{"type":"rich","version":"1.0","author_name":"npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga","author_url":"https://nostr.ae/npub1xv3g4rkhj7eyape0cqjhc9g4ljdu5axqkgcdewma854a8r7e0mtsl5j2ga","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-15\n📝 Original message:-----BEGIN PGP SIGNED MESSAGE-----\nHash: SHA1\n\nMike,\n\nTo sum it up, you are saying \"bitcoin will break and many of our users\nwill leave therefore OMG WTF so we have to do what GAVIN AND ME want\nto do to hardfork to XT which is the ONLY WAY, so GTFO!\"\n\nAnd so, no.  We don't have to accept that attitude.\n\nThere are other proposals that actually would work here.\n\nCameron Garnham's dynamic block size adjustment (needing soft fork\nonly) mentioned here http://www.twitlonger.com/show/n_1smkanp\n\nJeff Garzik's proposals (rewritten and published as a BIP)\nhttp://bitcoin-development.narkive.com/f5FMeA4D/comments-on-bip-100\n\nand more.\n\nI also disagree with the notion that everybody's just ok with what\nMike and Gavin are doing.... specifically, this statement by Mike\n\n\u003e The consensus you seek does exist. All wallet developers (except \n\u003e Lawrence), all the major exchanges, all the major payment\n\u003e processors and many of the major mining pools want to see the limit\n\u003e lifted\n\nwas kind of twisting things, because it made it sound like everybody\nsupports Gavin's proposal to hard fork to XT, which these folks don't.\n\nExample:\n\n1)\nhttp://cointelegraph.com/news/114481/chinese-exchanges-reject-gavin-andr\nesens-20-mb-block-size-increase\n\n2) https://twitter.com/GreenAddress/status/605037073725313024\n\nThis isn't to say they don't want to see a limit adjusted but not in\nthe way that Gavin (and you, Mike) are proposing - not through this\nhard fork to XT.\n\nSo go roll out your code for whatever it is you are going to put into\nXT and make a BIP, but stop saying that everyone supports it when\nobviously they don't and you don't even have something yet and there\nare already superior alternatives that don't involve Gavin's hard fork\nand your blessed XT.\n\n\nOn 06/15/2015 02:56 AM, Mike Hearn wrote:\n\u003e Hi Adam,\n\u003e \n\u003e Provisional answers below!\n\u003e \n\u003e - Are you releasing a BIP for that proposal for review?\n\u003e \n\u003e \n\u003e The work splits like this:\n\u003e \n\u003e * Gavin is writing the code and I think a BIP as well\n\u003e \n\u003e * I will review both and mostly delegate to Gavin's good taste\n\u003e around the details, unless there is some very strong disagreement.\n\u003e But that seems unlikely.\n\u003e \n\u003e * I have been handling gitian and the patch rebases, the code\n\u003e signing and so on, so far. I've also been doing some work to setup\n\u003e the basic infrastructure of the project (website etc).\n\u003e \n\u003e \n\u003e - If the reviewers all say NACK will you take on board their \n\u003e suggestions?\n\u003e \n\u003e \n\u003e Feedback will be read. There are no NACKS in Bitcoin XT. Patch\n\u003e requests aren't scored in any way. The final decision rests with\n\u003e the maintainer as in ~all open source projects.\n\u003e \n\u003e \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\n\u003e rationale for going ahead anyway?  The risks are well understood\n\u003e and enormous.\n\u003e \n\u003e \n\u003e Yes, I have been working on an article that explains how we got to\n\u003e this point from my perspective. It is quite long, but only because\n\u003e I want it to be readable for people who weren't following the\n\u003e debate.\n\u003e \n\u003e Anyway, I think I've laid out the gist of it over and over again,\n\u003e but to summarise:\n\u003e \n\u003e If Bitcoin runs out of capacity *it will break and many of our\n\u003e users will leave*. That is not an acceptable outcome for myself or\n\u003e the many other wallet, service and merchant developers who have\n\u003e worked for years to build an ecosystem around this protocol.\n\u003e \n\u003e \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,\n\u003e but non-consensus ones are extremely dangerous for consensus.\n\u003e \n\u003e \n\u003e The approach is the same for other forks. Voting via block versions\n\u003e and then when there's been \u003eX% for Y time units the 1mb limit is \n\u003e lifted/replaced.\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e - If you're going it alone as it were, are you proposing that you\n\u003e will personally maintain bitcoin-XT?  Or do you have a plan to\n\u003e later hand over maintenance to the bitcoin developers?\n\u003e \n\u003e \n\u003e Good question!  I have various thoughts on this, but let's wait and\n\u003e see what happens first. Perhaps the new chain won't get the\n\u003e majority on it.\n\u003e \n\u003e In the event that the \u003e1mb chain does eventually win, I would\n\u003e expect Core to apply the patch and rejoin the consensus rather than\n\u003e lose all its users. That would take XT back to being a fairly small\n\u003e patchset to improve the network protocol.\n\u003e \n\u003e \n\u003e \n\u003e - Do you have contingency plans for what to do if the\n\u003e non-consensus hard-fork goes wrong and $3B is lost as a result?\n\u003e \n\u003e \n\u003e Where did you get the $3B figure from? The fork either doesn't\n\u003e happen, or it happens after quite a long period of people knowing\n\u003e it's going to happen - for example because their full node is\n\u003e printing \"You need to upgrade\" messages due to seeing the larger\n\u003e block version, or because they read the news, or because they heard\n\u003e about it via some other mechanisms.\n\u003e \n\u003e Let me flip the question around. Do you have a contingency plan if \n\u003e Bitcoin runs out of capacity and significant user disruption occurs\n\u003e that results in exodus, followed by fall in BTC price? The only one\n\u003e I've seen is \"we can perform an emergency hard fork in a few\n\u003e weeks\"!\n\u003e \n\u003e \n\u003e \n\u003e As you can probably tell I think a unilateral fork without\n\u003e wide-scale consensus from the technical and business communities is\n\u003e a deeply inadvisable.\n\u003e \n\u003e \n\u003e Gavin and I have been polling many key players in the ecosystem.\n\u003e The consensus you seek does exist. All wallet developers (except\n\u003e Lawrence), all the major exchanges, all the major payment\n\u003e processors and many of the major mining pools want to see the limit\n\u003e lifted (I haven't been talking to pools, Gavin has).\n\u003e \n\u003e This notion that the change has no consensus is based on you\n\u003e polling the people directly around you and people who like to spend\n\u003e all day on this mailing list. It's not an accurate reflection of\n\u003e the wider Bitcoin community and that is one of the leading reasons\n\u003e there is going to be a fork. A small number of people have been\n\u003e flatly ignoring LOTS of highly technical and passionate developers\n\u003e who have written vast amounts of code, built up the Bitcoin user\n\u003e base, designed hardware and software, and yes built companies.\n\u003e \n\u003e How do you think that makes Bitcoin Core look to the rest of the\n\u003e Bitcoin world? How much confidence does that give people?\n\u003e \n\u003e \n\u003e \n\u003e Of the overall process, I think you can agree we should not be\n\u003e making technical decisions with this level of complexity and\n\u003e consensus risk with financial implications of this magnitude under\n\u003e duress of haste?\n\u003e \n\u003e \n\u003e This debate will never end until a fork makes it irrelevant. There\n\u003e is no process for ending it, despite me begging Wladimir to make\n\u003e one.\n\u003e \n\u003e And there is no haste. We have been debating the block size limit\n\u003e for _years_. We have known it must be lifted for _years_. I kicked\n\u003e off this current round of debates after realising that Wladimir's\n\u003e release timeline wouldn't allow a block size limit to be released\n\u003e before the end of the year. The reason we're talking about it now\n\u003e and not next year is exactly to ensure there is plenty of time.\n\u003e \n\u003e \n\u003e \n\u003e \n\u003e I can sincerely assure you everyone does want to scale bitcoin and \n\u003e shares your long term objective on that\n\u003e \n\u003e \n\u003e I really wish you were right, and I definitely feel you are one of\n\u003e the more reasonable ones Adam. But the overwhelming impression I\n\u003e get from a few others here is that no, they don't want to scale\n\u003e Bitcoin. They already decided it's a technological dead end. They\n\u003e want to kick end users out in order to \"incentivise\" (force) the\n\u003e creation of some other alternative, claiming that it's still\n\u003e Bitcoin whilst ignoring basic details ... like the fact that no\n\u003e existing wallets or services would work.\n\u003e \n\u003e Scaling Bitcoin can only be achieved by letting it grow, and\n\u003e letting people tackle each bottleneck as it arises at the right\n\u003e times. Not by convincing ourselves that success is failure.\n\u003e \n\u003e \n\u003e \n\u003e ----------------------------------------------------------------------\n- --------\n\u003e\n\u003e \n\u003e \n\u003e \n\u003e _______________________________________________ Bitcoin-development\n\u003e mailing list Bitcoin-development at lists.sourceforge.net \n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \n\n- -- \nhttp://abis.io ~\n\"a protocol concept to enable decentralization\nand expansion of a giving economy, and a new social good\"\nhttps://keybase.io/odinn\n-----BEGIN PGP SIGNATURE-----\nVersion: GnuPG v1\n\niQEcBAEBAgAGBQJVf1e3AAoJEGxwq/inSG8C7NwIAIah+HzWKB+aydCgarJB1Tuv\n4wK6ffaWP3pzT/D1jNPMoMwL6bp+hi/ixyrV2y9a841Oc/9vgf75ws1l8QH2YtEE\nTM5cLnRtScXnbaHKAAQZyewURbmGKTUxhNLMIRlVMMq2uHwbUEqRrDaaBGhwC1HO\n+v3u5zK13H1UMKBuUY7yANWvOamjs17FmwZ6MURYdX8qBFVqMoTorhPHTebDGusS\nNxDm4uqphW7ylXISOm53v7i3/CPjW63YGB2fyk9J+BqxhOM7yAJSH0Ln/xtu/COa\nuXudO+SbMco+x+cKrFLf/5ItxR65aOnWvWPKw0o55f96uSabngs/QozDhaU2BJk=\n=gof9\n-----END PGP SIGNATURE-----"}