Blog: Bitcoin.org Position On Hard Forks #894
Conversation
|
"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).
|
|
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. |
|
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. |
|
ACK |
|
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. |
|
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 ? |
|
Hi @harding . I'm just some guy, but this comes from the bottom of my heart: |
|
ACK. |
|
@MishaX1 heh .... normally going around canvassing voters is called "democracy" |
|
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. |
|
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. |
| 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 |
There was a problem hiding this comment.
How do you check closed source? Or web-wallets?
There was a problem hiding this comment.
@schildbach addressed here
|
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 |
|
@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. |
|
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. |
|
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. |
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.