{"type":"rich","version":"1.0","author_name":"npub1gg0pysd236d4em7pts906ev9kf6f30j8werd40j2vwpes7fqdn4qtt7uvk","author_url":"https://nostr.ae/npub1gg0pysd236d4em7pts906ev9kf6f30j8werd40j2vwpes7fqdn4qtt7uvk","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-16\n📝 Original message:On Tue, Jun 16, 2015 at 2:03 AM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\n\u003e Hi Mike\n\u003e\n\u003e Well thank you for replying openly on this topic, its helpful.\n\u003e\n\u003e I apologise in advance if this gets quite to the point and at times\n\u003e blunt, but transparency is important, and we owe it to the users who\n\u003e see Bitcoin as the start of a new future and the$3b of invested funds\n\u003e and $600m of VC funds invested in companies, we owe it to them that we\n\u003e be open and transparent here.\n\u003e\n\u003e I would really prefer on a personal nor professional basis to be\n\u003e having this conversation period, never mind in public, but Mike - your\n\u003e and Gavin's decision to promote a unilateral hard-fork and code fork\n\u003e are extremely high risk for bitcoin and so there remains little\n\u003e choice.  So I apologise again that we have to have this kind of\n\u003e conversation on a technical discussion list.  This whole thing is\n\u003e hugely stressful and worrying for developers, companies and investors.\n\u003e\n\u003e I strongly urge that we return to the existing collaborative\n\u003e constructive review process that has been used for the last 4 years\n\u003e which is a consensus by design to prevent one rogue person from\n\u003e inserting a backdoor, or lobbying for a favoured change on behalf of a\n\u003e special interest group, or working for bad actor (without accusing you\n\u003e of any of those - I understand you personally just want to scale\n\u003e bitcoin, but are inclined to knock heads and try to force an issue you\n\u003e see, rather than work collaboratively).\n\u003e\n\u003e For you (and everyone)\n\u003e\n\u003e - Should there be a summit of some kind, that is open attendance, and\n\u003e video recorded so that people who are unable to attend can participate\n\u003e too, so that people can present the technical proposals and risks in\n\u003e an unbiased way?\n\u003e\n\u003e\nDear Adam, All:\n\nAt the community's convenience, it would be an honour to arrange an initial\nopen summit to meet with representatives of the Chinese miners in Hong Kong\n(UTC+8) to facilitate a better understand between the different\nstakeholders of the Bitcoin ecosystem on this important issue.   This could\nbe arranged for this October, or earlier, if deemed necessary.\n\nRemote online participation would be welcome from those who might not be\nable to attend in person.\n\nHowever,  it is hoped that such a meeting would be primarily document\ndriven to facilitate orderly translation, discussion and decision.\n\np.\n\n\n\n\u003e (It is not theoretical question, I may have a sponsor and host - not\n\u003e Blockstream, an independent, its a question for everyone, developers,\n\u003e users, CTOs, CEOs.)\n\u003e\n\u003e\n\u003e\n\u003e So here I come back to more frank questions:\n\u003e\n\u003e Governance\n\u003e\n\u003e The rest of the developers are wise to realise that they do not want\n\u003e exclusive control, to avoid governance centralising into the hands of\n\u003e one person, and this is why they have shared it with a consensus\n\u003e process over the last 4 years.  No offence but I dont think you\n\u003e personally are thinking far enough ahead to think you want personal\n\u003e control of this industry.  Maybe some factions dont trust your\n\u003e motives, or they dont mind, but feel more assured if a dozen other\n\u003e people are closely reviewing and have collective review authority.\n\u003e\n\u003e - Do you understand that attempting to break this process by\n\u003e unilateral hard-fork is extremely weakening of Bitcoin's change\n\u003e governance model?\n\u003e\n\u003e - Do you understand that change governance is important, and that it\n\u003e is important that there be multiple reviewers and sign-off to avoid\n\u003e someone being blackmailed or influenced by an external party - which\n\u003e could potentially result in massive theft of funds if something were\n\u003e missed?\n\u003e\n\u003e - Secondarily do you understand that even if you succeed in a\n\u003e unilateral fork (and the level of lost coins and market cap and damage\n\u003e to confidence is recoverable), that it sets a precedent that others\n\u003e may try to follow in the future to introduce coercive features that\n\u003e break the assurances of bitcoin, like fungibility reducing features\n\u003e say (topically I hear you once proposed on a private forum the concept\n\u003e of red-lists, other such proposals have been made and quickly\n\u003e abandoned), or ultimately if there is a political process to obtain\n\u003e unpopular changes by unilateral threat, the sky is the limit - rewrite\n\u003e the social contract at that point without consensus, but by\n\u003e calculation that people will value Bitcoin enough that they will\n\u003e follow a lead to avoid risk to the system?\n\u003e\n\u003e\n\u003e Security\n\u003e\n\u003e As you probably know some extremely subtle bugs in Bitcoin have at\n\u003e times slipped past even the most rigorous testings, often with\n\u003e innocuous but unexpected behaviours, but some security issues  Some\n\u003e extremely intricate and time-sensitive security defect and incident\n\u003e response happens from time to time which is not necessarily publicly\n\u003e disclosed until after the issue has been rolled out and fixed, which\n\u003e can take some time due to the nature of protocol upgrades,\n\u003e work-arounds, software upgrade via contacting key miners etc.  We\n\u003e could take an example of the openSSL bug.\n\u003e\n\u003e - How do you plan to deal with security \u0026 incident response for the\n\u003e duration you describe where you will have control while you are\n\u003e deploying the unilateral hard-fork and being in sole maintainership\n\u003e control?\n\u003e\n\u003e - Are you a member of the bitcoin security reporting list?\n\u003e\n\u003e On 15 June 2015 at 11:56, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e \u003e I will review both and mostly delegate to Gavin's good taste around the\n\u003e \u003e details, unless there is some very strong disagreement. But that seems\n\u003e \u003e unlikely.\n\u003e \u003e ...\n\u003e \u003e Feedback will be read. There are no NACKS in Bitcoin XT. Patch requests\n\u003e \u003e aren't scored in any way. The final decision rests with the maintainer\n\u003e as in\n\u003e \u003e ~all open source projects.\n\u003e\n\u003e As you know the people who have written 95% of the code (and reviewed,\n\u003e and tested, and formally proved segments etc) are strenuously advising\n\u003e not to push any consensus code into public use without listening to\n\u003e and addressing review questions which span beyond rigorous code \u0026\n\u003e automated guided fuzz testers, simulation and sometimes formal proofs,\n\u003e but also economics, game-theory and critically very subtle\n\u003e determinism/consensus safety that they have collectively 4-5 years\n\u003e experience of each.\n\u003e\n\u003e - Will you pause your release plans if all of the other developers\n\u003e insist that the code or algorithm is defective?\n\u003e\n\u003e - Please don't take this the wrong way, and I know your bitcoinj work\n\u003e was a significant engineering project which required porting bitcoin\n\u003e logic.  But If the answer to the above question is no, as you seemed\n\u003e to indicate in your response, as you not have not written much bitcoin\n\u003e core code yourself (I think 3 PRs in total), do you find yourself more\n\u003e qualified than the combination of peer review of the group of people\n\u003e who have written 95% of it, and maintained it and refactored most of\n\u003e it over the last 4-5 years?\n\u003e\n\u003e I presume from your security background you are quite familiar with\n\u003e the need for review of crypto protocol changes \u0026 rigorous code review.\n\u003e That is even more the case with Bitcoin given the consensus\n\u003e criticality.\n\u003e\n\u003e \u003e\u003e - On the idea of a non-consensus hard-fork at all, I think we can\n\u003e \u003e\u003e assume you will get a row of NACKs.  Can you explain your rationale\n\u003e \u003e\u003e for going ahead anyway?  The risks are well understood and enormous.\n\u003e \u003e\n\u003e \u003e If Bitcoin runs out of capacity it will break and many of our users will\n\u003e \u003e leave. That is not an acceptable outcome for myself or the many other\n\u003e \u003e wallet, service and merchant developers who have worked for years to\n\u003e build\n\u003e \u003e an ecosystem around this protocol.\n\u003e\n\u003e That you are frustrated, is not a sufficient answer as to why you are\n\u003e proposing to go ahead with a universally acknowledged extreme network\n\u003e divergence danger unilateral hard-fork, lacking wide-spread consensus.\n\u003e People are quite concerned about this.  Patience, caution and prudence\n\u003e is necessary in a software system with such high assurance\n\u003e requirements.\n\u003e\n\u003e So I ask again:\n\u003e\n\u003e - On the idea of a non-consensus hard-fork at all, I think we can\n\u003e assume you will get a row of NACKs.  Can you explain your rationale\n\u003e for going ahead anyway?  The risks are well understood and enormous.\n\u003e\n\u003e Note the key point is that you are working on a unilateral hard-fork,\n\u003e where there is a clear 4 year established process for proposing\n\u003e improvements and an extremely well thought out and important change\n\u003e management governance process.  While there has been much discussion,\n\u003e you nor Gavin, have not actually posted a BIP for review.  Nor\n\u003e actually was much of the discussion even conducted in the open: it was\n\u003e only when Matt felt the need to clear the air and steer this\n\u003e conversation into the open that discussion arose here.  During that\n\u003e period of private discussion you and Gavin were largely unknown to\n\u003e most of us lobbying companies with your representation of a method\n\u003e that concerns everyone of the Bitcoin users.  Now that the technical\n\u003e community aware aware they are strenuously discouraging you on the\n\u003e basis of risks.\n\u003e\n\u003e\n\u003e Openness\n\u003e\n\u003e - Do you agree that bitcoin technical discussions should happen in the\n\u003e open?\n\u003e\n\u003e - As this is a FOSS project, do you agree that companies should also\n\u003e be open, about their requirements and trade-offs they would prefer?\n\u003e\n\u003e - Can you disclose the list of companies you have lobbied in private\n\u003e whether they have spoken publicly or not, and whether they have\n\u003e indicated approval or not?\n\u003e\n\u003e - Did you share a specific plan, like a BIP or white paper with these\n\u003e companies, and if so can we see it?\n\u003e\n\u003e - If you didnt submit a plan, could you summarise what you asked them\n\u003e and what you proposed, and if you discussed also the risks?  (If you\n\u003e asked them if they would like Bitcoin to scale, I expect almost\n\u003e everyone does, including every member of the technical community, so\n\u003e that for example would not fairly indicate approval for a unilateral\n\u003e hard-fork)\n\u003e\n\u003e I and others will be happy to talk with the CTO and CEOs of companies\n\u003e you have lobbied in private, for balance to assure ourselves and the\n\u003e rest of the community that their support was given - and with full\n\u003e understanding of the risks of doing it unilaterally, without peer\n\u003e review, benefit of maintenance and security inidence management, and\n\u003e what exactly they are being quoting as having signed up for.\n\u003e\n\u003e (This maybe more efficiently and openly achieved by the open process,\n\u003e on a mailing list, maybe a different one even special purpose to this\n\u003e topic, with additional option of the open public meeting I proposed at\n\u003e the top).\n\u003e\n\u003e - Do you agree that it would be appropriate, that companies be aware\n\u003e of both the scaling opportunities (of course, great everyone wants\n\u003e scalability) as well as the technical limits and risks with various\n\u003e approaches?  And that these be presented by parties from a range of\n\u003e views to ensure balance?\n\u003e\n\u003e - Do you consider your expression of issues to hold true to the ideal\n\u003e of representing balanced nuanced view of all sides of a technical\n\u003e debate, even when under pressure or feeling impatient about the\n\u003e process?\n\u003e\n\u003e You may want to review the opening few minutes of your epicenter 82\n\u003e bitcoin for example where you claimed and I quote \"[the rest of the\n\u003e technical community] dont want capacity to ever increase and want it\n\u003e to stay where it is and when it fills up people move to other\n\u003e systems\".\n\u003e\n\u003e - Do you think that is an accurate depiction of the complex trade-offs\n\u003e we have been discussing on this list?\n\u003e\n\u003e (For the record I am not aware of a single person who has said they do\n\u003e not agree with scaling Bitcoin.  Changing a constant is not the\n\u003e hard-part.  The hard part is validating a plan and the other factors\n\u003e that go into it.  It's not a free choice it is a security/scalability\n\u003e tradeoff.  No one will thank us if we \"scale\" bitcoin but break it in\n\u003e hard to recover ways at the same time.)\n\u003e\n\u003e - Were you similarly balanced in your explanations when talking to\n\u003e companies in private discussions?\n\u003e\n\u003e - Do you understand that if we do not work from balanced technical\n\u003e discussion, that we may end up with some biased criteria?\n\u003e\n\u003e Authority\n\u003e\n\u003e Neither you nor Gavin have any particular authority here to speak on\n\u003e behalf of Bitcoin (eg you acknowledge in your podcast that Wladimir is\n\u003e dev lead, and you and Gavin are both well aware of the 4 year\n\u003e established change management consensus decision making model where\n\u003e all of the technical reviewers have to come to agreement before\n\u003e changes go in for security reasons explained above).  I know Gavin has\n\u003e a \"Chief Scientist\" title from the Bitcoin Foundation, but sadly that\n\u003e organisation is not held in as much regard as it once was, due to\n\u003e various irregularities and controversies, and as I understand it no\n\u003e longer employs any developers, due to lack of funds.  Gavin is now\n\u003e employed by MIT's DCI project as a researcher in some capacity.  As\n\u003e you know Wladimir is doing the development lead role now, and it seems\n\u003e part of your personal frustration you said was because he did not\n\u003e agree with your views.  Neither you nor Gavin have been particularly\n\u003e involved in bitcoin lately, even Gavin, for 1.5 years or so.\n\u003e\n\u003e - Do you agree that if you presume to speak where you do not have\n\u003e authority you may confuse companies?\n\u003e\n\u003e \u003e If Bitcoin runs out of capacity it will break and many of our users will\n\u003e \u003e leave. That is not an acceptable outcome for myself or the many other\n\u003e \u003e wallet, service and merchant developers who have worked for years to\n\u003e build\n\u003e \u003e an ecosystem around this protocol.\n\u003e\n\u003e But I think this is a false dichotomy.  As I said in previous mail I\n\u003e understand people are frustrated that it has taken so long, but it is\n\u003e not the case that no progress has been made on scalability.\n\u003e\n\u003e I itemised a long list of scalability work which you acknowledged as\n\u003e impressive work (CPU, memory, network bandwidth/latency) and RBF, CPFP\n\u003e fee work, fee-estimation, and so on, which you acknowledged and are\n\u003e aware of.\n\u003e\n\u003e There are multiple proposals and BIPs under consideration on the list\n\u003e right now.\n\u003e\n\u003e - what is the reason that you (or Gavin) would not post your BIP along\n\u003e side the others to see if it would win based on technical merit?\n\u003e\n\u003e - why would you feel uniquely qualified to override the expert opinion\n\u003e of the rest of the technical community if your proposal were not\n\u003e considered to have most technical merit? (Given that this is not a\n\u003e simple market competition thing where multiple hard-forks can be\n\u003e considered - it is a one only decision, and if it is done in a\n\u003e divisive unilateral way there are extreme risks of the ledger\n\u003e diverging.)\n\u003e\n\u003e Network Divergence Risk\n\u003e\n\u003e \u003e\u003e - How do you propose to deal with the extra risks that come from\n\u003e \u003e\u003e non-consensus hard-forks?  Hard-forks themselves are quite risky, but\n\u003e \u003e\u003e non-consensus ones are extremely dangerous for consensus.\n\u003e \u003e\n\u003e \u003e The approach is the same for other forks. Voting via block versions and\n\u003e then\n\u003e \u003e when there's been \u003eX% for Y time units the 1mb limit is lifted/replaced.\n\u003e\n\u003e But this is not a soft-fork, it is a hard-fork.  Miner voting is only\n\u003e peripherally related.  Even if in the extremis 75% of miners tried a\n\u003e unilateral hard-fork but 100% of the users stayed on the maintained\n\u003e original code, no change would occur other than those miners losing\n\u003e reward (mining fork-coins with no resale value) and the difficulty\n\u003e would adjust.  The miners who made an error in choice would lose money\n\u003e and go out of business or rejoin the chain.\n\u003e\n\u003e However if something in that direction happens with actual users and\n\u003e companies on both sides of it users will lose money, the ledger will\n\u003e diverge as soon as a single double-spend happens, and never share a\n\u003e block again, companies will go instantly insolvent, and chaos will\n\u003e break out.  This is the dangerous scenario we are concerned about.\n\u003e\n\u003e So the same question again:\n\u003e\n\u003e - How do you propose to deal with the extra risks that come from\n\u003e non-consensus hard-forks?  Hard-forks themselves are quite risky, but\n\u003e non-consensus ones are extremely dangerous for consensus.\n\u003e\n\u003e\n\u003e Being sensitive to alarming the market\n\u003e\n\u003e It is something akin to Greece or Portugal or Italy exiting the euro\n\u003e currency in a disorderly way.  Economists and central bank policy\n\u003e makers are extremely worried about such an eventuality and talk about\n\u003e related factors in careful, measured terms, watch Mario Draghi when he\n\u003e speaks.\n\u003e\n\u003e Imagine that bitcoin is 10x or 100x bigger.  Bitcoin cant have people\n\u003e taking unilateral actions such as you have been proposing.  It is not\n\u003e following the consensus governance process, and not good policy and it\n\u003e is probably affecting bitcoin confidence and price at this moment.\n\u003e\n\u003e \u003e\u003e - Do you have contingency plans for what to do if the non-consensus\n\u003e \u003e\u003e hard-fork goes wrong and $3B is lost as a result?\n\u003e \u003e\n\u003e \u003e Where did you get the $3B figure from? The fork either doesn't happen,\n\u003e or it\n\u003e \u003e happens after quite a long period of people knowing it's going to happen\n\u003e -\n\u003e \u003e for example because their full node is printing \"You need to upgrade\"\n\u003e \u003e messages due to seeing the larger block version, or because they read the\n\u003e \u003e news, or because they heard about it via some other mechanisms.\n\u003e\n\u003e This is not a soft-fork, and the community will not want to take the\n\u003e risks once they understand them, and they have months in which to\n\u003e understand them and at this point you've motivated and wasted 100s of\n\u003e developer man hours such that we will feel impelled to make sure that\n\u003e no one opts into a unilateral hard-fork without understanding the\n\u003e risks.  It would be negligent to allow people to do that.  Before this\n\u003e gets very far FAQs will be on bitcoin.org etc explaining this risk I\n\u003e would imagine.  Its just starting not finished.\n\u003e\n\u003e What makes you think the rest of the community may not instead prefer\n\u003e Jeff Garzik's BIP after revisions that he is making now with review\n\u003e comments from others?\n\u003e\n\u003e Or another proposal.  Taken together with a deployment plan that sees\n\u003e work on decentralisation tying into that plan.\n\u003e\n\u003e - If you persisted anyway, what makes you think bitcoin could not make\n\u003e code changes defensively relating to your unilateral fork?\n\u003e (I am sure creative minds can find some ways to harden bitcoin against\n\u003e a unilateral fork, with a soft-fork or non-consensus update can be\n\u003e deployed much faster than a hard-fork).\n\u003e\n\u003e I tried to warn Gavin privately that I thought he was under-estimating\n\u003e the risk of failure to his fork proposal due to it being unilateral.\n\u003e Ie as you both seem sincere in your wish to have your proposal\n\u003e succeed, then obviously the best way to do that is to release a BIP in\n\u003e the open collaborative process and submit it to review like everyone\n\u003e else.  Doing it unilaterally only increases its chance of failure.\n\u003e\n\u003e The only sensible thing to do here is submit a BIP and stop the\n\u003e unilateral fork threat.\n\u003e\n\u003e Scalability Plans\n\u003e\n\u003e \u003e Let me flip the question around. Do you have a contingency plan if\n\u003e Bitcoin\n\u003e \u003e runs out of capacity and significant user disruption occurs that results\n\u003e in\n\u003e \u003e exodus, followed by fall in BTC price? The only one I've seen is \"we can\n\u003e \u003e perform an emergency hard fork in a few weeks\"!\n\u003e\n\u003e Yes people have proposed other plans.  Bryan Bishop posted a list of them.\n\u003e\n\u003e Jeff Garzik has a proposal, BIP-100 which seems already better than\n\u003e Gavin's having benefit of peer review which he has been incorporating.\n\u003e\n\u003e I proposed several soft-fork models which can be deployed safely and\n\u003e immediately, which do not have ledger risk.\n\u003e\n\u003e I have another proposal relating to simplified soft-fork one-way pegs\n\u003e which I'll write up in a bit.\n\u003e\n\u003e I think there are still issues in Jeff's proposal but he is very open\n\u003e and collaborating and there maybe related but different proposals\n\u003e presently.\n\u003e\n\u003e \u003e\u003e As you can probably tell I think a unilateral fork without wide-scale\n\u003e \u003e\u003e consensus from the technical and business communities is a deeply\n\u003e \u003e\u003e inadvisable.\n\u003e \u003e\n\u003e \u003e Gavin and I have been polling many key players in the ecosystem. The\n\u003e \u003e consensus you seek does exist. All wallet developers (except Lawrence),\n\u003e all\n\u003e \u003e the major exchanges, all the major payment processors and many of the\n\u003e major\n\u003e \u003e mining pools want to see the limit lifted (I haven't been talking to\n\u003e pools,\n\u003e \u003e Gavin has).\n\u003e\n\u003e It does not seem to me that you understand the issue.  Of course they\n\u003e want to increase the scalability of bitcoin.  So does everyone else on\n\u003e this mailing list.\n\u003e\n\u003e That they would support that is obvious.  If you presented your\n\u003e unilateral action plan without explaining the risks too.\n\u003e\n\u003e I think I covered this further above.  If you would like to share the\n\u003e company list, or we can invite them to the proposed public physical\n\u003e meeting, I think it would be useful for them to have a balanced view\n\u003e of the ledger divergence risks, and alternative in-consensus proposals\n\u003e underway, as well as the governance risks, maintenance risks, security\n\u003e incident risks.\n\u003e\n\u003e Note that other people talk to companies too, as part of their day to\n\u003e day jobs, or from contacts from being in the industry.  You have no\n\u003e special authority or unique ability to talk with business people.  Its\n\u003e just that the technical community did not know you were busy doing\n\u003e that.\n\u003e\n\u003e I can not believe that any company that would listen to their CTO, CSO\n\u003e or failing that board would be ok with the risks implied by what you\n\u003e are proposing on full examination.\n\u003e\n\u003e \u003e This notion that the change has no consensus is based on you polling the\n\u003e \u003e people directly around you and people who like to spend all day on this\n\u003e \u003e mailing list. It's not an accurate reflection of the wider Bitcoin\n\u003e community\n\u003e \u003e and that is one of the leading reasons there is going to be a fork. A\n\u003e small\n\u003e \u003e number of people have been flatly ignoring LOTS of highly technical and\n\u003e \u003e passionate developers who have written vast amounts of code, built up the\n\u003e \u003e Bitcoin user base, designed hardware and software, and yes built\n\u003e companies.\n\u003e\n\u003e I know you want scale bitcoin, as I said everyone here does. I think\n\u003e what you're experiencing is that you've had more luck explaining your\n\u003e pragmatic unilateral plan to non-technical people without peer review,\n\u003e and so not experienced the kind of huge pushback you are getting from\n\u003e the technical community.  The whole of bitcoin is immensely\n\u003e complicated such that it takes an uber-geek CS genius years to\n\u003e catchup, this is not a slight of any of the business people who are\n\u003e working hard to deploy Bitcoin into the world, its just complicated\n\u003e and therefore not easy to understand the game-theory, security,\n\u003e governance and distributed system thinking.  I have a comp sci PhD in\n\u003e distributed systems, implemented p2p network systems and have 2\n\u003e decades of applied crypto experience with a major interest in\n\u003e electronic cash crypto protocols, and it took me a several years to\n\u003e catchup and even I have a few hazy spots on low-level details, and I\n\u003e addictively into read everything I could find.  Realistically all of\n\u003e us are still learning, as bitcoin combines so many fields that it\n\u003e opens new possibilities.\n\u003e\n\u003e What I am expecting that yourself and Gavin are thinking is that\n\u003e you'll knock heads and force the issue and get to consensus.\n\u003e\n\u003e However I think you have seriously misjudged the risks and have not\n\u003e adequately explained them to companies you are talking with.  Indeed\n\u003e you do not fully seem to acknowledge the risks, nor to have a well\n\u003e thought out plan here of how you would actually manage it, nor the\n\u003e moral hazards of having a lone developer in hugely divisive\n\u003e circumstances in sole control of bitcoins running code.  Those are\n\u003e exactly the reasons for the code change governance process!\n\u003e\n\u003e Even though you are trying to help, the full result is you are not\n\u003e helping achieve anything by changing a constant and starting a\n\u003e unilateral hard-fork (not to trivialise the work of making a patch to\n\u003e do that).\n\u003e\n\u003e The work to even make the constant change be feasible was a result of\n\u003e 1000s of hours of work by others in the development community, that is\n\u003e emphatically and unilaterally telling you that hard-forks are hugely\n\u003e inadvisable.\n\u003e\n\u003e You are trying to break the code change governance security procedure\n\u003e that were put in place for good reason for the security of $3b of\n\u003e other peoples money, even if you have a pragmatic intent to help, this\n\u003e is flat out unacceptable.\n\u003e\n\u003e There are also security implications to what you are proposing, which\n\u003e I have heard you attempting to trivialise, that are core to Bitcoins\n\u003e security and core functionality.\n\u003e\n\u003e \u003e  the overwhelming impression I get from a few\n\u003e \u003e others here is that no, they don't want to scale Bitcoin. They already\n\u003e \u003e decided it's a technological dead end.\n\u003e\n\u003e I think this is a significant mischaracterisation, and I think almost\n\u003e everybody is on board with a combination plan:\n\u003e\n\u003e 1. work to improve decentralisation (specific technical work already\n\u003e underway, and education)\n\u003e 2. create a plan to increase block-size in a slow fashion to not cause\n\u003e system shocks (eg like Jeff is proposing or some better variant)\n\u003e 3. work on actual algorithmic scaling\n\u003e\n\u003e In this way we can have throughput needed for scalability and security\n\u003e work to continue.\n\u003e\n\u003e As I said you can not scale a O(n^2) broadcast network by changing\n\u003e constants, you need algorithmic improvements.\n\u003e\n\u003e People are working on them already.  All of those 3 things are being\n\u003e actively worked on RIGHT NOW, and in the case of algorithmic scaling\n\u003e and improve decentralisation have been worked on for months.\n\u003e\n\u003e You may have done one useful thing which is to remind people that\n\u003e blocks are only 3x-4x below capacity such that we should look at it.\n\u003e\n\u003e But we can not work under duress of haste, nor unilateral ultimatums,\n\u003e this is the realm of human action that leads to moral hazard, and\n\u003e ironically reminds us of why Satoshi put the quote in the genesis\n\u003e block.\n\u003e\n\u003e Bitcoin is too complex a system with too much at stake to be making\n\u003e political hasty decisions, it would be negligent to act in such a way.\n\u003e\n\u003e Again please consider that you did your job, caused people to pay\n\u003e attention, but return to the process, submit a BIP, retract the\n\u003e unilateral hard-fork which is so dangerous and lets have things be\n\u003e calm, civil and collaborative in the technical zone of Bitcoin and not\n\u003e further alarm companies and investors.\n\u003e\n\u003e Adam\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150616/0d9b09eb/attachment.html\u003e"}