Half of these nodes still have not upgraded to the latest version… which node would I have to select?
The fifth column shows the client version. Here, just add this to your nu.conf:
addnode=198.52.199.75
addnode=218.1.18.78
addnode=212.114.48.31
addnode=212.129.19.120
addnode=176.9.113.75
addnode=84.76.78.204
addnode=167.114.116.72
addnode=79.165.43.191
addnode=52.10.23.117
addnode=97.123.141.92
addnode=108.26.50.128
If this works, then this is still not a very nice solution, but a hint.
If a client receives more than one block from the same stake on the highest block, all these are rejected as invalid blocks. The mechanism moves the top block off the blockchain when another block is received that is minted by the same stake within a small time interval. To prevent network forking, it only applies the top block.
The result is that if you attempt to exploit the nothing at stake issue by minting with the same stake on multiple machines, nearly all or all blocks you find will become stale, having been rejected by the network. The only way you would get a block accepted is if your duplicate is detected as such after it is no longer the top block in the chain. This would be rare and could only happen when network latency exceeds the time needed to find the next block.
Yes, we implemented this very effective mechanism to penalize staking on multiple forks because there is more incentive to do it on our network than most, due to voting.
We prevent this by adding a checkpoint to the source code with every release, similar to what is done in Bitcoin. This is different than the centrally issued checkpoint that can be issued in real time in Peercoin because it doesn’t allow one person to control which fork is preferred in real time. I plan to make it possible for data feeds to broadcast checkpoints and clients that choose to trust a particular data feed will apply them in the future. So eventually we will have a decentralized and optional capability to accept checkpoints.
I don’t understand. So you say if someone has a single UTXO and for some reason this UTXO is a valid stake to reach the target on two competing forks, then the blocks will get rejected if this person broadcasts both of them?
How likely is that? I mean, the kernel method will create two completely different values that can be assumed to be stochastically independent, and therefore the probabilities of finding a block on both forks is the product of the probabilities of finding a block on each fork. So its pretty safe to stake on multiple forks even with the same UTXO and if there should be the case where the target is reached on both forks, then I can decide based on the tx fees and only broadcast this block.
Furthermore if I have C coins and have separated them in T=C/10,000 UTXO’s, then I can still start staking on T different forks in each block by using different permutations of the UTXO’s, right? So after N blocks there can be T^N different forks where I can safely stake on without even considering your rule.
I don’t see how NaS is prevented by doing this.
Decentralized checkpointing of course would solve everything, including all aspects of the NaS problem. But we have to be really careful here. Consensus of the blockchain is established by minting. Period. If a data feed is able to cut a fork by broadcasting a specific checkpoint, then data feeds have a greater power regarding consensus than the minting clients.
Large data feed providers are points of failures, and this is not different with voting, but harder to manipulate than a 1 minute block time blockchain with a recommended number of 10 confirmations. Just imagine what happens if a large data feed provider gets hacked and broadcasts a malicious checkpoint. This very well may lead to a temporary network split and if the hacker is able to hold this up for 10 minutes then a lot of damage can be done.
2 Likes
I ran some tests with the address you sent me and during the last 7 days it was able to find many blocks with 0.5.4. The last one being at 2015-02-28 10:59:59 UTC, about half an hour ago. Were you running the client at that time and had connections to other nodes (minting is disabled when there’s no node to propagate blocks to)?
1 Like
Thanks @sigmike for taking the time to test and investigate this issue -
Yes, I have left the client running (and unlocked for minting) since yesterday.
Is there anything in the recent logs?
Can you send me your log since the first mention of “ddea8c25884bede23db0” (a block you should have received before this last block you should have minted)?
Will get you that within 15h. Don’t have my PC with me at the moment.
Choose a period when @crypto_coiner is not minting, if someone is minting with the same utxos and finds a block in this period, one should see the minting addresses @crypto_coiner has shown up in the blockchain, right?
Another thought. When I run nud with -debug -printcoinage -printcoinstake on my raspi and let the my laptop mint on the same wallet, I see in the log that the raspi finds a block (search the string “ew block found” ) and the block is orphaned a block later.
edit to add: If @crypto_coiner changes the clock of the minting computer faster by a few minutes, either the log will show the same output (with -debug -printcoinage -printcoinstake), or @crypto_coiner will start to find blocks because these blocks could be confirmed by the network before the duplicate blocks are found.
1 Like
Yeah, well the Nu/peercion devs have a solution of a problem they don’t consider really as serious as the PoWers try to make people believe it to be.
See a record of discussions of the “Nothing-at-Stake” claim and solutions to it.
Just sent you the recent log - the duplicate proof of stake errors are showing up, my stake is zero and I have found no block.
That was un-successful - “ERROR: ProcessBlock() : duplicate proof-of-stake” are back
I’m afraid I am running out of ideas. Adding the debug flags @mhps mentioned could give some further insight. And you are absolutely sure that your system time is correct? I think windows has an option to sync it to an NTP server.
Can someone with a Windows 0.5.4 binary confirm that staking works?
Time sync on Windows 7 on my laptop is on by default as it seems. My raspi also seems to have it. Turn it off if you do the time-drift test.
I m staking with no issue on win 0.5.4 client.
Me too.
I thought I would share the results of my investigation (that I shared with @sigmike in personal message) since I deem it is rather very important:
I have been taking regular back ups of my keys since sep. 2014 as a personal practice, so I have historical backups.
As an experiment, I just tried with several different backups taken in january and february, and the results are odd since the backups should be identical (I did not modify my wallet during the last 3 months, except the votes)
1/13 backup
xxxxxxx NSR
1224 tx
Last Transactions:
2015/01/13 07:39
2015/03/01
1/10 backup
xxxxxxx NSR
1224 tx
last transactions:
2015/01/10 17:58
2015/03/01
2/14 back up
xxxxxxx NSR
1254 tx
last transactions:
2015/02/14 22:24
2015/03/01
2/24 back up (the one I am using now)
xxxxxxx NSR
1258 tx
last transactions:
2015/02/21 18:29
(stops on 2/21)
Additional remarks:
- the NSR amount indicated by each backup is identical
- Stake and Unconfirmed for each backup is Null.
- I would like to mention something maybe important:
around 2/21, when inputing a motion to vote or a custodial vote or a parking vote (i dont remember exactly) , the wallet UI allowed me to input the same vote, twice accidentally, which I removed clumsily but I felt the cancelling was not clear cut. This is obscure.
Perhaps my last key contains a duplicate vote already broadcasted which makes the network see me as broadcasting duplicate PoS, which is not the same thing at all…
I tried to mint with my 2/14 backup over the night (during 8h)
And I successfully have minted on my whole wallet.
I find new blocks and I dont have any duplicate PoS errors in my log.
My last transaction is: 2015/3/2 07:46 mint by stake 40:00nsr
Questions and enquiries:
- Hypothesis: I strongly suspect that my last backup was corrupted because of the GUI double vote bug.
- To NuShareholders: can you test whether duplicate votes (it could be on custodian, park rate, motion vote ) lead to the duplicate POS errors?
!!BEFORE DOING THIS, BACK UP YOUR WALLETS!! This is risky and I would not be liable for any lose.
I believe I corrupted my wallet on 0.5.3 version but the bug could be still alive.
- [quote=“JordanLee, post:1, topic:1500”]
This release contains a fix to the way motion votes are counted, resolves an obscure parking issue as well as resolving other issues. The motion vote count issue is detailed here.
[/quote]
What is this obscure parking issue about?
If you go to Help -> Debug window -> Console and then type getvote then it will dump the voting it will write into blocks. You can check there if you still have that duplicate hash in your voting, if you don’t trust the GUI.
1 Like
Thanks for the very useful command -
Now, I have run the command for several backup keys and it appears I dont have any duplicate vote for the 3 type of votes for any backup
Also, the backup that has stopped minting for days (froze on 2/21) indicates some blocks minted minutes ago and some stake.
Anyone has an explanation? I am puzzled…
1 Like
Well, I give up - my last backup does not mint and I am positive about that.
I believe this is a serious bug.
I hope the open-sourcing of the code will put some light on that obscure issue.
1 Like