summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorPindar Wong <pindar.wong@gmail.com>2015-06-16 20:33:31 +0800
committerbitcoindev <bitcoindev@gnusha.org>2015-06-16 12:33:42 +0000
commitc679f1ba814ce433395fd7fb0ebf36421086e07e (patch)
treea19873b4a969f85b95ed3dfdf9c8c32ba9c360ca
parentbe882ffd906f9b1158a34cb31c64d12731ecdf07 (diff)
downloadpi-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/5a9e28ce0d7a044cdd6ad9bdaca4f56f8c316b1280
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">&lt;<a hre=
+f=3D"mailto:adam@cypherspace.org" target=3D"_blank">adam@cypherspace.org</a=
+>&gt;</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&#39;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&#39;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&#39;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 &amp; 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 &lt;<a href=3D"mailto:mike@plan99.net"=
+>mike@plan99.net</a>&gt; wrote:<br>
+&gt; I will review both and mostly delegate to Gavin&#39;s good taste aroun=
+d the<br>
+&gt; details, unless there is some very strong disagreement. But that seems=
+<br>
+&gt; unlikely.<br>
+</span>&gt; ...<br>
+<span class=3D"">&gt; Feedback will be read. There are no NACKS in Bitcoin =
+XT. Patch requests<br>
+&gt; aren&#39;t scored in any way. The final decision rests with the mainta=
+iner as in<br>
+&gt; ~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 &amp;<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&#39;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 &amp; rigorous code review.<=
+br>
+That is even more the case with Bitcoin given the consensus<br>
+criticality.<br>
+<span class=3D""><br>
+&gt;&gt; - On the idea of a non-consensus hard-fork at all, I think we can<=
+br>
+&gt;&gt; assume you will get a row of NACKs.=C2=A0 Can you explain your rat=
+ionale<br>
+&gt;&gt; for going ahead anyway?=C2=A0 The risks are well understood and en=
+ormous.<br>
+&gt;<br>
+</span><span class=3D"">&gt; If Bitcoin runs out of capacity it will break =
+and many of our users will<br>
+&gt; leave. That is not an acceptable outcome for myself or the many other<=
+br>
+&gt; wallet, service and merchant developers who have worked for years to b=
+uild<br>
+&gt; 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 &quot;[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&quot;.<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&#39;s not a free choice it is a security/scalabil=
+ity<br>
+tradeoff.=C2=A0 No one will thank us if we &quot;scale&quot; 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 &quot;Chief Scientist&quot; 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&#39;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>
+&gt; If Bitcoin runs out of capacity it will break and many of our users wi=
+ll<br>
+&gt; leave. That is not an acceptable outcome for myself or the many other<=
+br>
+&gt; wallet, service and merchant developers who have worked for years to b=
+uild<br>
+&gt; 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>
+&gt;&gt; - How do you propose to deal with the extra risks that come from<b=
+r>
+&gt;&gt; non-consensus hard-forks?=C2=A0 Hard-forks themselves are quite ri=
+sky, but<br>
+&gt;&gt; non-consensus ones are extremely dangerous for consensus.<br>
+&gt;<br>
+&gt; The approach is the same for other forks. Voting via block versions an=
+d then<br>
+&gt; when there&#39;s been &gt;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>
+&gt;&gt; - Do you have contingency plans for what to do if the non-consensu=
+s<br>
+&gt;&gt; hard-fork goes wrong and $3B is lost as a result?<br>
+&gt;<br>
+&gt; Where did you get the $3B figure from? The fork either doesn&#39;t hap=
+pen, or it<br>
+&gt; happens after quite a long period of people knowing it&#39;s going to =
+happen -<br>
+&gt; for example because their full node is printing &quot;You need to upgr=
+ade&quot;<br>
+&gt; messages due to seeing the larger block version, or because they read =
+the<br>
+&gt; 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&#39;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&#39;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>
+&gt; Let me flip the question around. Do you have a contingency plan if Bit=
+coin<br>
+&gt; runs out of capacity and significant user disruption occurs that resul=
+ts in<br>
+&gt; exodus, followed by fall in BTC price? The only one I&#39;ve seen is &=
+quot;we can<br>
+&gt; perform an emergency hard fork in a few weeks&quot;!<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&#39;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&#39;ll write up in a bit.<br>
+<br>
+I think there are still issues in Jeff&#39;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>
+&gt;&gt; As you can probably tell I think a unilateral fork without wide-sc=
+ale<br>
+&gt;&gt; consensus from the technical and business communities is a deeply<=
+br>
+&gt;&gt; inadvisable.<br>
+&gt;<br>
+&gt; Gavin and I have been polling many key players in the ecosystem. The<b=
+r>
+&gt; consensus you seek does exist. All wallet developers (except Lawrence)=
+, all<br>
+&gt; the major exchanges, all the major payment processors and many of the =
+major<br>
+&gt; mining pools want to see the limit lifted (I haven&#39;t been talking =
+to pools,<br>
+&gt; 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>
+&gt; This notion that the change has no consensus is based on you polling t=
+he<br>
+&gt; people directly around you and people who like to spend all day on thi=
+s<br>
+&gt; mailing list. It&#39;s not an accurate reflection of the wider Bitcoin=
+ community<br>
+&gt; and that is one of the leading reasons there is going to be a fork. A =
+small<br>
+&gt; number of people have been flatly ignoring LOTS of highly technical an=
+d<br>
+&gt; passionate developers who have written vast amounts of code, built up =
+the<br>
+&gt; 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&#39;re experiencing is that you&#39;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&#39;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>
+&gt;=C2=A0 the overwhelming impression I get from a few<br>
+&gt; others here is that no, they don&#39;t want to scale Bitcoin. They alr=
+eady<br>
+&gt; decided it&#39;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--
+
+