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
Blog: Bitcoin.org Position On Hard Forks #894
Conversation
and others
jgarzik
commented
Jun 15, 2015
|
"less is more" Sometimes it's better not to take a public position related to actively debated issues this doesn't seem like bitcoin.org material |
|
@jgarzik please note that this statement says nothing about the block size debate. It only addresses contentious hard forks, which we believe have major potential for harm regardless of what they implement. |
|
ACK. This is beyond the blocksize issue. Pushing a hard fork in the face of such controversy is a folly, a danger to the network, and that deserves to be said. |
|
This is very disappointing David. You want to ensure new users don't learn about Bitcoin XT. Why not just say that outright? Your position is wrong and will just reduce bitcoin.org's utility as a place to learn important information. What's more, you are inherently supporting a status quo in which a tiny number of people can veto any change to Bitcoin regardless of how widely supported it is by the rest of the community. That's not decentralisation. And it is ultimately far more dangerous to Bitcoin. If you try and shut down the only method the community has to reject the decisions of this tiny group, you're effectively dooming the project to the whims of whoever happened to be around early on in the project and ended up with commit access. However, if you really want to "pick a side" in this debate like that, then given the wording of your policy if a >1mb chain wins you will have to replace Bitcoin Core completely and not mention it anywhere, as at that point, it would be the implementation leaving the consensus by attempting to produce a contentious hard fork (the 1mb only chain). So are you sure you thought this through? Are you ready for that pull request, if one day it comes? I don't think this policy makes any sense. |
|
NACK. I have great respect for many of the accomplishments and contributions @theymos @cobra, @saivann, @harding and @laanwj have made to Bitcoin, and agree w/ @laanwj that hard forks are beyond a block size issue. Also, I am uneasy about the uncertainty and future implications of anything like that. However, I agree more w/ @jgarzik that Bitcoin.org should try to say as non-bias as possible in the midst of publicly debated issues. Hundreds of people, if not thousands, are coming to this site every day, many of which are new users learning about Bitcoin for the first time. For existing users in the space, this website is also an incredible resource in most cases. It seems like this post would be in an effort to sway public opinion more-so than anything else. It doesn't provide a complete context nor link to a wider array of information about the underlying issues it references so the reader can form their own opinion - it comes across as forcing a biased one. Let's not be dualistic and centralized with our messaging on Bitcoin.org. There is already a healthy debate happening on the dev mailing list, also in several other places. |
|
Oh yes, rereading the policy, there's one more reason this policy is suicide - it says you will delist any wallet or service that announces it will operate on the other side of the "previous consensus". Currently every single wallet bar GreenAddress that we've polled has told us they support bigger blocks. Additionally, every major payment processor we've talked to has also said that. Plus the major exchanges. So to be consistent with this policy you will have to delete every wallet and all major services (except GreenAddress) from the website. This would eliminate bitcoin.org as a useful place to learn about Bitcoin products and services, which is one of the key functions of the site! I understand you are concerned about the notion of a contentious hard fork. I think you're wrong about the possible consequences though. It should be clear from the block chain when the change has reached a sufficient amount of mining power and at that point there would be plenty of time for services to upgrade before the fork actually happens. Nobody should lose any money and nobody should feel disenfranchised: they can just switch to the winning chain and carry on. They can always sell their coins before or after if they really believe that the plan Satoshi had all along is so bad. |
|
@mikehearn we explicitly discussed the fact that this policy means we might have to drop Bitcoin Core someday, and we've begun moves to make it clearer that Bitcoin.org is separate from the Bitcoin Core project---even though some of the contributors who pre-approved this statement are unhappy about that. Regarding wallets, I am not aware of any wallet listed on this site that has the ability to detect a hard fork and has announced that they will move their users there by default. Re-reading the statement with this in mind, I think this might be unclear: I meant to indicate wallets that make the choice for their user, rather than wallets that just happen to use whatever chain they think is the strongest. I'll see if I can revise that---thank you for pointing that out. |
|
@Coderwill This statement is not about the block size debate. We encourage everyone to consider those issues for themselves, publicly or privately. This is about Bitcoin.org not promoting software that will lead to contentious hard forks. As the statement says, the least worse outcome from a contentious hard fork is people feeling disenfranchised because the consensus rules have been changed without their consent. Disenfranchised-feeling people are less likely to use Bitcoin, reducing the value of the system (possibly significantly because of Metcalf's law). In a worser case, the network is left in some sort of permanent split, making bitcoin as a currency much less useful, and likely causing bitcoins on both sides of the split to lose even more of their value. In the absolute worse case, Bitcoin becomes so unusable during the contentious hard fork that people switch to another system---maybe an altcoin, or maybe back to centralized payment systems. This makes bitcoins entirely lose their value. None of these are good outcomes, which is why it's important not to promote software that puts us at risk of going down that path. |
|
Alright, please do clarify that. There are yet more problems with this policy though. You have not defined "contentious". What happens if, say, after all this blows over we are cruising along on a >1mb chain. Whether it's Bitcoin XT or not. And then we decide, OK, that went fine, so let's try and do hard forks yearly to introduce new features. So we introduce some simple new features like a better sighash function, for instance, and then someone - somewhere - says they hate it and they could never support such a function. What then? At that point XT would be engaging in a "contentious" hard fork .... with itself. So you'd have to delete it entirely and would be left with no full nodes on the website at all. That outcome is nonsensical but it is implied by your policy. If you try and define "contentious" then you'll rapidly discover it's a ball and chain that drags you underwater. |
|
@mikehearn I agree that defining contentious is difficult, but it is easy to say that the current situation is such a case. |
|
Ah, so your policy is entirely arbitrary then. I can as well argue that in fact this situation is not contentious at all - as I said above, all major players agree on the need for larger blocks, indeed, even some Blockstream employees do (or say they do). It's really just a tiny number of people holding up progress at this point. So if you are going to decide that my definition of contentious is wrong and yours is right, just because "it's easy to say", then why have a policy at all? Why not just admit it's your opinion? Look. I don't mean to be antagonistic. I realise you are attempting to avoid harm to Bitcoin. But remember why Gavin and I are doing this - if the fork does not happen Bitcoin will suffer. You see this as some kind of one-sided deal: if a fork happens it might be bad and hurt Bitcoin, but if it doesn't happen there's no problem! I'm the developer of the first and still most widely used SPV wallets. Aaron Voisine is the developer of the most widely used SPV wallet on iOS. Both of us have reached the same conclusion about what will happen if capacity is not raised: it will hurt Bitcoin, a lot. Many others in the community have also reached that conclusion. By backing stasis you are not backing stability, or helping preserve Bitcoin's value. You are not taking a principled stand for a better development process. You are instead joining up with those who want to drive the network off a cliff. It is not bitcoin.org's place to make such decisions. Please reconsider this policy. |
What is contentious here is the unilateral, almost dictatorial decision. Bitcoin was designed so that, for a hard fork, everyone that runs a full node has to agree to change their software. This is the only protection it has against attacks and takeovers. It may mean that your, or my, specific dream feature may not make it into bitcoin as fast as we'd like. But what is more important is the long-term stability and survival of the system, and that is more likely if it it protected against such contentious forks. |
|
I agree that "contentious" ought to be defined. In the case of the block size matter, unanimous support from exchanges and merchants IMO indicates non-contentious despite the opinions of developers. In the case of other hardforks (eg, one to make valid bitcoins unspendable or inflate the supply beyond 21MBTC), any dissent would seem more relevant. Clarification: I don't think XT's proposed hardfork meets any of these criteria for non-contentious, but I could be wrong. |
Everyone who wants to trade with the others, yes. Wladimir, I'm afraid your depiction of this decision as being "dictatorial" is the exact opposite of the truth. How could myself or Gavin dictate anything? All we can do is release software. It's actually the Bitcoin Core developers who are acting like dictators - refusing to listen to what the people want and then asserting that any attempt to resolve the problem with a vote is disaster, madness, it'll destroy Bitcoin, and only when everyone (i.e. you) agree can anything happen at all. What we plan to do with XT is put the change to a vote. That is the opposite of dictatorial decision making. |
|
ACK |
|
@mikehearn I've not been involved as much as I'd want recently and only have an incomplete view of the situation, so sorry in advance if you have answered this elsewhere; If I understand correctly, with the changes introduced in XT, you will essentially let miners vote using the block version number, after what, if the number of miners adopting the change reaches a certain threshold, the hard fork will become effective. If so, can you explain what is that threshold. How much of the hash rate (and for how much blocks) will be necessary before XT starts forking the network? Either way, if XT really risks bringing any significant part of the network (edit: against each other) into a hard fork, I think you'll be wasting of your time insisting here. Virtually every person in control of the website, domain, servers, core releases, are unequivocally against this to the best of my knowledge. |
|
The exact thresholds aren't decided yet, I'm waiting to see what patch Gavin produces. Then we can start to get feedback and negotiate on that. There will most likely be a date requirement on it as well as a block percentage threshold. Regardless, there is no risk to anyone paying attention - Bitcoin Core will start printing messages in the logs and status bar before the fork happens telling the user to upgrade. It's only people who are running fully on auto-pilot for a fairly long period that can be left behind and this is true for any fork for any new feature. |
|
Commit 30cf561 tries to clear up the possible confusion identified by Mike by adding the following sentence (also highlighted in green in the image at the end of this comment).
|
morcos
commented
Jun 15, 2015
|
I'm in support of a message like this. I don't believe most of the services, wallets, and exchanges out there have fully appreciated what they are "supporting". This message on bitcoin.org would help communicate that, which I think is valuable for everyone in the community, regardless of which side of the debate you are on. Defining contentious is not easy, but no one can argue that this particular change is not contentious. I also would recommend modifying the first line to say "may result" instead of "will likely result", I'm not sure if it's likely. I don't believe this hard fork could go forward as is without Gavin's support, and I believe he cares about Bitcoin too much to push it through in the face of the existing opposition. This debate of how Bitcoin should evolve could still resolve itself in a positive manner. I believe all of the biggest Bitcoin proponents will eventually find a way forward without actually creating a contentious hard fork. |
|
@harding does that take into account the fact that Mike declared recently in an interview that if it comes to it he will put checkpoints in bitcoinj (and XT) should XT not have the chain with the most work to force clients on his contentious consensusless hardfork? Just in case that actually happens we forked bitcoinj so we can start from a clean state... |
|
@morcos Thanks! Changing to "may result" is no problem. I'm going to hold off for a while in case there are any other minor improvements like that which I can bundle together. It also very much my hope that in a few months we'll be looking back on this as another Reddit-induced drama. |
|
@mikehearn I agree that dictatorial decisions from all sides are bad. But don't you agree that the fact that this still triggers such a heated argument (here, an on the mailing list) shows that it's contentious? That many people disagree on the course to take? If only it was just me that disagreed it'd have been easy. But it's not.
Exchanges, miners and big merchants are not the only users that count. |
jgarzik
commented
Jun 15, 2015
|
Personally I agree with a lot of the hard fork risk evaluation (and tried to encompass that in BIP 100 discussion sections). However, this still feels like an inappropriate forum given the material in this PR. Bitcoin.org should be more neutral. e.g. RE block size, there is a major contingent not represented, that feels like a hard fork increase in this specific instance is no big deal. Suggested approach: Turn the same blog post into a whitepaper, and then link to the whitepaper from bitcoin.org. It shouldn't be core material of the website itself. Whitepaper can list authors/endorsers etc. |
|
@grennaddress yes, I was thinking about checkpoints when I wrote the original statement and in commit 30cf561 when I added this clause, "...and which continues doing whatever it would've done anyway." I do want to point out that I'm not a lawyer, and I'm not trying to write a court-enforcible Bitcoin.org terms and conditions document here. This policy is written in plain English to communicate the general idea to software authors and service providers who ask to be promoted on Bitcoin.org. Dealing with any nuances will be left to the regular site contributors, who (in my biased opinion) do a pretty good job of dealing with weird edge cases. |
|
+1 @jgarzik 's suggestion just now - otherwise, let's be honest - it seems there is no context except a force majeure, where this PR wouldn't be merged. I'm not sure what "unexpected criticism" is but it doesn't seem like we're short on criticism in this thread. |
|
@jgarzik neutrality, defined as the absence of comment, is very attractive. It is likely the case that the reason you think Bitcoin.org should be neutral is because we have been neutral through so many previous debates, as well as the last several months of this debate. However, if we wrote a white paper and came to a conclusion that contentious hard forks are very risky---an opinion I believe many Bitcoin experts currently hold---would it not then still be our obligation to refuse to promote the software that powered them? Phrased another way, Bitcoin.org holds the software it helps promote to a fairly high standard already. One of the ACKers on this very thread has software we've twice refused to promote because it doesn't yet meet our standards. Yet the problems with that software are insignificant when compared to software that could harm all Bitcoin users whether or not they used it themselves. Thank you for your suggestion. I continue to believe this should be site policy. |
|
@harding, thanks for considering it |
|
This statement is necessary, unfortunately. Contentious hard forks are not good for Bitcoin. Hard forks should have near unanimous support, both among the developers, and across the wider community. Neutrality is not possible here without causing confusion and exposing new visitors to excessive risk. In the event of a contentious hard fork, bitcoin.org should continue to support and promote software that conforms to the existing consensus. If somebody wants to rewrite the existing consensus without unanimous support, then they should create a new currency, and promote it as such. @mikehearn I don't think XT will ever be featured, promoted, or discussed on bitcoin.org. It's too controversial and divisive. I also don't think XT will get much support or usage in the community once people clue in on the fact that your controversial hard fork won't win out against Bitcoin Core. |
|
@laanwj Any large enough group of people will have people who think anything is contentious. Lots of people in the world think Bitcoin itself is contentious - does that mean we shouldn't work on it? The notion that literally every single person on the internet must be happy for something to happen is nuts. It's a recipe for the stagnation we now see - even when that stagnation will result in a very significant change to what Bitcoin was always meant to be. Given a large enough group, you cannot avoid upsetting some people no matter what. It's pointless to even try. So defining anything "contentious" as unworkable, is itself unworkable. Do you at least understand that argument, even if you don't agree with it? @Cobra-Bitcoin Let's imagine for a second that you've misjudged things and XT does become widely used, perhaps even triggering a chain fork to raise capacity (as Satoshi intended). Would you be OK with this policy meaning that Core must be deleted from the website, and replaced with XT everywhere? |
|
I think we're forgetting our Mission on the About page for Bitcoin.org: _Remain a neutral informative resource about Bitcoin._ It sounds like the only thing that's informative about this PR is the opinion of a group of people. To be clear, I agree with the sentiment in much of the PR, however, are we still remaining neutral if it gets merged? Nope. |
|
Striving for neutrality is very valuable, but only within a domain. Should bitcoin.org be neutral towards misinformation about bitcoin? Should it be neutral toward efforts to shut it down? No. Should it be neutral towards efforts to fragment the blockchain? Toward an effort to undermine Bitcoin's fundamental properties? Towards efforts to promote competing currencies? I don't think so. Many initiatives in Bitcoin are actually, in fact, uncontroversial -- e.g. where was the opposition to the BIP66 soft-fork? Some things will not be and complete non-controversy may not always be achievable and maybe some of those things still can and should go on, but a substantial minority opposed is nowhere near non-controversy-- it's not just a question of "some people"; and arguments that a complete consensus may not be possible just don't apply in cases like that. Particularly in terms of hardforks that rewrite the rules of the system, if the rules can just be rewritten against substantial opposition then they're meaningless---- and that is rule by political and press excellence and not rule by math. Even the claims of unanimity in some subgroups here is incorrect-- but just convincing a subgroup is not sufficient. I agree with @morcos above, that the direction here is good. The approach could use a little fine tuning, but that can be accomplished. |
|
I keep changing my mind as I write a response to this. Software makers are allowed to advocate changes in general. Deciding when the advocacy for a change is "over the line" seems nearly impossible to me, except in some corner cases. Is this a corner case? For example: Let's say Mike submits Bitcoin XT to the wallet page, based on 1MB blocks. It waits the proper waiting period, checks in out Q&A. Next he pushes a 20MB patch. Does this mean the wallet(or at least the newest version) should be put in the wait period? Is it considered Bitcoin anymore? What if Bitcoin Core devs push a 4MB block increase? Are these wallets with proposed changes not advertised at all? What if support appears to swell? You may be stranding people on "outdated" versions! It's something to think about. It appears that in general, when it comes to these kind of forks, I think bitcoin.org should be as informational/netural as possible. So normally with these types of serious proposals bitcoin.org should bend over backwards to accomodate. I would be for a page/blurb on the dangers of contentious hard-forks however, and "marking" versions that have proposed hard-forks(Core or otherwise). That is common-sense, and I think really gets at the heart of what I and others are finding really exasperating about the ongoing conversation. |
|
I strongly support the proposed policy, and the blog post looks good to me. @mikehearn Bitcoin.org exists to serve Bitcoin. XT will, if its hardfork is activated, diverge from Bitcoin and create a separate network/currency. Therefore, it and services that support it should not be allowed on bitcoin.org. In the extremely unlikely event that the vast majority of the Bitcoin economy switches to XT and there is a strong perception that XT is the true Bitcoin, we should probably consider switching from Core to XT, supporting only wallets/services that support XT, etc. In that case, the definition of "Bitcoin" will have changed. It doesn't make sense to support two incompatible networks/currencies -- there's only one Bitcoin, and bitcoin.org serves only Bitcoin. (Adoption of XT by bitcoin.org isn't guaranteed even if it is adopted by the the vast majority of the economy. We wouldn't allow any "Bitcoin" that inflates the currency more quickly, for example, so we'd have to consider whether this hardfork is in this "absolutely prohibited" category before allowing it. But that's not relevant now.) If a hardfork has near-unanimous agreement from Bitcoin experts and it's also supported by the vast majority of Bitcoin users and companies, we can predict with high accuracy that this new network/currency will take over the economy and become the new definition of Bitcoin. (Miners don't matter in this, and it's not any sort of vote.) This sort of hardfork can probably be adopted on bitcoin.org as soon as we've determined that it's not in the "absolutely prohibited" category mentioned above. For now, there will always be too much controversy around any hardfork that increases the max block size, but this will probably change as there's more debate and research, and as block space actually becomes more scarce. |
|
@theymos But why an obviously biased and dualistic notice about hard forks? |
theymos
and 1 other
commented on an outdated diff
Jun 15, 2015
| +layout: post | ||
| +lang: en | ||
| +category: blog | ||
| + | ||
| +title: "Bitcoin.org Hard Fork Policy" | ||
| +permalink: /en/posts/hard-fork-policy.html | ||
| +date: 2015-06-16 | ||
| +--- | ||
| +It appears that the recent block size debate will likely result in a | ||
| +contentious hard fork attempt. | ||
| + | ||
| +Contentious hard forks are bad for Bitcoin. At the very best, a | ||
| +contentious hard fork will leave people who chose the losing side of the | ||
| +fork feeling disenfranchised. At the very worst, it will make bitcoins | ||
| +permanently lose their value. In between are many possible outcomes, but | ||
| +none of them is good. |
harding
Contributor
|
|
Perhaps by removing all of the bias we could instead write something like: Hard Fork PolicyPart of Bitcoin.org's mission is to be a neutral and informative resource. We encourage wallet authors and service providers to offer their opinions on hard fork proposals by opening issues and/or submitting pull requests. Core developers and contributors will review these submissions on a case-by-case basis. End In this way we can deal with anything contentious and discuss concensus when the situation arises, but not before then. We haven't even had a Hard Fork in a negative context like this policy is alluding to, yet we're rushing out the door with a warning about one. If we're inevitably going to talk about XT or any other potential controversial change when it arises, let's let that happen when it comes up via its own Issue or PR on GitHub. Let's deal with it on a case by case basis, just like we do with wallets. As for what I suggested writing above, if something has to be said about Hard Forks, let's at least keep the author's bias out of it and remain neutral. |
|
ACK |
I thought the statement, particularly the final paragraph, made it clear that we fully encourage software makers to "offer their opinions on hard fork proposals"---which includes even the most bombastic advocacy for a hard fork. The software that we're not going to promote based on this policy is that which will we know will diverge from the previous consensus in order to follow a contentious hard fork.
That would be controversial, and so we would not list that version of Bitcoin Core on the site. I mentioned previously that this policy applies to Bitcoin Core, and the statement itself explicitly mentions Bitcoin Core. We're not playing favorites.
Again, we're not judging proposed changes. In the case of open source software, we'll look at implemented changes. In the case of proprietary software or remote services, we'll look for other evidence that a change has been implemented.
If support swells sufficiently, then it isn't contentious any more, and the policy no longer applies.
Please note that Bitcoin.org is remaining neutral to specific hard fork proposals. We don't want to stop you from choosing the best proposal---we simply want to preserve your ability to choose by not promoting software that would force its ideas for the network upon you.
If the announced plans for Bitcoin XT continue, I'll probably have to write that page. (Sigh.) |
maaku
and 1 other
commented on an outdated diff
Jun 15, 2015
| @@ -0,0 +1,41 @@ | ||
| +--- | ||
| +type: posts | ||
| +layout: post | ||
| +lang: en | ||
| +category: blog | ||
| + | ||
| +title: "Bitcoin.org Hard Fork Policy" | ||
| +permalink: /en/posts/hard-fork-policy.html | ||
| +date: 2015-06-16 | ||
| +--- | ||
| +It appears that the recent block size debate will likely result in a | ||
| +contentious hard fork attempt. |
maaku
|
Supporting bigger blocks is quite different to being willing to fight a civil war in order to get them. If Bitcoin Core came to consensus over a block increase with the majority technical community in agreement, I am confident everyone would upgrade to it. But in terms of your unilateral fork which carries immense risk, I am unconvinced you will get major exchanges and wallet providers to risk fighting your war for you. They will trust the status quo which has proven technical competence at every turn. |
|
ACK promoting a contentious hard fork is equivalent to promoting an altcoin so it makes sense. |
maaku
and 2 others
commented on an outdated diff
Jun 15, 2015
| +date: 2015-06-16 | ||
| +--- | ||
| +It appears that the recent block size debate will likely result in a | ||
| +contentious hard fork attempt. | ||
| + | ||
| +Contentious hard forks are bad for Bitcoin. At the very best, a | ||
| +contentious hard fork will leave people who chose the losing side of the | ||
| +fork feeling disenfranchised. At the very worst, it will make bitcoins | ||
| +permanently lose their value. In between are many possible outcomes, but | ||
| +none of them is good. | ||
| + | ||
| +The danger of a contentious hard fork is potentially so significant | ||
| +that Bitcoin.org has decided to adopt a new policy: | ||
| + | ||
| +> Bitcoin.org will not promote software or services that will leave the | ||
| +> previous consensus because of a contentious hard fork attempt. |
maaku
|
|
Hard-forks are one thing: a backward-incompatible change to the Bitcoin protocol, agreed upon by consensus. But the current XT proposal is something else entirely; it changes the protocol without consensus, thus it is an altcoin and out-of-scope for bitcoin.org no matter how neutral it is. Changing the block size rule is not substantially different from the more common altcoin model of changing the genesis block rule, and in fact there is precedent for an altcoin splitting from the genesis block of an existing cryptocurrency: Feathercoin is differentiated from Litecoin only by a checkpoint, yet is well-established linguistically as an independent altcoin. This logic is similar to the difference between soft-forks and 51% attacks. |
maaku
commented on an outdated diff
Jun 15, 2015
| + | ||
| +This policy applies to full node software, such as Bitcoin Core, | ||
| +software forks of Bitcoin Core, and alternative full node | ||
| +implementations. | ||
| + | ||
| +It also applies to wallets and services that have the ability to detect | ||
| +the contentious hard fork, and which release code or make announcements | ||
| +indicating that they will cease operating on the side of the previous | ||
| +consensus. | ||
| +It does not apply to software that cannot detect the contentious hard | ||
| +fork and which continues doing whatever it would've done anyway. | ||
| + | ||
| +To be clear, we encourage wallet authors and service providers to offer | ||
| +their opinions on hard fork proposals, and we will not penalize anyone | ||
| +for contributing to a discussion. We will only stop promoting particular | ||
| +wallets and services if they plan to move their users onto the |
maaku
|
|
Opinions clearly seem to be mixed. As far as I'm concerned, my biggest worry is if the hard fork is conducted in such a way that it might become effective before an overwhelming majority of users have already supported the change. If that risk is mostly avoided (looks like this can be the case), I guess a good part of my apprehension goes away. Now, measuring this support is another matter. It may be easier for miners (and maybe nodes?), elsewhere it may be more difficult, although not impossible if businesses in the space care to take public position. For that reason, defining what contentious means might prove difficult. Evaluating the consequences of any given change is crucial, yet it also always entails theory and speculation. As we try to be soothsayer in a large ecosystem, should it come as a surprise that there is persisting disagreement among experts as to the future for such a critical change? Is there really chances that consensus is reached on such a though and speculative matter? (I surely hope so and, if that's of any value, strongly encourage any effort on this front). To be clear, I still lean toward supporting this pull request but I surely cannot say if XT (which is not released) is bound to meet the definition of a contentious hard fork. |
maaku
commented
Jun 15, 2015
|
I have some nits above that I hope you will consider, but otherwise ACK. |
In the case of 20MB blocks, there is almost unanimous consensus that Mike and Gavin's approach is wrong. I also think @luke-jr's observation about altcoins is worth adding to the policy. Something along the lines of anything that creates an altcoin is out of scope for listing on bitcoin.org |
|
@btcdrak just a point to clarify, there is almost unanimous consensus in the technical community that Mike/Gavin's 20MB proposal, and especially the create-a-blockchain-fork is a wrong approach. In the non-technical community things are not so unanimous though the view on the blockchain fork part is very negative-- and we'll likely see more said against that as people realize whats actually been proposed. (I know you know this, but I think its important to be more precise) It's surprising to me that anyone would find the view that Bitcoin shouldn't have its hard-imposed rules controversially changed out from under people; I wouldn't have thought this needed any clarification in the past. After all, general resistance to twiddling around with politics is a fundamental part of the purpose of the system. Reasonable people can, and will, disagree on the fine details for where the boundaries are. We do not need to answer those questions today to at least be clear on where things stand for questions not on the boundary. |
|
@gmaxwell What's the approach that you alluded to that you think could use a little fine tuning? |
|
@gmaxwell thanks for commenting on my omission, I had meant to write "* in the technical community" but somehow my brain glitched-out. |
|
NACK due to time frames. From the wording my impression is that if a software maker "chooses their side" of the fork by implementing code while the debates continue, they are automatically delisted. As a result it seems like this policy disincentivizes entities from being early adopters of a hard fork. Also, how are you going to know if a closed source software maker that doesn't announce their intentions implements code to support a hard fork? My counter-proposal for such a policy would be that software on the new side of a hard fork not be de-listed until such time as a hard fork has actually occurred. |
|
The core of the problem is the following : When do we consider that an altcoin comes into existence ? Is it when an hardfork occurs, or is it when a codebase is planning the hardfork ? I would say in both case, I see no reason to promote a (future?) altcoin on bitcoin.org. |
|
@bartobri there is no vote. |
|
@jlopp I've been loose with my language in several of my comments, but the statement says "releases code" instead of "implements". Do you think that's unclear that we're talking about code that's meant for end use (rather than development code)? I certainly don't want to discourage anyone from demonstrating how their idea would work.
Could you please describe what you mean by a hard fork actually occurring? A policy that didn't take effect until blocks started to be rejected would likely be ineffective at accomplishing anything. |
|
@NicolasDorier I was about to say something similar. It seems fair that if there is an announcement by a company or if there is evidence (code or recognizable fork nodes) that it supports a contentious fork then the rule would apply, otherwise for the ones that can't be code reviewed and that don't say and have no way of being detected with no doubts then they would wait for the actual hard fork. |
|
@harding "Releases code" is clearly defined in terms of open source software, though of course you'll never know when closed source software has been deployed unless the company openly states having done so. Thus it seems like such a policy disincentivizes open source companies but not closed source companies when it comes to choosing the new side of a hard fork. That's basically how I arrived at the conclusion that it's not particularly fair to have this kind of policy if it can't be evenly applied across software makers. The only way you can know for sure which side of a fork a closed source company has chosen is by observing the blockchain when it forks. |
|
@jlopp That's a great point. @harding So how's that going to work with this policy? What if I'm running a closed source wallet on the wallets page (or any other type of service or platform for that matter), that decides to leave concensus but no one knows because it's closed source, like Circle or Coinbase? Is this policy just going to penalize the open source community that departs from concensus but not do anything with the closed source ones because it can't be publicly known unless they disclose it? |
cryptonaut420
commented
Jun 16, 2015
|
This is disgusting actually. Bitcoin.org should not be a place to push your politics, and seeing how most of the people pushing for this right now are clearly biased on the block size debate... I don't know but this just seems shady as hell. How about keep things neutral, at the very least until there is actual code released and an actual attempt to fork the network? Seems premature otherwise. Is contentious the word of the day? |
@jlopp I agree that this is the only way to know for sure, but if you recall that the during large 2013 BDB locks fork, miners really wanted to know what side of the fork Mt. Gox was on. Presumably because they wanted to know whether or not the coins they mined would be valid to sell there. Assuming something similar would be the case now, miners will want to know what side of the fork will be chosen by large bitcoin-controlling organizations such as exchanges, Bitcoin banks, and web wallets. That means those services may have to disclose their planned polices to miners if they want them to adopt the hard fork. This isn't as much information symmetry as we'd get from reviewing code, but it's better than nothing. Furthermore, Bitcoin.org has generally attempted to discourage use of proprietary software and un-auditable services, as you may notice from looking at the Choose Your Wallet page, so the risk of penalizing only open source software seems reduced. However, I do think this is a good point, and that we'll have to monitor the situation to make sure we aren't significantly skewing incentives in an undesirable direction. Thank you! |
|
@harding It seems pretty clear that there is criticism of the current version of this PR from several people. Even though I am completely against it (obviously) there are others that say it needs work. It is quite hostile that you are saying it's going to be merged today or tomorrow and putting that kind of time limit on this discussion. There are a significant amount of contributors that may not even see this discussion in that time. I recommend you at least amend the conversation on this until the end of the month so more people have a chance to participate and add their feedback. |
|
This was not a vote, but a quick skim of the PR shows almost 3/4ths of the commentators known to me in favor of this PR (see below), so I'm going to merge momentarily. I will continue to review any comments left here and everyone should feel free to open pull requests improving the statement. Thank you everyone for your time and insightful commentary. Supports:
Opposes: Unclear to me: |
harding
merged commit a02f364
into
bitcoin-dot-org:master
Jun 16, 2015
1 check passed
|
@Coderwill Unfortunately with plan to begin causing a split in the blockchain for pre-announced today (though it looks like it slipped, it is still apparently planned according to posts on bitcoin-development a few hours ago), timeliness is somewhat tricky. Setting aside the recent short term drama, what part of the general principles presented here do you disagree with? (I do wonder if some of the opposition has actually read the text! ... because most of the comments have been specific to the justification given for a particular contentious hardfork rather than the general perspective provided). |
|
Mostly ACK, fwiw. |
|
ACK |
stevenwagner
commented
Jun 16, 2015
|
I found these quotes relevant to this discussion... "Forking is considered a Bad Thing—not merely because it implies a lot of wasted effort in the future, but because forks tend to be accompanied by a great deal of strife and acrimony between the successor groups over issues of legitimacy, succession, and design direction. There is serious social pressure against forking." — Eric S. Raymond, Jargon File (1991) "The ability to fork code – a central freedom of open source software – is what keeps communities vibrant and companies honest." ~Glyn Moody, Rebel Code: Linux and the Open Source Revolution (2001) I don't see anything virtuous about taking extra measures to try and protect oneself from the threat of forks. Those silly forkers! Of course we were already prepared with the solution! I rather not see bitcoin.org become used as a political tool to take stands against others. I agree with jgarzik. |
|
@stevenwagner Take care not to confuse forks of software which are fine and not disputed, with fork in the state of the consensus ledger responsible for protecting the security and soundness of everyone's Bitcoins. We use intentionally permissive licenses to maximize people's ability to control their own software and share it with others. We could choose to do otherwise, but we don't because we are strongly committed to the advantages that doing so provides, even though they come with considerable costs. This posting, however, is related to the integrity of Bitcoin's consensus ledger which must enforce a multitude of complex rules and rapidly collapse to a single state globally shared bit-identically among all users of the system in order to uphold the properties of the Bitcoin current and protect its users from inflation/double-spends, etc. While sure, we might also arguably be better off to avoid any avoidable software forking for resource allocation and cooperation reasons, the concern related to the ledger is of much greater gravity. |
nicholasconfer
commented
Jun 16, 2015
|
Very disappointing update. It's "I know it when I see it" all over again. |
robustus
commented
Jun 16, 2015
|
NACK For several reasons:
|
|
@gmaxwell I understand, and again, just to be clear, I don't support XT as the reason for dissenting on this PR. Bottom line - Bitcoin.org shouldn't be making policies about hard forks; it should strive to be neutral as the Mission states. At the very least, working toward a formative compromise on what should be a policy - certainly not merging 0-day ad-hoc policy changes with hardly any of that. I think we removed one sentence, fixed a typo and changed an adverb or something. This is no less "contentious" without "concensus" than the hard fork the blog post describes. |
randy-waterhouse
commented
Jun 16, 2015
|
ACK |
collegecrypto
commented
Jun 16, 2015
|
Is this something bitcoin.org has done in the past (take a strong position)? I like to refer noobs to this website because it is objective. This seems to deviate from the website's past direction, which I find concerning. I feel that Bitcoin.org needs to be somewhere where new users can find information about bitcoin without being swayed by opinions... |
|
@Coderwill the policy is neutral with regard to software and hard fork proposals---it applies to all of them equally. Neutrality between the concept of consensus hard forks and the concept of contentious hard forks doesn't make much sense to me. Consensus hard forks are dangerous, but at least we all agree to them. Contentious hard forks start with the same inherent dangers, are in opposition to many users' desires, and become more dangerous because users who can't agree may not be able to work together to fix problems---they may even go out of their way to cause problems! Looking at the four people I recorded as disagreeing in my list, I believe Mike is the only one who seems to be claiming that contentious hard forks have the same risks as consensus forks. (At least I don't see where you, Jameson, or Jeff commit to a statement like that.) If that's correct, this PR might currently be nearly 20:1 against the idea of controversial hard forks being an acceptably safe way to change the consensus rules. If contentious hard forks are not safe, it seems perfectly neutral for Bitcoin.org to not promote software or services that power them. |
|
@collegecrypto sure, we have a whole bunch of requirements for the wallets we list on the Chose Your Wallet page. These requirements help keep the Bitcoin.org resources you recommend maintained to a high quality. (And thank you for recommending the site!) |
|
@harding I understand your logic and it makes sense, but I don't think it's Bitcoin.org's position to be getting involved in hard fork politics, or especially for it to be getting into the business of proactively issuing policy notices about things that haven't happened. If that's the case we might as well go ahead and also put some policies out about contentious exchanges and wallets. Or contentious contributors. We're only throwing fuel on a fire with this blog post. The outcomes of underlying issues relating to concensus and hard forks aren't going to happen on Bitcoin.org - anything leading up to them shouldn't be happening here, either. They belong in the developer mailing list, or in one of several of the other venues that developers familiar with the matter are already congregating. Not on a website with one of the largest amounts of visitors who aren't. @theymos or @Cobra-Bitcoin - please correct me if I have a false sense of community here and it needs to be mentioned that you two reserve the right to act unilaterally with Bitcoin.org. I'm under the impression that it's possible to have constructive dialogue about topics like this without having to worry about getting vetoed by either of you should an aggregate sentiment differing from your own ever be reached. I was thinking Bitcoin.org was a map and not a megaphone. |
mishax1
commented
Jun 16, 2015
|
mikehearn: "What's more, you are inherently supporting a status quo in which a tiny number of people can veto any change to Bitcoin regardless of how widely supported it is by the rest of the community. That's not decentralisation. And it is ultimately far more dangerous to Bitcoin." And how exactly do you call the act of lobbying and pushing pools and companies to adopt Bitcoin XT ? |
tobysterling
commented
Jun 16, 2015
|
Hi @harding . I'm just some guy, but this comes from the bottom of my heart: |
coinx-ltc
commented
Jun 16, 2015
|
ACK. |
|
@mishax1 heh .... normally going around canvassing voters is called "democracy" |
kyuupichan
commented
Jun 16, 2015
|
Very disappointing and unnecessarily divisive, but effective in showing people's true colours. |
|
I think it is clear to developers, that an implementation which make an hard fork over the old consensus should rightly be called an altcoin, and not a "contentious hardfork". The big debate is whether it is OK to transfer the branding of "Bitcoin" to such altcoin, and if yes, in what condition. If you condition is : 90% of miners. Then I agree with you. But as long as BitcoinXT do not have 90% of miners, it should be considered an altcoin, and nothing in the website should promote it, as we don't promote litecoin. @harding Do you think such explanation would make the decision clearer in everybody's head ? I don't think it is particulary controversial to define what an altcoin is in such a way, and maybe remove the term "contentious hard fork" which may be harder to define. I may help to rewrite something among the line if we agree with the definition of what is an altcoin. |
|
@NicolasDorier maybe. @luke-jr seems to be recommending something similar, and I find he's very good at choosing clear terminology. On the other hand, I don't think altcoin or non-altcoin has anything to do with hash rate percentages---otherwise there would be no SHA256d altcoins because they'd all be switched to the Bitcoin block chain. For this reason, I liked Luke's simile between altcoins/hard forks and 51% attacks/soft forks. |
|
The principal thing I dislike about Luke's definition is that trying to define "contentious" based things impossible to measure (opnions of merchants, exchanges, developers) make the whole thing even harder to define. It gives more questions than answers. (which merchant/exchange is relevant, which is not) While any hash rate percentage is obvious to measure. However, if bitcoin main repo is planning an uncontroversial hardfork, then, by the same definition I gave, it should not be promoted until the hash rate is enough... in short, be considered like bitcoinxt, if we want the site to be truly impartial. Another alternative is to be clear that the website always promote wallets who are based on the rules as defined by the bitcoin main repository, and never other. Which makes sense and easy to define and understand. |
|
Keep in mind that if you have to ask exactly how do you define "contentious" in that situation, you probably have a contentious situation. |
|
Remixing an old joke about recursion: In order to understand contentious, one must first understand contentious. |
|
I'm taking the US Supreme Court's view on pornography as a guide: "I'll know it when I see it". |
|
A few more thoughts on this subject: Bitcoin is not a democracy; the entire point is that users are free to come and go, innovate, take risks, fail, succeed, whatever they individually or collectively decide. Thus I'm not certain that disenfranchisement is something that we should be concerned about. The gist of the proposed policy, from my perspective, is to pre-emptively shun members of the community who have already shown that they are willing to be shunned by forging a new path via a hard fork. Will it make a difference in the long run? I have no idea. I completely agree that hard forks are risky and that the safest course of action is to try to prevent them, even if doing so means implementing policies like this that feel passive aggressive and irk members of the community. However, this appears to me to be an issue of safety versus freedom and thus is more of an ideological debate than technical. Do we try to incentivize software makers to choose the objectively safer and time tested status quo or do we allow them to take risks that may result in rewards (or failure?) At the end of the day, Bitcoin is still permissionless. You can't stop a group from implementing code that supports a hard fork, and since this policy seems to be an attempt to do just that, it may be futile. Thought experiment: if a group were to implement code that results in a hard fork but the conditions resulting in the fork won't be met for a decade, is that software still Bitcoin? IMO it is still Bitcoin until the fork actually occurs. As for which side is Bitcoin post-fork, that seems to be worthy of its own debate. |
|
@jlopp Whatever this is doing, it surely shouldn't be used to "shun" or "shame", but educate and guide.
If no education can be achieved before the fork happens, it's useless, imo. |
OmniEdge
commented
Jun 16, 2015
|
This debate reminds of how semantics and self-interest can cloud our judgement. It almost feels like a climate change debate. In data we trust and yes this whole debate is contentious. Bitcoin.org is trying to stay neutral and I have no problem with the new policy for Bitcoin.org regarding contentious hard forks. |
schildbach
commented on the diff
Jun 16, 2015
| +fork feeling disenfranchised. At the very worst, it will make bitcoins | ||
| +permanently lose their value. In between are many possible outcomes, but | ||
| +none of them are good. | ||
| + | ||
| +The danger of a contentious hard fork is potentially so significant | ||
| +that Bitcoin.org has decided to adopt a new policy: | ||
| + | ||
| +> Bitcoin.org will not promote software or services that will leave the | ||
| +> previous consensus because of an intentional and contentious hard fork attempt. | ||
| + | ||
| +This policy applies to full node software, such as Bitcoin Core, | ||
| +software forks of Bitcoin Core, and alternative full node | ||
| +implementations. | ||
| + | ||
| +It also applies to wallets and services that have the ability to detect | ||
| +the contentious hard fork, and which release code or make announcements |
|
|
aalness
commented
Jun 16, 2015
|
Late NACK. I'm a fairly technical person. I've helped implement a bitcoin node and written code for most of my life. I understand both sides of the argument. If politics fail the only recourse is to exit via fork. It is a deeply democratic option which is in the true spirit of bitcoin. |
|
@aalness note, this policy isn't about software forks. Most (all?) of us are hard-core open source users/developers who deeply appreciate the software fork safety valve. It's one reason that both Bitcoin Core and Bitcoin.org are MIT-licensed. (Note: Bitcoin.org includes trademarks and some images that are proprietary.) This policy is about a very specific type of block chain fork that could be damaging to all Bitcoin users. There are some additional details here: https://bitcoin.org/en/developer-guide#consensus-rule-changes |
aalness
commented
Jun 16, 2015
|
@harding like I mentioned, I took part in a project which implements a full bitcoin node so I'm intimately familiar with the consensus rules and their purpose along with the potential effects of changing them to be inconsistent with the majority of the network. I'm not a particularly vocal person and don't like attention so it is likely you have never heard of me and probably won't hear much from me in the future either. Things Mike and Gavin have said recently have resonated with me so FWIW I felt obliged to offer my two cents in an attempt to indicate that there are technical people out there who aren't active in the forums but agree with some of the spirit of things they are saying. I guess a silent minority? I'm unsure of our numbers. Given there is no concrete and meaningful definition of "contentious" offered I don't understand what I'm supposed to do with the specific information presented. In the interest of disclosure, I don't recognize any authority of bitcoin.org, Bitcoin Core, Mike, Gavin, Satoshi, Jesus or any other individual or group over the Bitcoin experiment. If people are this threatened by two people promoting an alternate form of the software, including changes to the consensus rules, it triggers my bullshit spidey senses. This fear suggests a fragility which if real would make the security of bitcoin appear too laughable to be considered for any serious use and renders a technical discussion on scaling moot. |
n0n3such
commented
Jun 16, 2015
|
It is clear that there is no consensus on the issues debated here. Irrespective of the validity of the individual arguments, proceeding without consensus sets a bad precedent and increases the risk that additional future changes will be introduced without consensus. |
|
@jlopp sorry for the delay responding.
Whose choice puts whose safety at risk? You choosing to risk your money in an unsafe investment is fine by me. But you choosing to risk my money isn't appropriate. Bitcoin is a consensus system---it only works if we all agree about who owns what, and if we can do that relatively quickly even in the event of major problems. The March 2013 extended fork shows that's possible to restore consensus after a major problem when there is a shared vision for how Bitcoin should work. But what if there isn't a shared vision? It seems clear to me that Bitcoin's resiliency would be greatly reduced. This brings us to what is now the first paragraph of the statement. If a contentious hard fork should occur and Bitcoin's consensus isn't stressed, then maybe all we have are some people feeling disenfranchised because the system was changed without their consent. That's not good, but we can hope time will heal those wounds. But if a contentious hard fork should occur and consensus become fractured, either during the fork or because of some event afterward, Bitcoin would be in danger of never again reestablishing the same level of consensus, and consequently losing some or all of its value. You may recall how fast the price dropped during the March 2013 fork (see below). That was with developers, miners, and merchants all collaboratively trying to resolve the problem. Imagine if that was not the case.
So, yes, thanks to Bitcoin Core being open source software and Bitcoin being an open protocol, there exists a lot of freedom of choice here---but some choices contain significant moral hazard. It is not just the value of the forkers' bitcoins at risk, but the value of everyone's bitcoins. |
|
Good points; I still think that we both agree about the risks involved, and that it is in all of our best interests to remain in consensus. Interesting point about moral hazard - that implies that hard fork proponents are more willing to take the risk because it puts the burden of the risk onto status quo consensus proponents. Upon further reflection, it seems to me that the risk borne by hard fork proponents is inversely proportional to the percentage of the ecosystem that supports the fork. That is, if a handful of entities decide to hard fork then they are taking all of the risk and placing little upon Bitcoin, whereas if a majority of entities decide to hard fork then they are placing most of the risk on the minority who remain on the old side of the fork. Is that desirable? Certainly not. But that's how the system works; by using the system we are accepting these risks, by enacting this policy bitcoin.org is attempting to mitigate the risks. In a sense, isn't the risk inherent to a contentious hard fork similar to Mutually Assured Destruction? MAD seems to have worked reasonably well so far... both sides know the risks involved and are incentivized to come to a consensus, lest they risk irreparably destroying everything. So, in terms of nuclear warfare, I think that MAD is sufficient incentive while policies like this are akin to a pre-emptive strike. It might work, or it might only result in further divisiveness. |
ABISprotocol
commented
Jun 17, 2015
|
Late ACK. See also my statement regarding this on reddit. And also, thank you to all of those entities who supported this position as developed for bitcoin.org ~ and I hope that the discussion continues in bitcoin-development as to how to counter risky proposals and develop ways to avoid or prevent them in the future. |
harding commentedJun 15, 2015
This blog post introduces a new policy for Bitcoin.org regarding contentious hard forks:
Full explanation can be found in the blog post itself using the GitHub diff on the screenshot preview below.
This statement, or earlier revisions of it, has been reviewed by the following persons:
We also feel that this statement reflects the published sentiments of many of Bitcoin.org's active reviewers, and we invite them to individually ACK this PR if that is the case. If a sufficient number ACK this PR today, we will merge today. If not, we will merge tomorrow (Tuesday) unless unexpected criticism is received.