Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
fork policy vague #1409
Comments
|
@rebroad A hardfork by nature must have consensus from the entire community before deployment. Attempts to deploy without such consensus transform it into an altcoin, which is clearly inappropriate for a Bitcoin webstie. Bitcoin.org is also not a Bitcoin Core website. You may wish to read https://bitcoincore.org/en/2016/01/07/statement/ There is no unavoidable "technical debt" in segwit, nor do I see anything interesting on either of those links. |
|
@rebroad No opinion on what should be on bitcoin.org, but my own opinion about the matter is here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html |
|
Yes, it's pretty vague and there's too much focus on hard forks. But it's difficult to make policies like this with the goal of describing what software we consider to be on the true Bitcoin network. I would probably consider some types of soft forks to be altcoins if they alter the economic and decentralization properties of the network significantly. In such a situation, a hard fork might be necessary to restore Bitcoin (which itself might be a contentious hard fork). It can get pretty complicated if you think about all the possible scenarios. But if there's ever a split in the community about which network is actually the true bitcoin network, then bitcoin.org will just pick the one we like the most (just like everyone else). We'll never promote 2 different bitcoin's. |
rebroad commentedNov 15, 2016
•
edited
https://bitcoin.org/en/posts/hard-fork-policy
This page seems to be misleading - it seems to suggest that "hard forks" are in some way worse than "soft forks" when it seems to me that the opposite is true. This conclusion has also been reached by other bitcoin developers. Can this page be clarified? Can "contentious" be defined, for example?
Soft forks are being proposed as bad because it makes it harder (if not impossible) for older nods to audit correctly - i.e. it intentionally creates a way for invalid transactions to appear valid to older software thereby taking away their ability to detect that they need to upgrade or change their rules. Hard forks on the other hand provide more "informed consent" being more transparent about a change in protocol.
This arguments above (also made by other developers) seem quite logical and persuasive, and therefore if Core has equally strong logical arguments for soft forks being better/preferable, then I think the opportunity is currently being missed to put these forward in the current web page.
Examples of what other developers are saying regarding the current soft fork dogma:-
https://medium.com/@octskyward/on-consensus-and-forks-c6a050c792e7#.apjir3k5d
https://www.reddit.com/r/btc/comments/428tjl/softforking_the_block_time_to_2_min_my_primarily/
The 2nd link is particularly interesting in that it proposes a way to scale bitcoin with far less technical debt than SegWit achieves, and without any hard-forks.