{"type":"rich","version":"1.0","author_name":"npub10sgmhm9jhg0whdtjea83pv0t99lzam0ud4xc2lh0ejtnaclzyatqnjphy0","author_url":"https://nostr.ae/npub10sgmhm9jhg0whdtjea83pv0t99lzam0ud4xc2lh0ejtnaclzyatqnjphy0","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-16\n📝 Original message:Mike Hearn,\n\nIn the light of your responses to Adam Back's questions, below, I feel\nit is time to speak up because what I now understand, and is implied,\nis that Mike Hearn and Gavin Andresen have planned and deployed the\ninfrastructure for a Bitcoin hard-fork and intend to action it despite\nmajority opposition.  http://xtnodes.com/\n\nI'll try to keep it brief:\n\nMike Hearn, you should cease your activity of a unilateral hard-fork\nimmediately. You are doing untold damage by breaking FOSS governance\nprotocol requiring methodical collaborative work and due process of\nchange implementation by consensus. Your actions are bad for the\nBitcoin project and its ideals, disrespectful of your peers and years\nof their passionate hard work, and dangerous for Bitcoin in the\nmarketplace and bitcoin in peoples' wallets.\n\nMike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,\nyou cannot have it. Your hard-fork is tantamount to theft and you and\nyour collaborators will effectively ex-communicate yourselves from\nthis project and community. It appears that you are consciously trying\nto usurp ownership and maintenance of Bitcoin. As if it is that easy!\nYou clearly do not comprehend the array of risks - especially the\nunanticipated ones. As the market saying goes: \"If you think\nspeculation is easy, it is because you are ignorant about the risks\".\nIf you take the risks with Mike\u0026GavCoin, that would be fine, but you\nare about to take them with community-owned Bitcoin and Other People's\nMoney!\n\nYou are causing a lot of stress, unnecessarily, and grave concern\nsurrounds your proposed renegade action. You can dissolve the threat:\nthose players to whom you have made promises can be appeased and\neventually get most of what they need from this FOSS project. The\ndevelopers whom you are railroading to get your way, and the way in\nwhich you are doing it, is about to cause a schism that will expand\noutward from this community.\n\nYou may accuse the community for being antagonistic to you, and\ntherefore uncooperative, but it is plain to see that your bullheaded\nmanner eventually generates antagonism wherever you go. Taking Bitcoin\naway from this community, in anger, won't solve the problem and will\nbe like killing the goose that lays the golden eggs.\n\nIf an individual in an objectively agreed-to FOSS-modelled\ncollaborative project has the audacity to threaten his peers and the\nworld with a unilateral hard-fork despite majority objection and a\nprobability distribution that includes terminal risks and unintended\nconsequences, then what would an impartial outsider think? Some of\ntheir thoughts would include that the antagonist could be acting in\nself-interest, or may be a paid actor, or worse, a saboteur. What\nwould they advise? Stop that individual, at once!\n\nBitcoin is a Free and Open Source Software project that serves as\nflagship for the blockchain. It has a payment network but the key\nbenefits are censorship resistance and trustless decentralization.\nThere is protocol for how change is effected in a FOSS project. For\nthe sake of everything that is good and useful in Bitcoin, reconsider\nyour dangerous plan and its intended and unintended consequences. Put\nyour feet back on the ground, return to the fold and let the\ncollaborative FOSS model, and the skills available here, gradually\nscale Bitcoin to your (and all our) grand vision.\n\nVenzen Khaosan\n\n\nOn 06/15/2015 04:56 PM, 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\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"}
