{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-15\n📝 Original message:Hi Adam,\n\nProvisional answers below!\n\n- Are you releasing a BIP for that proposal for review?\n\u003e\n\nThe work splits like this:\n\n   - Gavin is writing the code and I think a BIP as well\n\n   - I will review both and mostly delegate to Gavin's good taste around\n   the details, unless there is some very strong disagreement. But that seems\n   unlikely.\n\n   - I have been handling gitian and the patch rebases, the code signing\n   and so on, so far. I've also been doing some work to setup the basic\n   infrastructure of the project (website etc).\n\n\n- If the reviewers all say NACK will you take on board their suggestions?\n\u003e\n\nFeedback will be read. There are no NACKS in Bitcoin XT. Patch requests\naren't scored in any way. The final decision rests with the maintainer as\nin ~all open source projects.\n\n\n\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\nYes, I have been working on an article that explains how we got to this\npoint from my perspective. It is quite long, but only because I want it to\nbe readable for people who weren't following the debate.\n\nAnyway, I think I've laid out the gist of it over and over again, but to\nsummarise:\n\nIf Bitcoin runs out of capacity *it will break and many of our users will\nleave*. That is not an acceptable outcome for myself or the many other\nwallet, service and merchant developers who have worked for years to build\nan ecosystem around this protocol.\n\n\n\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\nThe approach is the same for other forks. Voting via block versions and\nthen when there's been \u003eX% for Y time units the 1mb limit is\nlifted/replaced.\n\n\n\n\n\u003e - If you're going it alone as it were, are you proposing that you will\n\u003e personally maintain bitcoin-XT?  Or do you have a plan to later hand\n\u003e over maintenance to the bitcoin developers?\n\u003e\n\nGood question!  I have various thoughts on this, but let's wait and see\nwhat happens first. Perhaps the new chain won't get the majority on it.\n\nIn the event that the \u003e1mb chain does eventually win, I would expect Core\nto apply the patch and rejoin the consensus rather than lose all its users.\nThat would take XT back to being a fairly small patchset to improve the\nnetwork protocol.\n\n\n\n- Do you have contingency plans for what to do if the non-consensus\n\u003e hard-fork goes wrong and $3B is lost as a result?\n\u003e\n\nWhere did you get the $3B figure from? The fork either doesn't happen, or\nit happens after quite a long period of people knowing it's going to happen\n- for example because their full node is printing \"You need to upgrade\"\nmessages due to seeing the larger block version, or because they read the\nnews, or because they heard about it via some other mechanisms.\n\nLet me flip the question around. Do you have a contingency plan if Bitcoin\nruns out of capacity and significant user disruption occurs that results in\nexodus, followed by fall in BTC price? The only one I've seen is \"we can\nperform an emergency hard fork in a few weeks\"!\n\n\n\n\u003e As you can probably tell I think a unilateral fork without wide-scale\n\u003e consensus from the technical and business communities is a deeply\n\u003e inadvisable.\n\n\nGavin and I have been polling many key players in the ecosystem. The\nconsensus you seek does exist. All wallet developers (except Lawrence), all\nthe major exchanges, all the major payment processors and many of the major\nmining pools want to see the limit lifted (I haven't been talking to pools,\nGavin has).\n\nThis notion that the change has no consensus is based on you polling the\npeople directly around you and people who like to spend all day on this\nmailing list. It's not an accurate reflection of the wider Bitcoin\ncommunity and that is one of the leading reasons there is going to be a\nfork. A small number of people have been flatly ignoring LOTS of highly\ntechnical and passionate developers who have written vast amounts of code,\nbuilt up the Bitcoin user base, designed hardware and software, and yes\nbuilt companies.\n\nHow do you think that makes Bitcoin Core look to the rest of the Bitcoin\nworld? How much confidence does that give people?\n\n\n\nOf the overall process, I think you can agree we should not be making\n\u003e technical decisions with this level of complexity and consensus risk\n\u003e with financial implications of this magnitude under duress of haste?\n\u003e\n\nThis debate will never end until a fork makes it irrelevant. There is no\nprocess for ending it, despite me begging Wladimir to make one.\n\nAnd there is no haste. We have been debating the block size limit for\n*years*. We have known it must be lifted for *years*. I kicked off this\ncurrent round of debates after realising that Wladimir's release timeline\nwouldn't allow a block size limit to be released before the end of the\nyear. The reason we're talking about it now and not next year is exactly to\nensure there is plenty of time.\n\n\n\n\n\u003e I can sincerely assure you everyone does want to scale bitcoin and\n\u003e shares your long term objective on that\n\n\nI really wish you were right, and I definitely feel you are one of the more\nreasonable ones Adam. But the overwhelming impression I get from a few\nothers here is that no, they don't want to scale Bitcoin. They already\ndecided it's a technological dead end. They want to kick end users out in\norder to \"incentivise\" (force) the creation of some other alternative,\nclaiming that it's still Bitcoin whilst ignoring basic details ... like the\nfact that no existing wallets or services would work.\n\nScaling Bitcoin can only be achieved by letting it grow, and letting people\ntackle each bottleneck as it arises at the right times. Not by convincing\nourselves that success is failure.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150615/892471da/attachment.html\u003e"}