{"type":"rich","version":"1.0","author_name":"npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","author_url":"https://nostr.ae/npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfj","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-15\n📝 Original message:Hi Mike\n\nWell thank you for replying openly on this topic, its helpful.\n\nI apologise in advance if this gets quite to the point and at times\nblunt, but transparency is important, and we owe it to the users who\nsee Bitcoin as the start of a new future and the$3b of invested funds\nand $600m of VC funds invested in companies, we owe it to them that we\nbe open and transparent here.\n\nI would really prefer on a personal nor professional basis to be\nhaving this conversation period, never mind in public, but Mike - your\nand Gavin's decision to promote a unilateral hard-fork and code fork\nare extremely high risk for bitcoin and so there remains little\nchoice.  So I apologise again that we have to have this kind of\nconversation on a technical discussion list.  This whole thing is\nhugely stressful and worrying for developers, companies and investors.\n\nI strongly urge that we return to the existing collaborative\nconstructive review process that has been used for the last 4 years\nwhich is a consensus by design to prevent one rogue person from\ninserting a backdoor, or lobbying for a favoured change on behalf of a\nspecial interest group, or working for bad actor (without accusing you\nof any of those - I understand you personally just want to scale\nbitcoin, but are inclined to knock heads and try to force an issue you\nsee, rather than work collaboratively).\n\nFor you (and everyone)\n\n- Should there be a summit of some kind, that is open attendance, and\nvideo recorded so that people who are unable to attend can participate\ntoo, so that people can present the technical proposals and risks in\nan unbiased way?\n\n(It is not theoretical question, I may have a sponsor and host - not\nBlockstream, an independent, its a question for everyone, developers,\nusers, CTOs, CEOs.)\n\n\n\nSo here I come back to more frank questions:\n\nGovernance\n\nThe rest of the developers are wise to realise that they do not want\nexclusive control, to avoid governance centralising into the hands of\none person, and this is why they have shared it with a consensus\nprocess over the last 4 years.  No offence but I dont think you\npersonally are thinking far enough ahead to think you want personal\ncontrol of this industry.  Maybe some factions dont trust your\nmotives, or they dont mind, but feel more assured if a dozen other\npeople are closely reviewing and have collective review authority.\n\n- Do you understand that attempting to break this process by\nunilateral hard-fork is extremely weakening of Bitcoin's change\ngovernance model?\n\n- Do you understand that change governance is important, and that it\nis important that there be multiple reviewers and sign-off to avoid\nsomeone being blackmailed or influenced by an external party - which\ncould potentially result in massive theft of funds if something were\nmissed?\n\n- Secondarily do you understand that even if you succeed in a\nunilateral fork (and the level of lost coins and market cap and damage\nto confidence is recoverable), that it sets a precedent that others\nmay try to follow in the future to introduce coercive features that\nbreak the assurances of bitcoin, like fungibility reducing features\nsay (topically I hear you once proposed on a private forum the concept\nof red-lists, other such proposals have been made and quickly\nabandoned), or ultimately if there is a political process to obtain\nunpopular changes by unilateral threat, the sky is the limit - rewrite\nthe social contract at that point without consensus, but by\ncalculation that people will value Bitcoin enough that they will\nfollow a lead to avoid risk to the system?\n\n\nSecurity\n\nAs you probably know some extremely subtle bugs in Bitcoin have at\ntimes slipped past even the most rigorous testings, often with\ninnocuous but unexpected behaviours, but some security issues  Some\nextremely intricate and time-sensitive security defect and incident\nresponse happens from time to time which is not necessarily publicly\ndisclosed until after the issue has been rolled out and fixed, which\ncan take some time due to the nature of protocol upgrades,\nwork-arounds, software upgrade via contacting key miners etc.  We\ncould take an example of the openSSL bug.\n\n- How do you plan to deal with security \u0026 incident response for the\nduration you describe where you will have control while you are\ndeploying the unilateral hard-fork and being in sole maintainership\ncontrol?\n\n- Are you a member of the bitcoin security reporting list?\n\nOn 15 June 2015 at 11:56, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e I will review both and mostly delegate to Gavin's good taste around the\n\u003e details, unless there is some very strong disagreement. But that seems\n\u003e unlikely.\n\u003e ...\n\u003e Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests\n\u003e aren't scored in any way. The final decision rests with the maintainer as in\n\u003e ~all open source projects.\n\nAs you know the people who have written 95% of the code (and reviewed,\nand tested, and formally proved segments etc) are strenuously advising\nnot to push any consensus code into public use without listening to\nand addressing review questions which span beyond rigorous code \u0026\nautomated guided fuzz testers, simulation and sometimes formal proofs,\nbut also economics, game-theory and critically very subtle\ndeterminism/consensus safety that they have collectively 4-5 years\nexperience of each.\n\n- Will you pause your release plans if all of the other developers\ninsist that the code or algorithm is defective?\n\n- Please don't take this the wrong way, and I know your bitcoinj work\nwas a significant engineering project which required porting bitcoin\nlogic.  But If the answer to the above question is no, as you seemed\nto indicate in your response, as you not have not written much bitcoin\ncore code yourself (I think 3 PRs in total), do you find yourself more\nqualified than the combination of peer review of the group of people\nwho have written 95% of it, and maintained it and refactored most of\nit over the last 4-5 years?\n\nI presume from your security background you are quite familiar with\nthe need for review of crypto protocol changes \u0026 rigorous code review.\nThat is even more the case with Bitcoin given the consensus\ncriticality.\n\n\u003e\u003e - On the idea of a non-consensus hard-fork at all, I think we can\n\u003e\u003e assume you will get a row of NACKs.  Can you explain your rationale\n\u003e\u003e for going ahead anyway?  The risks are well understood and enormous.\n\u003e\n\u003e If Bitcoin runs out of capacity it will break and many of our users will\n\u003e leave. That is not an acceptable outcome for myself or the many other\n\u003e wallet, service and merchant developers who have worked for years to build\n\u003e an ecosystem around this protocol.\n\nThat you are frustrated, is not a sufficient answer as to why you are\nproposing to go ahead with a universally acknowledged extreme network\ndivergence danger unilateral hard-fork, lacking wide-spread consensus.\nPeople are quite concerned about this.  Patience, caution and prudence\nis necessary in a software system with such high assurance\nrequirements.\n\nSo I ask again:\n\n- On the idea of a non-consensus hard-fork at all, I think we can\nassume you will get a row of NACKs.  Can you explain your rationale\nfor going ahead anyway?  The risks are well understood and enormous.\n\nNote the key point is that you are working on a unilateral hard-fork,\nwhere there is a clear 4 year established process for proposing\nimprovements and an extremely well thought out and important change\nmanagement governance process.  While there has been much discussion,\nyou nor Gavin, have not actually posted a BIP for review.  Nor\nactually was much of the discussion even conducted in the open: it was\nonly when Matt felt the need to clear the air and steer this\nconversation into the open that discussion arose here.  During that\nperiod of private discussion you and Gavin were largely unknown to\nmost of us lobbying companies with your representation of a method\nthat concerns everyone of the Bitcoin users.  Now that the technical\ncommunity aware aware they are strenuously discouraging you on the\nbasis of risks.\n\n\nOpenness\n\n- Do you agree that bitcoin technical discussions should happen in the open?\n\n- As this is a FOSS project, do you agree that companies should also\nbe open, about their requirements and trade-offs they would prefer?\n\n- Can you disclose the list of companies you have lobbied in private\nwhether they have spoken publicly or not, and whether they have\nindicated approval or not?\n\n- Did you share a specific plan, like a BIP or white paper with these\ncompanies, and if so can we see it?\n\n- If you didnt submit a plan, could you summarise what you asked them\nand what you proposed, and if you discussed also the risks?  (If you\nasked them if they would like Bitcoin to scale, I expect almost\neveryone does, including every member of the technical community, so\nthat for example would not fairly indicate approval for a unilateral\nhard-fork)\n\nI and others will be happy to talk with the CTO and CEOs of companies\nyou have lobbied in private, for balance to assure ourselves and the\nrest of the community that their support was given - and with full\nunderstanding of the risks of doing it unilaterally, without peer\nreview, benefit of maintenance and security inidence management, and\nwhat exactly they are being quoting as having signed up for.\n\n(This maybe more efficiently and openly achieved by the open process,\non a mailing list, maybe a different one even special purpose to this\ntopic, with additional option of the open public meeting I proposed at\nthe top).\n\n- Do you agree that it would be appropriate, that companies be aware\nof both the scaling opportunities (of course, great everyone wants\nscalability) as well as the technical limits and risks with various\napproaches?  And that these be presented by parties from a range of\nviews to ensure balance?\n\n- Do you consider your expression of issues to hold true to the ideal\nof representing balanced nuanced view of all sides of a technical\ndebate, even when under pressure or feeling impatient about the\nprocess?\n\nYou may want to review the opening few minutes of your epicenter 82\nbitcoin for example where you claimed and I quote \"[the rest of the\ntechnical community] dont want capacity to ever increase and want it\nto stay where it is and when it fills up people move to other\nsystems\".\n\n- Do you think that is an accurate depiction of the complex trade-offs\nwe have been discussing on this list?\n\n(For the record I am not aware of a single person who has said they do\nnot agree with scaling Bitcoin.  Changing a constant is not the\nhard-part.  The hard part is validating a plan and the other factors\nthat go into it.  It's not a free choice it is a security/scalability\ntradeoff.  No one will thank us if we \"scale\" bitcoin but break it in\nhard to recover ways at the same time.)\n\n- Were you similarly balanced in your explanations when talking to\ncompanies in private discussions?\n\n- Do you understand that if we do not work from balanced technical\ndiscussion, that we may end up with some biased criteria?\n\nAuthority\n\nNeither you nor Gavin have any particular authority here to speak on\nbehalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is\ndev lead, and you and Gavin are both well aware of the 4 year\nestablished change management consensus decision making model where\nall of the technical reviewers have to come to agreement before\nchanges go in for security reasons explained above).  I know Gavin has\na \"Chief Scientist\" title from the Bitcoin Foundation, but sadly that\norganisation is not held in as much regard as it once was, due to\nvarious irregularities and controversies, and as I understand it no\nlonger employs any developers, due to lack of funds.  Gavin is now\nemployed by MIT's DCI project as a researcher in some capacity.  As\nyou know Wladimir is doing the development lead role now, and it seems\npart of your personal frustration you said was because he did not\nagree with your views.  Neither you nor Gavin have been particularly\ninvolved in bitcoin lately, even Gavin, for 1.5 years or so.\n\n- Do you agree that if you presume to speak where you do not have\nauthority you may confuse companies?\n\n\u003e If Bitcoin runs out of capacity it will break and many of our users will\n\u003e leave. That is not an acceptable outcome for myself or the many other\n\u003e wallet, service and merchant developers who have worked for years to build\n\u003e an ecosystem around this protocol.\n\nBut I think this is a false dichotomy.  As I said in previous mail I\nunderstand people are frustrated that it has taken so long, but it is\nnot the case that no progress has been made on scalability.\n\nI itemised a long list of scalability work which you acknowledged as\nimpressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP\nfee work, fee-estimation, and so on, which you acknowledged and are\naware of.\n\nThere are multiple proposals and BIPs under consideration on the list right now.\n\n- what is the reason that you (or Gavin) would not post your BIP along\nside the others to see if it would win based on technical merit?\n\n- why would you feel uniquely qualified to override the expert opinion\nof the rest of the technical community if your proposal were not\nconsidered to have most technical merit? (Given that this is not a\nsimple market competition thing where multiple hard-forks can be\nconsidered - it is a one only decision, and if it is done in a\ndivisive unilateral way there are extreme risks of the ledger\ndiverging.)\n\nNetwork Divergence Risk\n\n\u003e\u003e - How do you propose to deal with the extra risks that come from\n\u003e\u003e non-consensus hard-forks?  Hard-forks themselves are quite risky, but\n\u003e\u003e non-consensus ones are extremely dangerous for consensus.\n\u003e\n\u003e The approach is the same for other forks. Voting via block versions and then\n\u003e when there's been \u003eX% for Y time units the 1mb limit is lifted/replaced.\n\nBut this is not a soft-fork, it is a hard-fork.  Miner voting is only\nperipherally related.  Even if in the extremis 75% of miners tried a\nunilateral hard-fork but 100% of the users stayed on the maintained\noriginal code, no change would occur other than those miners losing\nreward (mining fork-coins with no resale value) and the difficulty\nwould adjust.  The miners who made an error in choice would lose money\nand go out of business or rejoin the chain.\n\nHowever if something in that direction happens with actual users and\ncompanies on both sides of it users will lose money, the ledger will\ndiverge as soon as a single double-spend happens, and never share a\nblock again, companies will go instantly insolvent, and chaos will\nbreak out.  This is the dangerous scenario we are concerned about.\n\nSo the same question again:\n\n- How do you propose to deal with the extra risks that come from\nnon-consensus hard-forks?  Hard-forks themselves are quite risky, but\nnon-consensus ones are extremely dangerous for consensus.\n\n\nBeing sensitive to alarming the market\n\nIt is something akin to Greece or Portugal or Italy exiting the euro\ncurrency in a disorderly way.  Economists and central bank policy\nmakers are extremely worried about such an eventuality and talk about\nrelated factors in careful, measured terms, watch Mario Draghi when he\nspeaks.\n\nImagine that bitcoin is 10x or 100x bigger.  Bitcoin cant have people\ntaking unilateral actions such as you have been proposing.  It is not\nfollowing the consensus governance process, and not good policy and it\nis probably affecting bitcoin confidence and price at this moment.\n\n\u003e\u003e - Do you have contingency plans for what to do if the non-consensus\n\u003e\u003e hard-fork goes wrong and $3B is lost as a result?\n\u003e\n\u003e Where did you get the $3B figure from? The fork either doesn't happen, or it\n\u003e happens after quite a long period of people knowing it's going to happen -\n\u003e for example because their full node is printing \"You need to upgrade\"\n\u003e messages due to seeing the larger block version, or because they read the\n\u003e news, or because they heard about it via some other mechanisms.\n\nThis is not a soft-fork, and the community will not want to take the\nrisks once they understand them, and they have months in which to\nunderstand them and at this point you've motivated and wasted 100s of\ndeveloper man hours such that we will feel impelled to make sure that\nno one opts into a unilateral hard-fork without understanding the\nrisks.  It would be negligent to allow people to do that.  Before this\ngets very far FAQs will be on bitcoin.org etc explaining this risk I\nwould imagine.  Its just starting not finished.\n\nWhat makes you think the rest of the community may not instead prefer\nJeff Garzik's BIP after revisions that he is making now with review\ncomments from others?\n\nOr another proposal.  Taken together with a deployment plan that sees\nwork on decentralisation tying into that plan.\n\n- If you persisted anyway, what makes you think bitcoin could not make\ncode changes defensively relating to your unilateral fork?\n(I am sure creative minds can find some ways to harden bitcoin against\na unilateral fork, with a soft-fork or non-consensus update can be\ndeployed much faster than a hard-fork).\n\nI tried to warn Gavin privately that I thought he was under-estimating\nthe risk of failure to his fork proposal due to it being unilateral.\nIe as you both seem sincere in your wish to have your proposal\nsucceed, then obviously the best way to do that is to release a BIP in\nthe open collaborative process and submit it to review like everyone\nelse.  Doing it unilaterally only increases its chance of failure.\n\nThe only sensible thing to do here is submit a BIP and stop the\nunilateral fork threat.\n\nScalability Plans\n\n\u003e Let me flip the question around. Do you have a contingency plan if Bitcoin\n\u003e runs out of capacity and significant user disruption occurs that results in\n\u003e exodus, followed by fall in BTC price? The only one I've seen is \"we can\n\u003e perform an emergency hard fork in a few weeks\"!\n\nYes people have proposed other plans.  Bryan Bishop posted a list of them.\n\nJeff Garzik has a proposal, BIP-100 which seems already better than\nGavin's having benefit of peer review which he has been incorporating.\n\nI proposed several soft-fork models which can be deployed safely and\nimmediately, which do not have ledger risk.\n\nI have another proposal relating to simplified soft-fork one-way pegs\nwhich I'll write up in a bit.\n\nI think there are still issues in Jeff's proposal but he is very open\nand collaborating and there maybe related but different proposals\npresently.\n\n\u003e\u003e As you can probably tell I think a unilateral fork without wide-scale\n\u003e\u003e consensus from the technical and business communities is a deeply\n\u003e\u003e inadvisable.\n\u003e\n\u003e Gavin and I have been polling many key players in the ecosystem. The\n\u003e consensus you seek does exist. All wallet developers (except Lawrence), all\n\u003e the major exchanges, all the major payment processors and many of the major\n\u003e mining pools want to see the limit lifted (I haven't been talking to pools,\n\u003e Gavin has).\n\nIt does not seem to me that you understand the issue.  Of course they\nwant to increase the scalability of bitcoin.  So does everyone else on\nthis mailing list.\n\nThat they would support that is obvious.  If you presented your\nunilateral action plan without explaining the risks too.\n\nI think I covered this further above.  If you would like to share the\ncompany list, or we can invite them to the proposed public physical\nmeeting, I think it would be useful for them to have a balanced view\nof the ledger divergence risks, and alternative in-consensus proposals\nunderway, as well as the governance risks, maintenance risks, security\nincident risks.\n\nNote that other people talk to companies too, as part of their day to\nday jobs, or from contacts from being in the industry.  You have no\nspecial authority or unique ability to talk with business people.  Its\njust that the technical community did not know you were busy doing\nthat.\n\nI can not believe that any company that would listen to their CTO, CSO\nor failing that board would be ok with the risks implied by what you\nare proposing on full examination.\n\n\u003e This notion that the change has no consensus is based on you polling the\n\u003e people directly around you and people who like to spend all day on this\n\u003e mailing list. It's not an accurate reflection of the wider Bitcoin community\n\u003e and that is one of the leading reasons there is going to be a fork. A small\n\u003e number of people have been flatly ignoring LOTS of highly technical and\n\u003e passionate developers who have written vast amounts of code, built up the\n\u003e Bitcoin user base, designed hardware and software, and yes built companies.\n\nI know you want scale bitcoin, as I said everyone here does. I think\nwhat you're experiencing is that you've had more luck explaining your\npragmatic unilateral plan to non-technical people without peer review,\nand so not experienced the kind of huge pushback you are getting from\nthe technical community.  The whole of bitcoin is immensely\ncomplicated such that it takes an uber-geek CS genius years to\ncatchup, this is not a slight of any of the business people who are\nworking hard to deploy Bitcoin into the world, its just complicated\nand therefore not easy to understand the game-theory, security,\ngovernance and distributed system thinking.  I have a comp sci PhD in\ndistributed systems, implemented p2p network systems and have 2\ndecades of applied crypto experience with a major interest in\nelectronic cash crypto protocols, and it took me a several years to\ncatchup and even I have a few hazy spots on low-level details, and I\naddictively into read everything I could find.  Realistically all of\nus are still learning, as bitcoin combines so many fields that it\nopens new possibilities.\n\nWhat I am expecting that yourself and Gavin are thinking is that\nyou'll knock heads and force the issue and get to consensus.\n\nHowever I think you have seriously misjudged the risks and have not\nadequately explained them to companies you are talking with.  Indeed\nyou do not fully seem to acknowledge the risks, nor to have a well\nthought out plan here of how you would actually manage it, nor the\nmoral hazards of having a lone developer in hugely divisive\ncircumstances in sole control of bitcoins running code.  Those are\nexactly the reasons for the code change governance process!\n\nEven though you are trying to help, the full result is you are not\nhelping achieve anything by changing a constant and starting a\nunilateral hard-fork (not to trivialise the work of making a patch to\ndo that).\n\nThe work to even make the constant change be feasible was a result of\n1000s of hours of work by others in the development community, that is\nemphatically and unilaterally telling you that hard-forks are hugely\ninadvisable.\n\nYou are trying to break the code change governance security procedure\nthat were put in place for good reason for the security of $3b of\nother peoples money, even if you have a pragmatic intent to help, this\nis flat out unacceptable.\n\nThere are also security implications to what you are proposing, which\nI have heard you attempting to trivialise, that are core to Bitcoins\nsecurity and core functionality.\n\n\u003e  the overwhelming impression I get from a few\n\u003e others here is that no, they don't want to scale Bitcoin. They already\n\u003e decided it's a technological dead end.\n\nI think this is a significant mischaracterisation, and I think almost\neverybody is on board with a combination plan:\n\n1. work to improve decentralisation (specific technical work already\nunderway, and education)\n2. create a plan to increase block-size in a slow fashion to not cause\nsystem shocks (eg like Jeff is proposing or some better variant)\n3. work on actual algorithmic scaling\n\nIn this way we can have throughput needed for scalability and security\nwork to continue.\n\nAs I said you can not scale a O(n^2) broadcast network by changing\nconstants, you need algorithmic improvements.\n\nPeople are working on them already.  All of those 3 things are being\nactively worked on RIGHT NOW, and in the case of algorithmic scaling\nand improve decentralisation have been worked on for months.\n\nYou may have done one useful thing which is to remind people that\nblocks are only 3x-4x below capacity such that we should look at it.\n\nBut we can not work under duress of haste, nor unilateral ultimatums,\nthis is the realm of human action that leads to moral hazard, and\nironically reminds us of why Satoshi put the quote in the genesis\nblock.\n\nBitcoin is too complex a system with too much at stake to be making\npolitical hasty decisions, it would be negligent to act in such a way.\n\nAgain please consider that you did your job, caused people to pay\nattention, but return to the process, submit a BIP, retract the\nunilateral hard-fork which is so dangerous and lets have things be\ncalm, civil and collaborative in the technical zone of Bitcoin and not\nfurther alarm companies and investors.\n\nAdam"}