• Forum has been upgraded, all links, images, etc are as they were. Please see Official Announcements for more information

Forking Megathread

TaoOfSatoshi said:
Thank you for that, bud. Are there any ideas as to what IS causing this, then?
Click to expand...
moli said:
Flare, thanks for this post. Many people on this forum and IRC keep saying MNs on the older versions caused the forks and I keep saying but the network was stable on the older versions, there must be something in the Core version that rejects the blocks... But I'm a noob, I don't quite understand all this.

What has been causing the forks, flare? and are we out of the woods now? Thank you!
Click to expand...
Fact: forks only occured with masternode payment enforcement enabled. Which points me to the payment verification code. This seems to have changed from v10 to v11. So blocks mined by v10 miners may be incompatible with blocks mined by v11 miners and vice versa- in enforcement mode. The solution for me: dont enable enforcement until 90% of miners updated to v11 - this worked in the past and i dont see any reason why it should not work this time.
 
flare said:
Fact: forks only occured with masternode payment enforcement enabled. Which points me to the payment verification code. This seems to have changed from v10 to v11. So blocks mined by v10 miners may be incompatible with blocks mined by v11 miners and vice versa- in enforcement mode. The solution for me: dont enable enforcement until 90% of miners updated to v11 - this worked in the past and i dont see any reason why it should not work this time.
Click to expand...
Didn't we have 80%+ of miners on Core, if so, the majority of nethash should have been mining on the right blockchain. Then again, I read numerous pools rolling back to Onyx for stability so who really knows.
 
oblox said:
Didn't we have 80%+ of miners on Core, if so, the majority of nethash should have been mining on the right blockchain. Then again, I read numerous pools rolling back to Onyx for stability so who really knows.
Click to expand...
There is still a segfault in v11 we are trying to get hold of. Onyx was pretty mature, crashing with a probability of <1% per day. V11 has a higher crash yield yet.
 
flare said:
There is still a segfault in v11 we are trying to get hold of. Onyx was pretty mature, crashing with a probability of <1% per day. V11 has a higher crash yield yet.
Click to expand...

Tx flare for your posts
it helps to get some professional feedback on the issues
appreciate you taking the time !
 
TaoOfSatoshi said:
Thank you for that, bud. Are there any ideas as to what IS causing this, then?
Click to expand...

I know.

V11 was not ready for release and should not have been released on main net.

If you have a stable P2P network and release a new client that causes it to break, is it the old client or the new client that is at fault? I say the latter.

Please correct me if I am wrong but when v11 was released I saw no warnings about potential forks or problems with the network if we didn't update super quick.

Finally, expecting masternode operators to update very quickly is totally unrealistic. Otoh is away travelling at the moment and only has intermittent access to the internet...thats over 100 masternodes that won't be udpated for a while with just one person being away!

TLDR: V11 wasn't tested fully, was released too early and even if the dev team were aware of the possible issues that it could cause there should have been ample notice to the community and vendors to prepare.

The bottom line is that end users, masternode operators, exchanges, pools and merchants have been hit by this and lighting up your torches for a witch hunt to find the people on the older versions is distracting from the fact that THIS SHOULD NOT HAVE HAPPENED IN THE FIRST PLACE.
 
moli said:
I think i'm on the right track about this issue in my other post: https://darkcointalk.org/threads/0-11-0-darkcoin-core-release.3601/page-19#post-37589

"getcheckpoint" is no longer in v.11. Evan is trying to get rid of the reference nodes. Am I correct, flare?

Anyways, gotta get some sleep, will read your posts later. Thanks.
Click to expand...
Things get confusing then using "getblocktemplate" and seeing the bottom information:

,
"noncerange" : "00000000ffffffff",
"sigoplimit" : 20000,
"sizelimit" : 1000000,
"curtime" : 1422004946,
"bits" : "1b126005",
"height" : 207852,
"votes" : [
],
"payee" : "XtFzRjgQsM9YspaWtbNYJ6RhNUQYYevNxF",
"payee_amount" : 175010500,
"masternode_payments" : true,
"enforce_masternode_payments" : true
}
 
oblox said:
Things get confusing then using "getblocktemplate" and seeing the bottom information:

,
"noncerange" : "00000000ffffffff",
"sigoplimit" : 20000,
"sizelimit" : 1000000,
"curtime" : 1422004946,
"bits" : "1b126005",
"height" : 207852,
"votes" : [
],
"payee" : "XtFzRjgQsM9YspaWtbNYJ6RhNUQYYevNxF",
"payee_amount" : 175010500,
"masternode_payments" : true,
"enforce_masternode_payments" : true
}
Click to expand...
Yeah, and v10 clients show this

Code: 
    "masternode_payments" : true,
    "enforce_masternode_payments" : false
}

I have discussed this with UdjinM6 last night and it seems that this is just cosmetical, as the value is hardcoded in v11, but does not reflect the actual state the client is in. Feedback from eduffield pending
 
flare said:
This! It seems some folks forget that last week saw 6(!) releases, and in the past (v9, v10) it took at least one week for masternode network to catch up. But V11 is the first time people see the stats for that...

Having that said: v10 masternodes are not forking the blockchain, as they are not mining. Only way to fork a blockchain is to create (aka mine) a block which is "invalid" and not handled properly. Masternodes are passive re. blockchain generation. So please stop putting the responsibility for the forks on the masternode operators.
Click to expand...

There's this guy named Evan that disagrees with you.

eduffield said:
Nope, nearly all of the miners are up-to-date. The problem was "mnw" messages failed to propagate to part of the network, which then couldn't tell who to pay. So we just had fragmentation.
Click to expand...

There is more than one way to cause a fork when your coin has more than one way of validating it's blocks...

The two versions disagree on how mns are selected for winning payment. v11 has more robust BS detector that v10 lacks. When they disagree, we get a fork-like fragmentation of blocks being asserted by v10 which v11 rejects. There are enough v10s still on the network that they keep their own chain alive.

This will keep happening until the network becomes significantly v11 heavy and the bad mnw selections from v10 are made irrelevant to the point that v10 can't peer with itself enough.
 
Last edited by a moderator:
camosoul said:
There's this guy named Evan that disagrees with you.

There is more than one way to cause a fork when your coin has more than one way of validating it's blocks...
Click to expand...

I don't see a disagreement here: Miners forked the network because they did not receive mnw messages.

I repeat: Only miners can fork the network, passive nodes can't - claiming this is like saying: Using Bitcoin 0.7 wallets will fork Bitcoin.

If Darkcoin network is vulnerable to nwm propagation issues we need to fix that - otherwise it will be part of the next DDos attack.
 
flare said:
I don't see a disagreement here: Miners forked the network because they did not receive mnw messages.

I repeat: Only miners can fork the network, passive nodes can't - claiming this is like saying: Using Bitcoin 0.7 wallets will fork Bitcoin.

If Darkcoin network is vulnerable to nwm propagation issues we need to fix that - otherwise it will be part of the next DDos attack.
Click to expand...
But there are enough v10s around to keep too many connections alive to those miners. When they validate a block based on the bad input, v11 correctly rejects it but v10 keeps it alive.

v10 is finally getting minoritized enough that it's losing it's ability to hold enough connections to get it's mnw input validated.
 
camosoul said:
But there are enough v10s around to keep too many connections alive to those miners. When they validate a block based on the bad input, v11 correctly rejects it but v10 keeps it alive.
Click to expand...
Root cause found: Why are v11 miners accepting masternode entries of v10 masternodes? v9 did not have that, v10 neither.

I know that this was supposed to be an improvement to faciliate network updates, but it seems we opened a can of worms here.

Btw: Keeping it alive does not make a large fork - you still need (v10) miners to mine that chain.
 
flare said:
Root cause found: Why are v11 miners accepting masternode entries of v10 masternodes? v9 did not have that, v10 neither.

I know that this was supposed to be an improvement to faciliate network updates, but it seems we opened a can of worms here.

Btw: Keeping it alive does not make a large fork - you still need (v10) miners to mine that chain.
Click to expand...
Not entirely. The not-quite-a-fork as I originally called it is occuring at the point of propogation, not validation like we're accustomed. A block gets validated, but then other clients say that block is no good when they get the new block. It's as large as the grouping of clients that accept the block.

"Woah, this is the block, but the winner selected doesn't match what it should be, piss on this fraud block!"

v11 and v10 were thought to play together at the point of release. As stated in other threads, this couldn't be true... I've been harping about it for a reason, the same reason I was running v0.11.0.4 on mainnet before release...
 
Last edited by a moderator:
stonehedge said:
TLDR: V11 wasn't tested fully, was released too early and even if the dev team were aware of the possible issues that it could cause there should have been ample notice to the community and vendors to prepare.

The bottom line is that end users, masternode operators, exchanges, pools and merchants have been hit by this and lighting up your torches for a witch hunt to find the people on the older versions is distracting from the fact that THIS SHOULD NOT HAVE HAPPENED IN THE FIRST PLACE.
Click to expand...

I fully agree. These immature releases have to stop. Now we just need a strategy to convince evan about that.
 
If testnet isn't proving to be a good battleground representative of mainnet, why not create a test coin that is merge mined with DRK? Not sure if there is a way to have the existing masternode network function on both though. The nodes would still be setup using the primary blockchain (Darkcoin's existing blockchain) and the 1000k requirement, but all masternodes would also have test features embedded for this "test coin" to see what works and doesn't.
 
oblox said:
If testnet isn't proving to be a good battleground representative of mainnet, why not create a test coin that is merge mined with DRK?
Click to expand...
No, testnet is perfeclty fine. We are simply not using it correctly. The source code has too many exceptions for testnet and we go live on main net even with big major issues left behind.
 
You must log in or register to reply here.
Back
Top