diff options
author | Pindar Wong <pindar.wong@gmail.com> | 2015-06-16 20:33:31 +0800 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2015-06-16 12:33:42 +0000 |
commit | c679f1ba814ce433395fd7fb0ebf36421086e07e (patch) | |
tree | a19873b4a969f85b95ed3dfdf9c8c32ba9c360ca | |
parent | be882ffd906f9b1158a34cb31c64d12731ecdf07 (diff) | |
download | pi-bitcoindev-c679f1ba814ce433395fd7fb0ebf36421086e07e.tar.gz pi-bitcoindev-c679f1ba814ce433395fd7fb0ebf36421086e07e.zip |
Re: [Bitcoin-development] questions about bitcoin-XT code fork & non-consensus hard-fork
-rw-r--r-- | 9e/5a9e28ce0d7a044cdd6ad9bdaca4f56f8c316b | 1280 |
1 files changed, 1280 insertions, 0 deletions
diff --git a/9e/5a9e28ce0d7a044cdd6ad9bdaca4f56f8c316b b/9e/5a9e28ce0d7a044cdd6ad9bdaca4f56f8c316b new file mode 100644 index 000000000..d7f4dd421 --- /dev/null +++ b/9e/5a9e28ce0d7a044cdd6ad9bdaca4f56f8c316b @@ -0,0 +1,1280 @@ +Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] + helo=mx.sourceforge.net) + by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <pindar.wong@gmail.com>) id 1Z4q3i-0006Mf-FZ + for bitcoin-development@lists.sourceforge.net; + Tue, 16 Jun 2015 12:33:42 +0000 +Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.212.177 as permitted sender) + client-ip=209.85.212.177; envelope-from=pindar.wong@gmail.com; + helo=mail-wi0-f177.google.com; +Received: from mail-wi0-f177.google.com ([209.85.212.177]) + by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1Z4q3d-00031F-VZ + for bitcoin-development@lists.sourceforge.net; + Tue, 16 Jun 2015 12:33:42 +0000 +Received: by wicnd19 with SMTP id nd19so51731884wic.1 + for <bitcoin-development@lists.sourceforge.net>; + Tue, 16 Jun 2015 05:33:32 -0700 (PDT) +MIME-Version: 1.0 +X-Received: by 10.180.82.162 with SMTP id j2mr6580637wiy.54.1434458011865; + Tue, 16 Jun 2015 05:33:31 -0700 (PDT) +Received: by 10.194.2.237 with HTTP; Tue, 16 Jun 2015 05:33:31 -0700 (PDT) +In-Reply-To: <CALqxMTFC7zBN9GvHAZLQj4SbXjzkCAM9meSErd3qn7uCoON98Q@mail.gmail.com> +References: <CALqxMTGBt7MNs5YWf8QzKe+4Fr-uKVimf8=VbytBANEDm=s50g@mail.gmail.com> + <CANEZrP31AEson9DZ=ZU7d4t=DvmGodh1ja6EaZ6xQZ3bFEXeVA@mail.gmail.com> + <CALqxMTFC7zBN9GvHAZLQj4SbXjzkCAM9meSErd3qn7uCoON98Q@mail.gmail.com> +Date: Tue, 16 Jun 2015 20:33:31 +0800 +Message-ID: <CAM7BtUoNJ3vPqW9esCBo8XSN=yRjC3oheP_hd_kcgzs0_0De6w@mail.gmail.com> +From: Pindar Wong <pindar.wong@gmail.com> +To: Adam Back <adam@cypherspace.org> +Content-Type: multipart/alternative; boundary=f46d044288043e18a10518a1c889 +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (pindar.wong[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature + 0.0 LOTS_OF_MONEY Huge... sums of money + 0.0 T_MONEY_PERCENT X% of a lot of money for you +X-Headers-End: 1Z4q3d-00031F-VZ +Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net> +Subject: Re: [Bitcoin-development] questions about bitcoin-XT code fork & + non-consensus hard-fork +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Tue, 16 Jun 2015 12:33:42 -0000 + +--f46d044288043e18a10518a1c889 +Content-Type: text/plain; charset=UTF-8 + +On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <adam@cypherspace.org> wrote: + +> Hi Mike +> +> Well thank you for replying openly on this topic, its helpful. +> +> I apologise in advance if this gets quite to the point and at times +> blunt, but transparency is important, and we owe it to the users who +> see Bitcoin as the start of a new future and the$3b of invested funds +> and $600m of VC funds invested in companies, we owe it to them that we +> be open and transparent here. +> +> I would really prefer on a personal nor professional basis to be +> having this conversation period, never mind in public, but Mike - your +> and Gavin's decision to promote a unilateral hard-fork and code fork +> are extremely high risk for bitcoin and so there remains little +> choice. So I apologise again that we have to have this kind of +> conversation on a technical discussion list. This whole thing is +> hugely stressful and worrying for developers, companies and investors. +> +> I strongly urge that we return to the existing collaborative +> constructive review process that has been used for the last 4 years +> which is a consensus by design to prevent one rogue person from +> inserting a backdoor, or lobbying for a favoured change on behalf of a +> special interest group, or working for bad actor (without accusing you +> of any of those - I understand you personally just want to scale +> bitcoin, but are inclined to knock heads and try to force an issue you +> see, rather than work collaboratively). +> +> For you (and everyone) +> +> - Should there be a summit of some kind, that is open attendance, and +> video recorded so that people who are unable to attend can participate +> too, so that people can present the technical proposals and risks in +> an unbiased way? +> +> +Dear Adam, All: + +At the community's convenience, it would be an honour to arrange an initial +open summit to meet with representatives of the Chinese miners in Hong Kong +(UTC+8) to facilitate a better understand between the different +stakeholders of the Bitcoin ecosystem on this important issue. This could +be arranged for this October, or earlier, if deemed necessary. + +Remote online participation would be welcome from those who might not be +able to attend in person. + +However, it is hoped that such a meeting would be primarily document +driven to facilitate orderly translation, discussion and decision. + +p. + + + +> (It is not theoretical question, I may have a sponsor and host - not +> Blockstream, an independent, its a question for everyone, developers, +> users, CTOs, CEOs.) +> +> +> +> So here I come back to more frank questions: +> +> Governance +> +> The rest of the developers are wise to realise that they do not want +> exclusive control, to avoid governance centralising into the hands of +> one person, and this is why they have shared it with a consensus +> process over the last 4 years. No offence but I dont think you +> personally are thinking far enough ahead to think you want personal +> control of this industry. Maybe some factions dont trust your +> motives, or they dont mind, but feel more assured if a dozen other +> people are closely reviewing and have collective review authority. +> +> - Do you understand that attempting to break this process by +> unilateral hard-fork is extremely weakening of Bitcoin's change +> governance model? +> +> - Do you understand that change governance is important, and that it +> is important that there be multiple reviewers and sign-off to avoid +> someone being blackmailed or influenced by an external party - which +> could potentially result in massive theft of funds if something were +> missed? +> +> - Secondarily do you understand that even if you succeed in a +> unilateral fork (and the level of lost coins and market cap and damage +> to confidence is recoverable), that it sets a precedent that others +> may try to follow in the future to introduce coercive features that +> break the assurances of bitcoin, like fungibility reducing features +> say (topically I hear you once proposed on a private forum the concept +> of red-lists, other such proposals have been made and quickly +> abandoned), or ultimately if there is a political process to obtain +> unpopular changes by unilateral threat, the sky is the limit - rewrite +> the social contract at that point without consensus, but by +> calculation that people will value Bitcoin enough that they will +> follow a lead to avoid risk to the system? +> +> +> Security +> +> As you probably know some extremely subtle bugs in Bitcoin have at +> times slipped past even the most rigorous testings, often with +> innocuous but unexpected behaviours, but some security issues Some +> extremely intricate and time-sensitive security defect and incident +> response happens from time to time which is not necessarily publicly +> disclosed until after the issue has been rolled out and fixed, which +> can take some time due to the nature of protocol upgrades, +> work-arounds, software upgrade via contacting key miners etc. We +> could take an example of the openSSL bug. +> +> - How do you plan to deal with security & incident response for the +> duration you describe where you will have control while you are +> deploying the unilateral hard-fork and being in sole maintainership +> control? +> +> - Are you a member of the bitcoin security reporting list? +> +> On 15 June 2015 at 11:56, Mike Hearn <mike@plan99.net> wrote: +> > I will review both and mostly delegate to Gavin's good taste around the +> > details, unless there is some very strong disagreement. But that seems +> > unlikely. +> > ... +> > Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests +> > aren't scored in any way. The final decision rests with the maintainer +> as in +> > ~all open source projects. +> +> As you know the people who have written 95% of the code (and reviewed, +> and tested, and formally proved segments etc) are strenuously advising +> not to push any consensus code into public use without listening to +> and addressing review questions which span beyond rigorous code & +> automated guided fuzz testers, simulation and sometimes formal proofs, +> but also economics, game-theory and critically very subtle +> determinism/consensus safety that they have collectively 4-5 years +> experience of each. +> +> - Will you pause your release plans if all of the other developers +> insist that the code or algorithm is defective? +> +> - Please don't take this the wrong way, and I know your bitcoinj work +> was a significant engineering project which required porting bitcoin +> logic. But If the answer to the above question is no, as you seemed +> to indicate in your response, as you not have not written much bitcoin +> core code yourself (I think 3 PRs in total), do you find yourself more +> qualified than the combination of peer review of the group of people +> who have written 95% of it, and maintained it and refactored most of +> it over the last 4-5 years? +> +> I presume from your security background you are quite familiar with +> the need for review of crypto protocol changes & rigorous code review. +> That is even more the case with Bitcoin given the consensus +> criticality. +> +> >> - On the idea of a non-consensus hard-fork at all, I think we can +> >> assume you will get a row of NACKs. Can you explain your rationale +> >> for going ahead anyway? The risks are well understood and enormous. +> > +> > If Bitcoin runs out of capacity it will break and many of our users will +> > leave. That is not an acceptable outcome for myself or the many other +> > wallet, service and merchant developers who have worked for years to +> build +> > an ecosystem around this protocol. +> +> That you are frustrated, is not a sufficient answer as to why you are +> proposing to go ahead with a universally acknowledged extreme network +> divergence danger unilateral hard-fork, lacking wide-spread consensus. +> People are quite concerned about this. Patience, caution and prudence +> is necessary in a software system with such high assurance +> requirements. +> +> So I ask again: +> +> - On the idea of a non-consensus hard-fork at all, I think we can +> assume you will get a row of NACKs. Can you explain your rationale +> for going ahead anyway? The risks are well understood and enormous. +> +> Note the key point is that you are working on a unilateral hard-fork, +> where there is a clear 4 year established process for proposing +> improvements and an extremely well thought out and important change +> management governance process. While there has been much discussion, +> you nor Gavin, have not actually posted a BIP for review. Nor +> actually was much of the discussion even conducted in the open: it was +> only when Matt felt the need to clear the air and steer this +> conversation into the open that discussion arose here. During that +> period of private discussion you and Gavin were largely unknown to +> most of us lobbying companies with your representation of a method +> that concerns everyone of the Bitcoin users. Now that the technical +> community aware aware they are strenuously discouraging you on the +> basis of risks. +> +> +> Openness +> +> - Do you agree that bitcoin technical discussions should happen in the +> open? +> +> - As this is a FOSS project, do you agree that companies should also +> be open, about their requirements and trade-offs they would prefer? +> +> - Can you disclose the list of companies you have lobbied in private +> whether they have spoken publicly or not, and whether they have +> indicated approval or not? +> +> - Did you share a specific plan, like a BIP or white paper with these +> companies, and if so can we see it? +> +> - If you didnt submit a plan, could you summarise what you asked them +> and what you proposed, and if you discussed also the risks? (If you +> asked them if they would like Bitcoin to scale, I expect almost +> everyone does, including every member of the technical community, so +> that for example would not fairly indicate approval for a unilateral +> hard-fork) +> +> I and others will be happy to talk with the CTO and CEOs of companies +> you have lobbied in private, for balance to assure ourselves and the +> rest of the community that their support was given - and with full +> understanding of the risks of doing it unilaterally, without peer +> review, benefit of maintenance and security inidence management, and +> what exactly they are being quoting as having signed up for. +> +> (This maybe more efficiently and openly achieved by the open process, +> on a mailing list, maybe a different one even special purpose to this +> topic, with additional option of the open public meeting I proposed at +> the top). +> +> - Do you agree that it would be appropriate, that companies be aware +> of both the scaling opportunities (of course, great everyone wants +> scalability) as well as the technical limits and risks with various +> approaches? And that these be presented by parties from a range of +> views to ensure balance? +> +> - Do you consider your expression of issues to hold true to the ideal +> of representing balanced nuanced view of all sides of a technical +> debate, even when under pressure or feeling impatient about the +> process? +> +> You may want to review the opening few minutes of your epicenter 82 +> bitcoin for example where you claimed and I quote "[the rest of the +> technical community] dont want capacity to ever increase and want it +> to stay where it is and when it fills up people move to other +> systems". +> +> - Do you think that is an accurate depiction of the complex trade-offs +> we have been discussing on this list? +> +> (For the record I am not aware of a single person who has said they do +> not agree with scaling Bitcoin. Changing a constant is not the +> hard-part. The hard part is validating a plan and the other factors +> that go into it. It's not a free choice it is a security/scalability +> tradeoff. No one will thank us if we "scale" bitcoin but break it in +> hard to recover ways at the same time.) +> +> - Were you similarly balanced in your explanations when talking to +> companies in private discussions? +> +> - Do you understand that if we do not work from balanced technical +> discussion, that we may end up with some biased criteria? +> +> Authority +> +> Neither you nor Gavin have any particular authority here to speak on +> behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is +> dev lead, and you and Gavin are both well aware of the 4 year +> established change management consensus decision making model where +> all of the technical reviewers have to come to agreement before +> changes go in for security reasons explained above). I know Gavin has +> a "Chief Scientist" title from the Bitcoin Foundation, but sadly that +> organisation is not held in as much regard as it once was, due to +> various irregularities and controversies, and as I understand it no +> longer employs any developers, due to lack of funds. Gavin is now +> employed by MIT's DCI project as a researcher in some capacity. As +> you know Wladimir is doing the development lead role now, and it seems +> part of your personal frustration you said was because he did not +> agree with your views. Neither you nor Gavin have been particularly +> involved in bitcoin lately, even Gavin, for 1.5 years or so. +> +> - Do you agree that if you presume to speak where you do not have +> authority you may confuse companies? +> +> > If Bitcoin runs out of capacity it will break and many of our users will +> > leave. That is not an acceptable outcome for myself or the many other +> > wallet, service and merchant developers who have worked for years to +> build +> > an ecosystem around this protocol. +> +> But I think this is a false dichotomy. As I said in previous mail I +> understand people are frustrated that it has taken so long, but it is +> not the case that no progress has been made on scalability. +> +> I itemised a long list of scalability work which you acknowledged as +> impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP +> fee work, fee-estimation, and so on, which you acknowledged and are +> aware of. +> +> There are multiple proposals and BIPs under consideration on the list +> right now. +> +> - what is the reason that you (or Gavin) would not post your BIP along +> side the others to see if it would win based on technical merit? +> +> - why would you feel uniquely qualified to override the expert opinion +> of the rest of the technical community if your proposal were not +> considered to have most technical merit? (Given that this is not a +> simple market competition thing where multiple hard-forks can be +> considered - it is a one only decision, and if it is done in a +> divisive unilateral way there are extreme risks of the ledger +> diverging.) +> +> Network Divergence Risk +> +> >> - How do you propose to deal with the extra risks that come from +> >> non-consensus hard-forks? Hard-forks themselves are quite risky, but +> >> non-consensus ones are extremely dangerous for consensus. +> > +> > The approach is the same for other forks. Voting via block versions and +> then +> > when there's been >X% for Y time units the 1mb limit is lifted/replaced. +> +> But this is not a soft-fork, it is a hard-fork. Miner voting is only +> peripherally related. Even if in the extremis 75% of miners tried a +> unilateral hard-fork but 100% of the users stayed on the maintained +> original code, no change would occur other than those miners losing +> reward (mining fork-coins with no resale value) and the difficulty +> would adjust. The miners who made an error in choice would lose money +> and go out of business or rejoin the chain. +> +> However if something in that direction happens with actual users and +> companies on both sides of it users will lose money, the ledger will +> diverge as soon as a single double-spend happens, and never share a +> block again, companies will go instantly insolvent, and chaos will +> break out. This is the dangerous scenario we are concerned about. +> +> So the same question again: +> +> - How do you propose to deal with the extra risks that come from +> non-consensus hard-forks? Hard-forks themselves are quite risky, but +> non-consensus ones are extremely dangerous for consensus. +> +> +> Being sensitive to alarming the market +> +> It is something akin to Greece or Portugal or Italy exiting the euro +> currency in a disorderly way. Economists and central bank policy +> makers are extremely worried about such an eventuality and talk about +> related factors in careful, measured terms, watch Mario Draghi when he +> speaks. +> +> Imagine that bitcoin is 10x or 100x bigger. Bitcoin cant have people +> taking unilateral actions such as you have been proposing. It is not +> following the consensus governance process, and not good policy and it +> is probably affecting bitcoin confidence and price at this moment. +> +> >> - Do you have contingency plans for what to do if the non-consensus +> >> hard-fork goes wrong and $3B is lost as a result? +> > +> > Where did you get the $3B figure from? The fork either doesn't happen, +> or it +> > happens after quite a long period of people knowing it's going to happen +> - +> > for example because their full node is printing "You need to upgrade" +> > messages due to seeing the larger block version, or because they read the +> > news, or because they heard about it via some other mechanisms. +> +> This is not a soft-fork, and the community will not want to take the +> risks once they understand them, and they have months in which to +> understand them and at this point you've motivated and wasted 100s of +> developer man hours such that we will feel impelled to make sure that +> no one opts into a unilateral hard-fork without understanding the +> risks. It would be negligent to allow people to do that. Before this +> gets very far FAQs will be on bitcoin.org etc explaining this risk I +> would imagine. Its just starting not finished. +> +> What makes you think the rest of the community may not instead prefer +> Jeff Garzik's BIP after revisions that he is making now with review +> comments from others? +> +> Or another proposal. Taken together with a deployment plan that sees +> work on decentralisation tying into that plan. +> +> - If you persisted anyway, what makes you think bitcoin could not make +> code changes defensively relating to your unilateral fork? +> (I am sure creative minds can find some ways to harden bitcoin against +> a unilateral fork, with a soft-fork or non-consensus update can be +> deployed much faster than a hard-fork). +> +> I tried to warn Gavin privately that I thought he was under-estimating +> the risk of failure to his fork proposal due to it being unilateral. +> Ie as you both seem sincere in your wish to have your proposal +> succeed, then obviously the best way to do that is to release a BIP in +> the open collaborative process and submit it to review like everyone +> else. Doing it unilaterally only increases its chance of failure. +> +> The only sensible thing to do here is submit a BIP and stop the +> unilateral fork threat. +> +> Scalability Plans +> +> > Let me flip the question around. Do you have a contingency plan if +> Bitcoin +> > runs out of capacity and significant user disruption occurs that results +> in +> > exodus, followed by fall in BTC price? The only one I've seen is "we can +> > perform an emergency hard fork in a few weeks"! +> +> Yes people have proposed other plans. Bryan Bishop posted a list of them. +> +> Jeff Garzik has a proposal, BIP-100 which seems already better than +> Gavin's having benefit of peer review which he has been incorporating. +> +> I proposed several soft-fork models which can be deployed safely and +> immediately, which do not have ledger risk. +> +> I have another proposal relating to simplified soft-fork one-way pegs +> which I'll write up in a bit. +> +> I think there are still issues in Jeff's proposal but he is very open +> and collaborating and there maybe related but different proposals +> presently. +> +> >> As you can probably tell I think a unilateral fork without wide-scale +> >> consensus from the technical and business communities is a deeply +> >> inadvisable. +> > +> > Gavin and I have been polling many key players in the ecosystem. The +> > consensus you seek does exist. All wallet developers (except Lawrence), +> all +> > the major exchanges, all the major payment processors and many of the +> major +> > mining pools want to see the limit lifted (I haven't been talking to +> pools, +> > Gavin has). +> +> It does not seem to me that you understand the issue. Of course they +> want to increase the scalability of bitcoin. So does everyone else on +> this mailing list. +> +> That they would support that is obvious. If you presented your +> unilateral action plan without explaining the risks too. +> +> I think I covered this further above. If you would like to share the +> company list, or we can invite them to the proposed public physical +> meeting, I think it would be useful for them to have a balanced view +> of the ledger divergence risks, and alternative in-consensus proposals +> underway, as well as the governance risks, maintenance risks, security +> incident risks. +> +> Note that other people talk to companies too, as part of their day to +> day jobs, or from contacts from being in the industry. You have no +> special authority or unique ability to talk with business people. Its +> just that the technical community did not know you were busy doing +> that. +> +> I can not believe that any company that would listen to their CTO, CSO +> or failing that board would be ok with the risks implied by what you +> are proposing on full examination. +> +> > This notion that the change has no consensus is based on you polling the +> > people directly around you and people who like to spend all day on this +> > mailing list. It's not an accurate reflection of the wider Bitcoin +> community +> > and that is one of the leading reasons there is going to be a fork. A +> small +> > number of people have been flatly ignoring LOTS of highly technical and +> > passionate developers who have written vast amounts of code, built up the +> > Bitcoin user base, designed hardware and software, and yes built +> companies. +> +> I know you want scale bitcoin, as I said everyone here does. I think +> what you're experiencing is that you've had more luck explaining your +> pragmatic unilateral plan to non-technical people without peer review, +> and so not experienced the kind of huge pushback you are getting from +> the technical community. The whole of bitcoin is immensely +> complicated such that it takes an uber-geek CS genius years to +> catchup, this is not a slight of any of the business people who are +> working hard to deploy Bitcoin into the world, its just complicated +> and therefore not easy to understand the game-theory, security, +> governance and distributed system thinking. I have a comp sci PhD in +> distributed systems, implemented p2p network systems and have 2 +> decades of applied crypto experience with a major interest in +> electronic cash crypto protocols, and it took me a several years to +> catchup and even I have a few hazy spots on low-level details, and I +> addictively into read everything I could find. Realistically all of +> us are still learning, as bitcoin combines so many fields that it +> opens new possibilities. +> +> What I am expecting that yourself and Gavin are thinking is that +> you'll knock heads and force the issue and get to consensus. +> +> However I think you have seriously misjudged the risks and have not +> adequately explained them to companies you are talking with. Indeed +> you do not fully seem to acknowledge the risks, nor to have a well +> thought out plan here of how you would actually manage it, nor the +> moral hazards of having a lone developer in hugely divisive +> circumstances in sole control of bitcoins running code. Those are +> exactly the reasons for the code change governance process! +> +> Even though you are trying to help, the full result is you are not +> helping achieve anything by changing a constant and starting a +> unilateral hard-fork (not to trivialise the work of making a patch to +> do that). +> +> The work to even make the constant change be feasible was a result of +> 1000s of hours of work by others in the development community, that is +> emphatically and unilaterally telling you that hard-forks are hugely +> inadvisable. +> +> You are trying to break the code change governance security procedure +> that were put in place for good reason for the security of $3b of +> other peoples money, even if you have a pragmatic intent to help, this +> is flat out unacceptable. +> +> There are also security implications to what you are proposing, which +> I have heard you attempting to trivialise, that are core to Bitcoins +> security and core functionality. +> +> > the overwhelming impression I get from a few +> > others here is that no, they don't want to scale Bitcoin. They already +> > decided it's a technological dead end. +> +> I think this is a significant mischaracterisation, and I think almost +> everybody is on board with a combination plan: +> +> 1. work to improve decentralisation (specific technical work already +> underway, and education) +> 2. create a plan to increase block-size in a slow fashion to not cause +> system shocks (eg like Jeff is proposing or some better variant) +> 3. work on actual algorithmic scaling +> +> In this way we can have throughput needed for scalability and security +> work to continue. +> +> As I said you can not scale a O(n^2) broadcast network by changing +> constants, you need algorithmic improvements. +> +> People are working on them already. All of those 3 things are being +> actively worked on RIGHT NOW, and in the case of algorithmic scaling +> and improve decentralisation have been worked on for months. +> +> You may have done one useful thing which is to remind people that +> blocks are only 3x-4x below capacity such that we should look at it. +> +> But we can not work under duress of haste, nor unilateral ultimatums, +> this is the realm of human action that leads to moral hazard, and +> ironically reminds us of why Satoshi put the quote in the genesis +> block. +> +> Bitcoin is too complex a system with too much at stake to be making +> political hasty decisions, it would be negligent to act in such a way. +> +> Again please consider that you did your job, caused people to pay +> attention, but return to the process, submit a BIP, retract the +> unilateral hard-fork which is so dangerous and lets have things be +> calm, civil and collaborative in the technical zone of Bitcoin and not +> further alarm companies and investors. +> +> Adam +> +> +> ------------------------------------------------------------------------------ +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development +> + +--f46d044288043e18a10518a1c889 +Content-Type: text/html; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable + +<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= +te">On Tue, Jun 16, 2015 at 2:03 AM, Adam Back <span dir=3D"ltr"><<a hre= +f=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a= +>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0p= +x 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi= + Mike<br> +<br> +Well thank you for replying openly on this topic, its helpful.<br> +<br> +I apologise in advance if this gets quite to the point and at times<br> +blunt, but transparency is important, and we owe it to the users who<br> +see Bitcoin as the start of a new future and the$3b of invested funds<br> +and $600m of VC funds invested in companies, we owe it to them that we<br> +be open and transparent here.<br> +<br> +I would really prefer on a personal nor professional basis to be<br> +having this conversation period, never mind in public, but Mike - your<br> +and Gavin's decision to promote a unilateral hard-fork and code fork<br= +> +are extremely high risk for bitcoin and so there remains little<br> +choice.=C2=A0 So I apologise again that we have to have this kind of<br> +conversation on a technical discussion list.=C2=A0 This whole thing is<br> +hugely stressful and worrying for developers, companies and investors.<br> +<br> +I strongly urge that we return to the existing collaborative<br> +constructive review process that has been used for the last 4 years<br> +which is a consensus by design to prevent one rogue person from<br> +inserting a backdoor, or lobbying for a favoured change on behalf of a<br> +special interest group, or working for bad actor (without accusing you<br> +of any of those - I understand you personally just want to scale<br> +bitcoin, but are inclined to knock heads and try to force an issue you<br> +see, rather than work collaboratively).<br> +<br> +For you (and everyone)<br> +<br> +- Should there be a summit of some kind, that is open attendance, and<br> +video recorded so that people who are unable to attend can participate<br> +too, so that people can present the technical proposals and risks in<br> +an unbiased way?<br> +<br></blockquote><div><br></div><div>Dear Adam, All:<br><br></div><div>At t= +he community's convenience, it would be an honour to arrange an initial= + open summit to meet with representatives of the Chinese miners in Hong Kon= +g (UTC+8) to facilitate a better understand between the different stakehold= +ers of the Bitcoin ecosystem on this important issue.=C2=A0=C2=A0 This coul= +d be arranged for this October, or earlier, if deemed necessary. <br><br>Re= +mote online participation would be welcome from those who might not be able= + to attend in person. =C2=A0 <br><br></div><div>However,=C2=A0 it is hoped = +that such a meeting would be primarily document driven to facilitate orderl= +y translation, discussion and decision.=C2=A0 <br></div><div><br></div><div= +>p.<br><br></div><div>=C2=A0<br></div><blockquote class=3D"gmail_quote" sty= +le=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);paddi= +ng-left:1ex"> +(It is not theoretical question, I may have a sponsor and host - not<br> +Blockstream, an independent, its a question for everyone, developers,<br> +users, CTOs, CEOs.)<br> +<br> +<br> +<br> +So here I come back to more frank questions:<br> +<br> +Governance<br> +<br> +The rest of the developers are wise to realise that they do not want<br> +exclusive control, to avoid governance centralising into the hands of<br> +one person, and this is why they have shared it with a consensus<br> +process over the last 4 years.=C2=A0 No offence but I dont think you<br> +personally are thinking far enough ahead to think you want personal<br> +control of this industry.=C2=A0 Maybe some factions dont trust your<br> +motives, or they dont mind, but feel more assured if a dozen other<br> +people are closely reviewing and have collective review authority.<br> +<br> +- Do you understand that attempting to break this process by<br> +unilateral hard-fork is extremely weakening of Bitcoin's change<br> +governance model?<br> +<br> +- Do you understand that change governance is important, and that it<br> +is important that there be multiple reviewers and sign-off to avoid<br> +someone being blackmailed or influenced by an external party - which<br> +could potentially result in massive theft of funds if something were<br> +missed?<br> +<br> +- Secondarily do you understand that even if you succeed in a<br> +unilateral fork (and the level of lost coins and market cap and damage<br> +to confidence is recoverable), that it sets a precedent that others<br> +may try to follow in the future to introduce coercive features that<br> +break the assurances of bitcoin, like fungibility reducing features<br> +say (topically I hear you once proposed on a private forum the concept<br> +of red-lists, other such proposals have been made and quickly<br> +abandoned), or ultimately if there is a political process to obtain<br> +unpopular changes by unilateral threat, the sky is the limit - rewrite<br> +the social contract at that point without consensus, but by<br> +calculation that people will value Bitcoin enough that they will<br> +follow a lead to avoid risk to the system?<br> +<br> +<br> +Security<br> +<br> +As you probably know some extremely subtle bugs in Bitcoin have at<br> +times slipped past even the most rigorous testings, often with<br> +innocuous but unexpected behaviours, but some security issues=C2=A0 Some<br= +> +extremely intricate and time-sensitive security defect and incident<br> +response happens from time to time which is not necessarily publicly<br> +disclosed until after the issue has been rolled out and fixed, which<br> +can take some time due to the nature of protocol upgrades,<br> +work-arounds, software upgrade via contacting key miners etc.=C2=A0 We<br> +could take an example of the openSSL bug.<br> +<br> +- How do you plan to deal with security & incident response for the<br> +duration you describe where you will have control while you are<br> +deploying the unilateral hard-fork and being in sole maintainership<br> +control?<br> +<br> +- Are you a member of the bitcoin security reporting list?<br> +<span class=3D""><br> +On 15 June 2015 at 11:56, Mike Hearn <<a href=3D"mailto:mike@plan99.net"= +>mike@plan99.net</a>> wrote:<br> +> I will review both and mostly delegate to Gavin's good taste aroun= +d the<br> +> details, unless there is some very strong disagreement. But that seems= +<br> +> unlikely.<br> +</span>> ...<br> +<span class=3D"">> Feedback will be read. There are no NACKS in Bitcoin = +XT. Patch requests<br> +> aren't scored in any way. The final decision rests with the mainta= +iner as in<br> +> ~all open source projects.<br> +<br> +</span>As you know the people who have written 95% of the code (and reviewe= +d,<br> +and tested, and formally proved segments etc) are strenuously advising<br> +not to push any consensus code into public use without listening to<br> +and addressing review questions which span beyond rigorous code &<br> +automated guided fuzz testers, simulation and sometimes formal proofs,<br> +but also economics, game-theory and critically very subtle<br> +determinism/consensus safety that they have collectively 4-5 years<br> +experience of each.<br> +<br> +- Will you pause your release plans if all of the other developers<br> +insist that the code or algorithm is defective?<br> +<br> +- Please don't take this the wrong way, and I know your bitcoinj work<b= +r> +was a significant engineering project which required porting bitcoin<br> +logic.=C2=A0 But If the answer to the above question is no, as you seemed<b= +r> +to indicate in your response, as you not have not written much bitcoin<br> +core code yourself (I think 3 PRs in total), do you find yourself more<br> +qualified than the combination of peer review of the group of people<br> +who have written 95% of it, and maintained it and refactored most of<br> +it over the last 4-5 years?<br> +<br> +I presume from your security background you are quite familiar with<br> +the need for review of crypto protocol changes & rigorous code review.<= +br> +That is even more the case with Bitcoin given the consensus<br> +criticality.<br> +<span class=3D""><br> +>> - On the idea of a non-consensus hard-fork at all, I think we can<= +br> +>> assume you will get a row of NACKs.=C2=A0 Can you explain your rat= +ionale<br> +>> for going ahead anyway?=C2=A0 The risks are well understood and en= +ormous.<br> +><br> +</span><span class=3D"">> If Bitcoin runs out of capacity it will break = +and many of our users will<br> +> leave. That is not an acceptable outcome for myself or the many other<= +br> +> wallet, service and merchant developers who have worked for years to b= +uild<br> +> an ecosystem around this protocol.<br> +<br> +</span>That you are frustrated, is not a sufficient answer as to why you ar= +e<br> +proposing to go ahead with a universally acknowledged extreme network<br> +divergence danger unilateral hard-fork, lacking wide-spread consensus.<br> +People are quite concerned about this.=C2=A0 Patience, caution and prudence= +<br> +is necessary in a software system with such high assurance<br> +requirements.<br> +<br> +So I ask again:<br> +<span class=3D""><br> +- On the idea of a non-consensus hard-fork at all, I think we can<br> +assume you will get a row of NACKs.=C2=A0 Can you explain your rationale<br= +> +for going ahead anyway?=C2=A0 The risks are well understood and enormous.<b= +r> +<br> +</span>Note the key point is that you are working on a unilateral hard-fork= +,<br> +where there is a clear 4 year established process for proposing<br> +improvements and an extremely well thought out and important change<br> +management governance process.=C2=A0 While there has been much discussion,<= +br> +you nor Gavin, have not actually posted a BIP for review.=C2=A0 Nor<br> +actually was much of the discussion even conducted in the open: it was<br> +only when Matt felt the need to clear the air and steer this<br> +conversation into the open that discussion arose here.=C2=A0 During that<br= +> +period of private discussion you and Gavin were largely unknown to<br> +most of us lobbying companies with your representation of a method<br> +that concerns everyone of the Bitcoin users.=C2=A0 Now that the technical<b= +r> +community aware aware they are strenuously discouraging you on the<br> +basis of risks.<br> +<br> +<br> +Openness<br> +<br> +- Do you agree that bitcoin technical discussions should happen in the open= +?<br> +<br> +- As this is a FOSS project, do you agree that companies should also<br> +be open, about their requirements and trade-offs they would prefer?<br> +<br> +- Can you disclose the list of companies you have lobbied in private<br> +whether they have spoken publicly or not, and whether they have<br> +indicated approval or not?<br> +<br> +- Did you share a specific plan, like a BIP or white paper with these<br> +companies, and if so can we see it?<br> +<br> +- If you didnt submit a plan, could you summarise what you asked them<br> +and what you proposed, and if you discussed also the risks?=C2=A0 (If you<b= +r> +asked them if they would like Bitcoin to scale, I expect almost<br> +everyone does, including every member of the technical community, so<br> +that for example would not fairly indicate approval for a unilateral<br> +hard-fork)<br> +<br> +I and others will be happy to talk with the CTO and CEOs of companies<br> +you have lobbied in private, for balance to assure ourselves and the<br> +rest of the community that their support was given - and with full<br> +understanding of the risks of doing it unilaterally, without peer<br> +review, benefit of maintenance and security inidence management, and<br> +what exactly they are being quoting as having signed up for.<br> +<br> +(This maybe more efficiently and openly achieved by the open process,<br> +on a mailing list, maybe a different one even special purpose to this<br> +topic, with additional option of the open public meeting I proposed at<br> +the top).<br> +<br> +- Do you agree that it would be appropriate, that companies be aware<br> +of both the scaling opportunities (of course, great everyone wants<br> +scalability) as well as the technical limits and risks with various<br> +approaches?=C2=A0 And that these be presented by parties from a range of<br= +> +views to ensure balance?<br> +<br> +- Do you consider your expression of issues to hold true to the ideal<br> +of representing balanced nuanced view of all sides of a technical<br> +debate, even when under pressure or feeling impatient about the<br> +process?<br> +<br> +You may want to review the opening few minutes of your epicenter 82<br> +bitcoin for example where you claimed and I quote "[the rest of the<br= +> +technical community] dont want capacity to ever increase and want it<br> +to stay where it is and when it fills up people move to other<br> +systems".<br> +<br> +- Do you think that is an accurate depiction of the complex trade-offs<br> +we have been discussing on this list?<br> +<br> +(For the record I am not aware of a single person who has said they do<br> +not agree with scaling Bitcoin.=C2=A0 Changing a constant is not the<br> +hard-part.=C2=A0 The hard part is validating a plan and the other factors<b= +r> +that go into it.=C2=A0 It's not a free choice it is a security/scalabil= +ity<br> +tradeoff.=C2=A0 No one will thank us if we "scale" bitcoin but br= +eak it in<br> +hard to recover ways at the same time.)<br> +<br> +- Were you similarly balanced in your explanations when talking to<br> +companies in private discussions?<br> +<br> +- Do you understand that if we do not work from balanced technical<br> +discussion, that we may end up with some biased criteria?<br> +<br> +Authority<br> +<br> +Neither you nor Gavin have any particular authority here to speak on<br> +behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is<br> +dev lead, and you and Gavin are both well aware of the 4 year<br> +established change management consensus decision making model where<br> +all of the technical reviewers have to come to agreement before<br> +changes go in for security reasons explained above).=C2=A0 I know Gavin has= +<br> +a "Chief Scientist" title from the Bitcoin Foundation, but sadly = +that<br> +organisation is not held in as much regard as it once was, due to<br> +various irregularities and controversies, and as I understand it no<br> +longer employs any developers, due to lack of funds.=C2=A0 Gavin is now<br> +employed by MIT's DCI project as a researcher in some capacity.=C2=A0 A= +s<br> +you know Wladimir is doing the development lead role now, and it seems<br> +part of your personal frustration you said was because he did not<br> +agree with your views.=C2=A0 Neither you nor Gavin have been particularly<b= +r> +involved in bitcoin lately, even Gavin, for 1.5 years or so.<br> +<br> +- Do you agree that if you presume to speak where you do not have<br> +authority you may confuse companies?<br> +<span class=3D""><br> +> If Bitcoin runs out of capacity it will break and many of our users wi= +ll<br> +> leave. That is not an acceptable outcome for myself or the many other<= +br> +> wallet, service and merchant developers who have worked for years to b= +uild<br> +> an ecosystem around this protocol.<br> +<br> +</span>But I think this is a false dichotomy.=C2=A0 As I said in previous m= +ail I<br> +understand people are frustrated that it has taken so long, but it is<br> +not the case that no progress has been made on scalability.<br> +<br> +I itemised a long list of scalability work which you acknowledged as<br> +impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP<br> +fee work, fee-estimation, and so on, which you acknowledged and are<br> +aware of.<br> +<br> +There are multiple proposals and BIPs under consideration on the list right= + now.<br> +<br> +- what is the reason that you (or Gavin) would not post your BIP along<br> +side the others to see if it would win based on technical merit?<br> +<br> +- why would you feel uniquely qualified to override the expert opinion<br> +of the rest of the technical community if your proposal were not<br> +considered to have most technical merit? (Given that this is not a<br> +simple market competition thing where multiple hard-forks can be<br> +considered - it is a one only decision, and if it is done in a<br> +divisive unilateral way there are extreme risks of the ledger<br> +diverging.)<br> +<br> +Network Divergence Risk<br> +<span class=3D""><br> +>> - How do you propose to deal with the extra risks that come from<b= +r> +>> non-consensus hard-forks?=C2=A0 Hard-forks themselves are quite ri= +sky, but<br> +>> non-consensus ones are extremely dangerous for consensus.<br> +><br> +> The approach is the same for other forks. Voting via block versions an= +d then<br> +> when there's been >X% for Y time units the 1mb limit is lifted/= +replaced.<br> +<br> +</span>But this is not a soft-fork, it is a hard-fork.=C2=A0 Miner voting i= +s only<br> +peripherally related.=C2=A0 Even if in the extremis 75% of miners tried a<b= +r> +unilateral hard-fork but 100% of the users stayed on the maintained<br> +original code, no change would occur other than those miners losing<br> +reward (mining fork-coins with no resale value) and the difficulty<br> +would adjust.=C2=A0 The miners who made an error in choice would lose money= +<br> +and go out of business or rejoin the chain.<br> +<br> +However if something in that direction happens with actual users and<br> +companies on both sides of it users will lose money, the ledger will<br> +diverge as soon as a single double-spend happens, and never share a<br> +block again, companies will go instantly insolvent, and chaos will<br> +break out.=C2=A0 This is the dangerous scenario we are concerned about.<br> +<br> +So the same question again:<br> +<span class=3D""><br> +- How do you propose to deal with the extra risks that come from<br> +non-consensus hard-forks?=C2=A0 Hard-forks themselves are quite risky, but<= +br> +non-consensus ones are extremely dangerous for consensus.<br> +<br> +<br> +</span>Being sensitive to alarming the market<br> +<br> +It is something akin to Greece or Portugal or Italy exiting the euro<br> +currency in a disorderly way.=C2=A0 Economists and central bank policy<br> +makers are extremely worried about such an eventuality and talk about<br> +related factors in careful, measured terms, watch Mario Draghi when he<br> +speaks.<br> +<br> +Imagine that bitcoin is 10x or 100x bigger.=C2=A0 Bitcoin cant have people<= +br> +taking unilateral actions such as you have been proposing.=C2=A0 It is not<= +br> +following the consensus governance process, and not good policy and it<br> +is probably affecting bitcoin confidence and price at this moment.<br> +<span class=3D""><br> +>> - Do you have contingency plans for what to do if the non-consensu= +s<br> +>> hard-fork goes wrong and $3B is lost as a result?<br> +><br> +> Where did you get the $3B figure from? The fork either doesn't hap= +pen, or it<br> +> happens after quite a long period of people knowing it's going to = +happen -<br> +> for example because their full node is printing "You need to upgr= +ade"<br> +> messages due to seeing the larger block version, or because they read = +the<br> +> news, or because they heard about it via some other mechanisms.<br> +<br> +</span>This is not a soft-fork, and the community will not want to take the= +<br> +risks once they understand them, and they have months in which to<br> +understand them and at this point you've motivated and wasted 100s of<b= +r> +developer man hours such that we will feel impelled to make sure that<br> +no one opts into a unilateral hard-fork without understanding the<br> +risks.=C2=A0 It would be negligent to allow people to do that.=C2=A0 Before= + this<br> +gets very far FAQs will be on <a href=3D"http://bitcoin.org" rel=3D"norefer= +rer" target=3D"_blank">bitcoin.org</a> etc explaining this risk I<br> +would imagine.=C2=A0 Its just starting not finished.<br> +<br> +What makes you think the rest of the community may not instead prefer<br> +Jeff Garzik's BIP after revisions that he is making now with review<br> +comments from others?<br> +<br> +Or another proposal.=C2=A0 Taken together with a deployment plan that sees<= +br> +work on decentralisation tying into that plan.<br> +<br> +- If you persisted anyway, what makes you think bitcoin could not make<br> +code changes defensively relating to your unilateral fork?<br> +(I am sure creative minds can find some ways to harden bitcoin against<br> +a unilateral fork, with a soft-fork or non-consensus update can be<br> +deployed much faster than a hard-fork).<br> +<br> +I tried to warn Gavin privately that I thought he was under-estimating<br> +the risk of failure to his fork proposal due to it being unilateral.<br> +Ie as you both seem sincere in your wish to have your proposal<br> +succeed, then obviously the best way to do that is to release a BIP in<br> +the open collaborative process and submit it to review like everyone<br> +else.=C2=A0 Doing it unilaterally only increases its chance of failure.<br> +<br> +The only sensible thing to do here is submit a BIP and stop the<br> +unilateral fork threat.<br> +<br> +Scalability Plans<br> +<span class=3D""><br> +> Let me flip the question around. Do you have a contingency plan if Bit= +coin<br> +> runs out of capacity and significant user disruption occurs that resul= +ts in<br> +> exodus, followed by fall in BTC price? The only one I've seen is &= +quot;we can<br> +> perform an emergency hard fork in a few weeks"!<br> +<br> +</span>Yes people have proposed other plans.=C2=A0 Bryan Bishop posted a li= +st of them.<br> +<br> +Jeff Garzik has a proposal, BIP-100 which seems already better than<br> +Gavin's having benefit of peer review which he has been incorporating.<= +br> +<br> +I proposed several soft-fork models which can be deployed safely and<br> +immediately, which do not have ledger risk.<br> +<br> +I have another proposal relating to simplified soft-fork one-way pegs<br> +which I'll write up in a bit.<br> +<br> +I think there are still issues in Jeff's proposal but he is very open<b= +r> +and collaborating and there maybe related but different proposals<br> +presently.<br> +<span class=3D""><br> +>> As you can probably tell I think a unilateral fork without wide-sc= +ale<br> +>> consensus from the technical and business communities is a deeply<= +br> +>> inadvisable.<br> +><br> +> Gavin and I have been polling many key players in the ecosystem. The<b= +r> +> consensus you seek does exist. All wallet developers (except Lawrence)= +, all<br> +> the major exchanges, all the major payment processors and many of the = +major<br> +> mining pools want to see the limit lifted (I haven't been talking = +to pools,<br> +> Gavin has).<br> +<br> +</span>It does not seem to me that you understand the issue.=C2=A0 Of cours= +e they<br> +want to increase the scalability of bitcoin.=C2=A0 So does everyone else on= +<br> +this mailing list.<br> +<br> +That they would support that is obvious.=C2=A0 If you presented your<br> +unilateral action plan without explaining the risks too.<br> +<br> +I think I covered this further above.=C2=A0 If you would like to share the<= +br> +company list, or we can invite them to the proposed public physical<br> +meeting, I think it would be useful for them to have a balanced view<br> +of the ledger divergence risks, and alternative in-consensus proposals<br> +underway, as well as the governance risks, maintenance risks, security<br> +incident risks.<br> +<br> +Note that other people talk to companies too, as part of their day to<br> +day jobs, or from contacts from being in the industry.=C2=A0 You have no<br= +> +special authority or unique ability to talk with business people.=C2=A0 Its= +<br> +just that the technical community did not know you were busy doing<br> +that.<br> +<br> +I can not believe that any company that would listen to their CTO, CSO<br> +or failing that board would be ok with the risks implied by what you<br> +are proposing on full examination.<br> +<span class=3D""><br> +> This notion that the change has no consensus is based on you polling t= +he<br> +> people directly around you and people who like to spend all day on thi= +s<br> +> mailing list. It's not an accurate reflection of the wider Bitcoin= + community<br> +> and that is one of the leading reasons there is going to be a fork. A = +small<br> +> number of people have been flatly ignoring LOTS of highly technical an= +d<br> +> passionate developers who have written vast amounts of code, built up = +the<br> +> Bitcoin user base, designed hardware and software, and yes built compa= +nies.<br> +<br> +</span>I know you want scale bitcoin, as I said everyone here does. I think= +<br> +what you're experiencing is that you've had more luck explaining yo= +ur<br> +pragmatic unilateral plan to non-technical people without peer review,<br> +and so not experienced the kind of huge pushback you are getting from<br> +the technical community.=C2=A0 The whole of bitcoin is immensely<br> +complicated such that it takes an uber-geek CS genius years to<br> +catchup, this is not a slight of any of the business people who are<br> +working hard to deploy Bitcoin into the world, its just complicated<br> +and therefore not easy to understand the game-theory, security,<br> +governance and distributed system thinking.=C2=A0 I have a comp sci PhD in<= +br> +distributed systems, implemented p2p network systems and have 2<br> +decades of applied crypto experience with a major interest in<br> +electronic cash crypto protocols, and it took me a several years to<br> +catchup and even I have a few hazy spots on low-level details, and I<br> +addictively into read everything I could find.=C2=A0 Realistically all of<b= +r> +us are still learning, as bitcoin combines so many fields that it<br> +opens new possibilities.<br> +<br> +What I am expecting that yourself and Gavin are thinking is that<br> +you'll knock heads and force the issue and get to consensus.<br> +<br> +However I think you have seriously misjudged the risks and have not<br> +adequately explained them to companies you are talking with.=C2=A0 Indeed<b= +r> +you do not fully seem to acknowledge the risks, nor to have a well<br> +thought out plan here of how you would actually manage it, nor the<br> +moral hazards of having a lone developer in hugely divisive<br> +circumstances in sole control of bitcoins running code.=C2=A0 Those are<br> +exactly the reasons for the code change governance process!<br> +<br> +Even though you are trying to help, the full result is you are not<br> +helping achieve anything by changing a constant and starting a<br> +unilateral hard-fork (not to trivialise the work of making a patch to<br> +do that).<br> +<br> +The work to even make the constant change be feasible was a result of<br> +1000s of hours of work by others in the development community, that is<br> +emphatically and unilaterally telling you that hard-forks are hugely<br> +inadvisable.<br> +<br> +You are trying to break the code change governance security procedure<br> +that were put in place for good reason for the security of $3b of<br> +other peoples money, even if you have a pragmatic intent to help, this<br> +is flat out unacceptable.<br> +<br> +There are also security implications to what you are proposing, which<br> +I have heard you attempting to trivialise, that are core to Bitcoins<br> +security and core functionality.<br> +<span class=3D""><br> +>=C2=A0 the overwhelming impression I get from a few<br> +> others here is that no, they don't want to scale Bitcoin. They alr= +eady<br> +> decided it's a technological dead end.<br> +<br> +</span>I think this is a significant mischaracterisation, and I think almos= +t<br> +everybody is on board with a combination plan:<br> +<br> +1. work to improve decentralisation (specific technical work already<br> +underway, and education)<br> +2. create a plan to increase block-size in a slow fashion to not cause<br> +system shocks (eg like Jeff is proposing or some better variant)<br> +3. work on actual algorithmic scaling<br> +<br> +In this way we can have throughput needed for scalability and security<br> +work to continue.<br> +<br> +As I said you can not scale a O(n^2) broadcast network by changing<br> +constants, you need algorithmic improvements.<br> +<br> +People are working on them already.=C2=A0 All of those 3 things are being<b= +r> +actively worked on RIGHT NOW, and in the case of algorithmic scaling<br> +and improve decentralisation have been worked on for months.<br> +<br> +You may have done one useful thing which is to remind people that<br> +blocks are only 3x-4x below capacity such that we should look at it.<br> +<br> +But we can not work under duress of haste, nor unilateral ultimatums,<br> +this is the realm of human action that leads to moral hazard, and<br> +ironically reminds us of why Satoshi put the quote in the genesis<br> +block.<br> +<br> +Bitcoin is too complex a system with too much at stake to be making<br> +political hasty decisions, it would be negligent to act in such a way.<br> +<br> +Again please consider that you did your job, caused people to pay<br> +attention, but return to the process, submit a BIP, retract the<br> +unilateral hard-fork which is so dangerous and lets have things be<br> +calm, civil and collaborative in the technical zone of Bitcoin and not<br> +further alarm companies and investors.<br> +<div class=3D""><div class=3D"h5"><br> +Adam<br> +<br> +---------------------------------------------------------------------------= +---<br> +_______________________________________________<br> +Bitcoin-development mailing list<br> +<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo= +pment@lists.sourceforge.net</a><br> +<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development= +" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/= +listinfo/bitcoin-development</a><br> +</div></div></blockquote></div><br></div></div> + +--f46d044288043e18a10518a1c889-- + + |