The issue I have with you is that you run to conclusions which I later break down. You then move on to the next thing you find that can be suspicious without acknowledging you’ve been wrong.
What do you mean by that?
Just noticed that I haven’t been able to successfully mint block with my Nu client v5.01 in the last 24 hours. They all went unconfirmed after creation although I have 8 connections. My Peercoin client is still minting so it appears not to be the computer or connection. Anyone else seeing the same issues or do I need to restart the client or my computer?
1 Like
I’m having the same issue.
All blocks unconfirmed since yesterday morning. I’ve restarted the client and computer with no luck so far.
1 Like
There has been many reorganizations (51 yesterday). The most likely is that some major shareholders have a bad connection and mint on old blocks because they failed to receive yours, or because their own blocks sometimes fail to propagate and finally reach the rest of the network when they find a second or a third block (and then yours are forked out because your chain is shorter because you and the other nodes could not create that many blocks during the same time).
To verify that it’s what’s happening you can look at the “new block found” occurrences in your log. If they are always followed by 2 or more block received and a “REORGANIZE” then that’s probably what is happening.
It could also be a major shareholder that deliberately modified the client to not mint on blocks generated by others.
3 Likes
Hold on now. You accuse people of things that they could have done (guesses). I counter your assumption with scenarios that can make it look like that but isn’t necessarily so. I’ve in several cases gathered detailed data suggesting statements of yours were false. You then go silent in that topic or find something new to focus on.
What you suggest is guilt unless proven innocent.
This argument we’re having here is not one where I’ve breaken down your statements. Do not conflate those to invalidate my point for readers who do not follow our strife.
There is no question he said those shares would not be used to mint. He did announce it, though I’m not aware of within which timeframe of beginning minting. As for being authorized by B&C Exchange shareholders, there’s the following passed motion that means the US-NBT were transferred to be handled by @Phoenix “in the interest of” B&C Exchange shareholders. They later passed the motion to trade all US-NBT for NSR.
All B&C shareholders funds in existence as of August 21st, 2016 shall be transferred to @Phoenix immediately upon passage of this motion, to be used in the interest of shareholders. This includes funds held by Jordan Lee and Angela. It excludes any funds that may be given by shareholders as a BlockShare or BlockCredit custodial grant.
— [Passed] Phoenix for Custodian of B&C Funds
Your crusade to enlighten everyone of what they should care about is apparently fair game according to those who control this forum. The fact you don’t know why they were used to mint suggests your primary interest in it lies not in whether it was best for B&C Exchange, but to find another weapon against @Phoenix and Nu.
3 Likes
I have found 163 entries with Reorganize in my logs (last week). Most are 2-5 blocks, found one with 6 blocks:
REORGANIZE
REORGANIZE: Disconnect 6 blocks; 525a93b7077822027583…8b950a4c7b02a3903beb
REORGANIZE: Connect 6 blocks; 525a93b7077822027583…4ac4f625b19ca5569b26
Wouldn’t be surprised about that given the current ‘climate’.
Things appeared to have returned closer to normal by now, although I still see an elevated number of orphans.
I’ve in several cases gathered detailed data as well.
I’m grateful for your feedback and accommodate you with admitting that you provided different points of view.
Whether statements are false or true often is subject to interpretation. We can agree to disagree for the most parts, if you like.
No, but I’m not agreeing that people in important roles should be left alone if there’s a lot going on that requires clearing up.
But instead of clearing things up, Phoenix hides and only crawls hout his hole to accuse people.
Agreed. It would be hard to deny that.
And what does that make him?
My interpretation is that this makes him unreliable in more than just one way.
Others may interpret that differently.
Really? That must have slipped my attention and I’m good at reading and remembering. The easiest thing would have been for Phoenix to tell, because he should remember best what he did, why and when.
Sadly he remains silent and leaves it to you to provide us with possible explanations of what might have been.
That’s the way to run a business and lead! Let others do the dirty work. Always transparent.
Thank you for your insights.
You wanna whitewash @Phoenix by saying he can do as he pleases, if only one may assume it could be in the interest of B&C sahreholders, this is funny. Or naive.
If he had decided to trade the NBT to BTC that would have been fine?
Oh how wonderful for BKS holders, if the B&C dev fund were still holding BTC…
Some might see him as a leader. Others might see him as something different.
And that inherits the “in the interest of” part of the motion that made Phoenix fund keeper?
Strangely the motion to trade NBT for NSR doesn’t have such an “in the interest of” clause.
Regarding the trade of NBT to NSR.
BKS holders were caught between a rock and a hard place and decided to trade NBT for NSR.
That was a game well played.
They received $0.70 per NBT. They paid a part of the price of Nu’s failure. What a compelling benefit. If there’s so much confidence in the inner workings of Nu, why trading NBT in the first place? Phoenix is felicitous, but he’s a snake in the grass.
Nu’s business scheme hasn’t been adjusted, although the need for that as well as ways for that have been laid out.
It’s still based on selling NSR to cover operational expenses like the losses from trading NBT/BTC all hoping for a future in which there will be miraculous revenues. For the foreseeable future this makes Nu a ponzi scheme.
Nu doesn’t have any kind of useful accounting. This is necessary to keep investors and customers blindfolded.
Phoenix hides behind a cloak of transparency, when thing’s aren’t transparent at all and he is silent as the grave.
He’s in control of the minting majority at Nu apparently, holds B&C ransom with the NBT and NSR games he plays and at the same time he’s super anonymous.
He’s the dictator that’s out of reach.
I spent a lot of time researching Nu. I was impressed by the potential. I was close to losing money at Nu. But I was lucky enough to find smelly things before I put money in NSR. I realized that the only real potential to make money is for those who can see behind the curtain. That was never the NSR holders.
Both NSR holders and customers (NBT holders like B&C) paid the price for Nu’s flawed business scheme.
With all I’ve read and understood I can’t stay silent and keep my peace of conscience. Future investors and customers have the chance to know better. It’s up to them what they make with this information.
Please try to understand that.
Wallet is unstable. Keeps crashing.
1 Like
Shit! Is there android wallet for nsr holding?
If the wallet keeps crashing, Cryptopia will delist NSR.
From my experience the wallet crashes due to lack of resources (memory?) after a while when it has to process multiple requests. Haven’t been able to pin down which requests causes the issue. I’m not a coder, just sharing experience.
When used as a ‘home’ wallet for minting there is no problem and it is stable.
A simple autorestart using e.g. something like supervisor works around this although I agree it is not ideal.
2 Likes
it does not crash here.
it runs out of memory on the server twice a day on average.
The NSR wallet is not resource efficient at all. Out of the 40 wallets, this is the only one that constantly crashes. I would not be surprised if Cryptopia delist NSR. I just hope this is fixed soon. At this stage I can’t even use this wallet without having to put it on an another server by iteslf.
The way the wallet works is that it makes a ton of UTXOs, ruining the output table for the chain and making it very resource intensive. There is no fix at this point aside from scrapping the chain/protocol and starting again.
I have 2 nodes, one minting on a VPS with 3 GB memory, and one full node on a 2 GB VPS. They have been both running without interruption since the last client upgrade on May 27. They are both on linux, one 32 bits and the other 64 bits. So it can be stable. I haven’t done any transfer for a long time though.
So what exactly is happening to those who get crashes (how does it crash, the end of debug.log, etc.) and in what situation (what you were doing, what platform, etc.)?
1 Like
Here is the end of debug.log from the client I’m running for the svr1 blockexplorer. Not sure it is relevant. It crashes between twice a day and twice a week. I can’t figure it out. Only seeing that it slowly takes more resources and then just exits. Please let me know what other logs you like to see as I would greatly appreciate to get this long standing issue sorted.
BTW As said before, I have no problems with my non minting node or minting node. They are indeed stable. It is only where the client is actively used through it APIs where the trouble starts. I saw something similar when running Liquidbits.
received getdata for: block ee1686da461de8267b8b
received getdata for: block 061902b00cb142f26905
received getdata for: block 1279da63a57e61cc7b01
received getdata for: block 5c5f0d68a8ddd9aed175
received getdata for: block 4dcab0376dc43e30f28f
received getdata for: block f6cd3ec5b63c59a5f78b
received getdata for: block b913b2048bee2033280b
received getdata for: block 5b8f6ee20b420c4de200
received getdata for: block 4f9dd836fa0137a18840
getblocks 1163520 to 4f9dd836fa0137a18840 limit 1021
getblocks stopping at limit 1164540 cb49a5019f27275122bc (725704 bytes)
received getdata for: block 7d953c1ef34d94d42301
getblocks 1163520 to 7d953c1ef34d94d42301 limit 1021
getblocks stopping at limit 1164540 cb49a5019f27275122bc (725704 bytes)
ResendWalletTransactions()
received getdata for: block 53c129646abcab434f1d
getblocks 1163279 to 53c129646abcab434f1d limit 1533
getblocks stopping at limit 1164811 c3dec2a16f7145c020ff (1038470 bytes)
ResendWalletTransactions()
ThreadRPCServer S method=getblockhash
ThreadRPCServer S method=getblockhash
ThreadRPCServer S method=getblock
ThreadRPCServer S method=getrawtransaction
ThreadRPCServer S method=getrawtransaction
ThreadRPCServer S method=getrawmempool
received getdata for: block 0b98e3a90136891e8972
askfor block c44950df1fd2236d7bc7 0
sending getdata: block c44950df1fd2236d7bc7
getblocks 1163520 to 0b98e3a90136891e8972 limit 1021
getblocks stopping at limit 1164540 cb49a5019f27275122bc (725704 bytes)
received block c44950df1fd2236d7bc702e4be31cc7d1f307ff0bb27ed076212c27579c0bcec
The blockexplorer code is open source and can be found here: https://github.com/Cybnate/NuBits-Abe-explorer
do you have swap space enabled?
It can make the client slow and sluggish but can prevent it from crashing.
easiest way to do that on Ubuntu is sudo apt-get install dphys-swapfile as then all the setup is dome for you
A look at /var/log/syslog for the same time period might be helpful too. If the process uses too much memory and is killed by the system I doubt anything would register that in the client debug.log but syslog might show the system killing it.