Re: [ANN][DRK] DarkCoin | First Anonymous Coin | First X11 | First DGW | ASIC Resistant
Attention pool operators!
https://darkcointalk.org/threads/issues-with-masternode-payments-fork.858/
https://darkcointalk.org/threads/issues-with-masternode-payments-fork.858/
Wow. So fast
Quote
Today the masternode payments fork went into effect. The fork went off without issue and the network looks very healthy, but it appears there is some issue with pools voting for the wrong masternodes. This is causing payments to not go through as they should.
The fix is rather simple and can be done without a hard fork. After the pools update to the fixed version, the payments will begin to go through.
Were currently working on a resolution and will provide the new version soon (probably by tomorrow, hopefully in a few hours).
Thanks,
The Darkcoin Team
The fix is rather simple and can be done without a hard fork. After the pools update to the fixed version, the payments will begin to go through.
Were currently working on a resolution and will provide the new version soon (probably by tomorrow, hopefully in a few hours).
Thanks,
The Darkcoin Team
Pools need to update to the fixed version
[01:51] http://pastebin.com/QmbM8dPH
[01:51] I found the problem :-)
[01:51] It's actually rather simple to fix
[01:51] ahem
[01:52] anyone care to guess from the paste? I'm curious
[01:52] checking
[01:52] badVote
[01:53] Both votes have the same hash, but they have different votes
[01:53] er both blocks*
[01:54] Two blocks are solved at nearly the same moment on the network, both are propogated and accepted by the network. In the current implementation both blocks have the same hash, but in these blocks there's some discrepency about who to vote for.
[01:54] In one block the miner votes for 88802 and 88803, in the other the miner abstains from voting. When the next block is solved it's based on of one of the older blocks, so half of the network beleives the miner cheated and rejects the block causing a fork.
[01:54] nice
[01:54] The solution to this is rather simple. Any changes to the votes need to also change the hash of the block. The network must not think these two blocks are the same.
[01:54] How come we didnt see this in testnet
[01:54] seems rather simple problem
[01:55] what in mainnet causes it
[01:55] Not sure. No one noticed.
[01:55] race conditions are hard to witness
[01:51] I found the problem :-)
[01:51] It's actually rather simple to fix
[01:51] ahem
[01:52] anyone care to guess from the paste? I'm curious
[01:52] checking
[01:52] badVote
[01:53] Both votes have the same hash, but they have different votes
[01:53] er both blocks*
[01:54] Two blocks are solved at nearly the same moment on the network, both are propogated and accepted by the network. In the current implementation both blocks have the same hash, but in these blocks there's some discrepency about who to vote for.
[01:54] In one block the miner votes for 88802 and 88803, in the other the miner abstains from voting. When the next block is solved it's based on of one of the older blocks, so half of the network beleives the miner cheated and rejects the block causing a fork.
[01:54] nice
[01:54] The solution to this is rather simple. Any changes to the votes need to also change the hash of the block. The network must not think these two blocks are the same.
[01:54] How come we didnt see this in testnet
[01:54] seems rather simple problem
[01:55] what in mainnet causes it
[01:55] Not sure. No one noticed.
[01:55] race conditions are hard to witness
Its going to take one more month for what you call "simple problem" ?