4 ms·

> the consensus layer prevents anyone from effectively forking the project This isn't true, as soon as 51% of clients are trying to push "new" blocks not recog

by zanny 11y ago

> the consensus layer prevents anyone from effectively forking the project This isn't true, as soon as 51% of clients are trying to push "new" blocks not recognized by the old client old clients cannot recognize them and the chain forks. This has happened several times in the past, but we have never seen anything like Classic where it was a version increment out of the Core tree that is set to break old clients.

adrianmacneil 11y ago
Right. And that would be a disaster. Imagine if io.js forked node.js, but the fork was effectively unusable until 75% of projects started using it. And as soon as that threshold was reached, everyone still using and developing node.js was stuck with unmaintainable software and forced to migrate against their wish. Personal opinions aside, what Bitcoin Classic is trying to do is follow the traditional open source project fork playbook, but it will not succeed with a consensus protocol - at best they are keeping attention focused on the issue. Blockchain development works best when there is competition _between_ blockchains, not within them.
- zanny 11y ago
  Except that is the problem in Bitcoin. None of the money, none of the participation, none of the market are in alternate blockchains. They are in the bitcoin blockchain. That is fine, like the article says, when you have BDFL steering the project and keeping the original vision absolute, but that is not the case with bitcoin. Development is hijacked by those in a small insular group who refuse to adopt extremely popular reforms despite the userbase dramatically demanding the change. This has happened before. It happened with ffmpeg when it was forked into libav. Up until the fork happened the leadership of ffmpeg did not yield - only after the competition was real did they change their behavior and then they made the smart decision of obsoleting libav by merging back in all changes made. I'm not sure how you think Bitcoin Classic is failing. They already have a majority of hashing power pledged, and last I saw they had around a quarter of nodes running Classic or XT a week or so ago. If Classic wins, it simply demonstrates that the current project leaders of bitcoin core are not acting in the interests of a supermajority of the community as a whole according to their desires, and free software never works like that. If everyone wants change, someone will provide that change - it has happened so many times in the past they are near innumerable to list. I do not see how, if 75% of bitcoin users want 2MB blocks, it will not happen.
ikeboy 11y ago
Several times in the past? AFAIK there's only been one hard fork, https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi... That was accidental, and was reverted as soon as people realized. Someone pushed through a $10,000 double-spend in the meantime. Other than that, I don't think any hardforks have taken place.
- makomk 11y ago
  There was technically a second hard fork a couple of months after the accidental one in order to carry out the change that caused the first one in a more controlled and planned manner. Sticking with the existing code was not an option for technical reasons: "This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page)." Also, there was technically also one way back in 2010 to fix an integer overflow bug that allowed large amounts of BTC to be created from thin air: https://bitcointalk.org/index.php?topic=823.0 https://bitcointalk.org/index.php?topic=823.0
  - ikeboy 11y ago
    I've seen bitcoin developers saying that wasn't really a hard fork because the previous behavior wasn't well defined. The second is a soft fork, not a hard fork.

by zanny 11y ago

adrianmacneil 11y ago

Right. And that would be a disaster. Imagine if io.js forked node.js, but the fork was effectively unusable until 75% of projects started using it. And as soon as that threshold was reached, everyone still using and developing node.js was stuck with unmaintainable software and forced to migrate against their wish. Personal opinions aside, what Bitcoin Classic is trying to do is follow the traditional open source project fork playbook, but it will not succeed with a consensus protocol - at best they are keeping attention focused on the issue. Blockchain development works best when there is competition _between_ blockchains, not within them.

zanny 11y ago
Except that is the problem in Bitcoin. None of the money, none of the participation, none of the market are in alternate blockchains. They are in the bitcoin blockchain. That is fine, like the article says, when you have BDFL steering the project and keeping the original vision absolute, but that is not the case with bitcoin. Development is hijacked by those in a small insular group who refuse to adopt extremely popular reforms despite the userbase dramatically demanding the change. This has happened before. It happened with ffmpeg when it was forked into libav. Up until the fork happened the leadership of ffmpeg did not yield - only after the competition was real did they change their behavior and then they made the smart decision of obsoleting libav by merging back in all changes made. I'm not sure how you think Bitcoin Classic is failing. They already have a majority of hashing power pledged, and last I saw they had around a quarter of nodes running Classic or XT a week or so ago. If Classic wins, it simply demonstrates that the current project leaders of bitcoin core are not acting in the interests of a supermajority of the community as a whole according to their desires, and free software never works like that. If everyone wants change, someone will provide that change - it has happened so many times in the past they are near innumerable to list. I do not see how, if 75% of bitcoin users want 2MB blocks, it will not happen.

ikeboy 11y ago

Several times in the past? AFAIK there's only been one hard fork, https://github.com/bitcoin/bips/blob/master/bip-0050.mediawiki https://github.com/bitcoin/bips/blob/master/bip-0050.mediawi... That was accidental, and was reverted as soon as people realized. Someone pushed through a $10,000 double-spend in the meantime. Other than that, I don't think any hardforks have taken place.

makomk 11y ago
There was technically a second hard fork a couple of months after the accidental one in order to carry out the change that caused the first one in a more controlled and planned manner. Sticking with the existing code was not an option for technical reasons: "This would be an issue even if the entire network was running version 0.7.2. It is theoretically possible for one 0.7.2 node to create a block that others are unable to validate, or for 0.7.2 nodes to create block re-orgs that peers cannot validate, because the contents of each node's blkindex.dat database is not identical, and the number of locks required depends on the exact arrangement of the blkindex.dat on disk (locks are acquired per-page)." Also, there was technically also one way back in 2010 to fix an integer overflow bug that allowed large amounts of BTC to be created from thin air: https://bitcointalk.org/index.php?topic=823.0 https://bitcointalk.org/index.php?topic=823.0
- ikeboy 11y ago
  I've seen bitcoin developers saying that wasn't really a hard fork because the previous behavior wasn't well defined. The second is a soft fork, not a hard fork.