{"type":"rich","version":"1.0","author_name":"npub14jegtpz2t9nfnefqqr0q4te9353e4k4x5y2528qf235ruluzsaes8vk3rk","author_url":"https://nostr.ae/npub14jegtpz2t9nfnefqqr0q4te9353e4k4x5y2528qf235ruluzsaes8vk3rk","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-06-16\n📝 Original message:\u003e Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,\nyou cannot have it.\n\nNeither do you or anyone else.\n\n\u003e There is protocol for how change is effected in a FOSS project.\n\nAnd it allows the minority to hold the majority hostage.\n\n\u003e If you take the risks with Mike\u0026GavCoin, that would be fine, but you are\nabout to take them with community-owned Bitcoin and Other People's Money!\n\nThe same can be said about the other camp.\n\nBitcoinXT is not going to fork the chain on a specific date no matter what.\nPeople will be able to vote via block versions and once a sufficient\nmajority supports the extensions, everyone else will have a grace period to\nupgrade. Only after that is a very small minority at risk of losing money.\n\nThat being said, I'd rather see a solution that everyone agrees on. My\npersonal opinion/hope is that Mike and Gavin are just applying pressure\nwhere it's needed. But in the end, they can do whatever they want if they\nhave the necessary support. Permissionless innovation is one of bitcoins\nvirtues. In the end, only adoption will decide what bitcoin is and isn't.\n\n2015-06-16 7:18 GMT+02:00 Venzen \u003cvenzen at mail.bihthai.net\u003e:\n\n\u003e Mike Hearn,\n\u003e\n\u003e In the light of your responses to Adam Back's questions, below, I feel\n\u003e it is time to speak up because what I now understand, and is implied,\n\u003e is that Mike Hearn and Gavin Andresen have planned and deployed the\n\u003e infrastructure for a Bitcoin hard-fork and intend to action it despite\n\u003e majority opposition.  http://xtnodes.com/\n\u003e\n\u003e I'll try to keep it brief:\n\u003e\n\u003e Mike Hearn, you should cease your activity of a unilateral hard-fork\n\u003e immediately. You are doing untold damage by breaking FOSS governance\n\u003e protocol requiring methodical collaborative work and due process of\n\u003e change implementation by consensus. Your actions are bad for the\n\u003e Bitcoin project and its ideals, disrespectful of your peers and years\n\u003e of their passionate hard work, and dangerous for Bitcoin in the\n\u003e marketplace and bitcoin in peoples' wallets.\n\u003e\n\u003e Mike Hearn and Gavin Andresen do not own Bitcoin and, emphatically,\n\u003e you cannot have it. Your hard-fork is tantamount to theft and you and\n\u003e your collaborators will effectively ex-communicate yourselves from\n\u003e this project and community. It appears that you are consciously trying\n\u003e to usurp ownership and maintenance of Bitcoin. As if it is that easy!\n\u003e You clearly do not comprehend the array of risks - especially the\n\u003e unanticipated ones. As the market saying goes: \"If you think\n\u003e speculation is easy, it is because you are ignorant about the risks\".\n\u003e If you take the risks with Mike\u0026GavCoin, that would be fine, but you\n\u003e are about to take them with community-owned Bitcoin and Other People's\n\u003e Money!\n\u003e\n\u003e You are causing a lot of stress, unnecessarily, and grave concern\n\u003e surrounds your proposed renegade action. You can dissolve the threat:\n\u003e those players to whom you have made promises can be appeased and\n\u003e eventually get most of what they need from this FOSS project. The\n\u003e developers whom you are railroading to get your way, and the way in\n\u003e which you are doing it, is about to cause a schism that will expand\n\u003e outward from this community.\n\u003e\n\u003e You may accuse the community for being antagonistic to you, and\n\u003e therefore uncooperative, but it is plain to see that your bullheaded\n\u003e manner eventually generates antagonism wherever you go. Taking Bitcoin\n\u003e away from this community, in anger, won't solve the problem and will\n\u003e be like killing the goose that lays the golden eggs.\n\u003e\n\u003e If an individual in an objectively agreed-to FOSS-modelled\n\u003e collaborative project has the audacity to threaten his peers and the\n\u003e world with a unilateral hard-fork despite majority objection and a\n\u003e probability distribution that includes terminal risks and unintended\n\u003e consequences, then what would an impartial outsider think? Some of\n\u003e their thoughts would include that the antagonist could be acting in\n\u003e self-interest, or may be a paid actor, or worse, a saboteur. What\n\u003e would they advise? Stop that individual, at once!\n\u003e\n\u003e Bitcoin is a Free and Open Source Software project that serves as\n\u003e flagship for the blockchain. It has a payment network but the key\n\u003e benefits are censorship resistance and trustless decentralization.\n\u003e There is protocol for how change is effected in a FOSS project. For\n\u003e the sake of everything that is good and useful in Bitcoin, reconsider\n\u003e your dangerous plan and its intended and unintended consequences. Put\n\u003e your feet back on the ground, return to the fold and let the\n\u003e collaborative FOSS model, and the skills available here, gradually\n\u003e scale Bitcoin to your (and all our) grand vision.\n\u003e\n\u003e Venzen Khaosan\n\u003e\n\u003e\n\u003e On 06/15/2015 04:56 PM, Mike Hearn wrote:\n\u003e \u003e Hi Adam,\n\u003e \u003e\n\u003e \u003e Provisional answers below!\n\u003e \u003e\n\u003e \u003e - Are you releasing a BIP for that proposal for review?\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e The work splits like this:\n\u003e \u003e\n\u003e \u003e * Gavin is writing the code and I think a BIP as well\n\u003e \u003e\n\u003e \u003e * I will review both and mostly delegate to Gavin's good taste\n\u003e \u003e around the details, unless there is some very strong disagreement.\n\u003e \u003e But that seems unlikely.\n\u003e \u003e\n\u003e \u003e * I have been handling gitian and the patch rebases, the code\n\u003e \u003e signing and so on, so far. I've also been doing some work to setup\n\u003e \u003e the basic infrastructure of the project (website etc).\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e - If the reviewers all say NACK will you take on board their\n\u003e \u003e suggestions?\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Feedback will be read. There are no NACKS in Bitcoin XT. Patch\n\u003e \u003e requests aren't scored in any way. The final decision rests with\n\u003e \u003e the maintainer as in ~all open source projects.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e - On the idea of a non-consensus hard-fork at all, I think we can\n\u003e \u003e assume you will get a row of NACKs.  Can you explain your\n\u003e \u003e rationale for going ahead anyway?  The risks are well understood\n\u003e \u003e and enormous.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Yes, I have been working on an article that explains how we got to\n\u003e \u003e this point from my perspective. It is quite long, but only because\n\u003e \u003e I want it to be readable for people who weren't following the\n\u003e \u003e debate.\n\u003e \u003e\n\u003e \u003e Anyway, I think I've laid out the gist of it over and over again,\n\u003e \u003e but to summarise:\n\u003e \u003e\n\u003e \u003e If Bitcoin runs out of capacity *it will break and many of our\n\u003e \u003e users will leave*. That is not an acceptable outcome for myself or\n\u003e \u003e the many other wallet, service and merchant developers who have\n\u003e \u003e worked for years to build an ecosystem around this protocol.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e - How do you propose to deal with the extra risks that come from\n\u003e \u003e non-consensus hard-forks?  Hard-forks themselves are quite risky,\n\u003e \u003e but non-consensus ones are extremely dangerous for consensus.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e The approach is the same for other forks. Voting via block versions\n\u003e \u003e and then when there's been \u003eX% for Y time units the 1mb limit is\n\u003e \u003e lifted/replaced.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e - If you're going it alone as it were, are you proposing that you\n\u003e \u003e will personally maintain bitcoin-XT?  Or do you have a plan to\n\u003e \u003e later hand over maintenance to the bitcoin developers?\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Good question!  I have various thoughts on this, but let's wait and\n\u003e \u003e see what happens first. Perhaps the new chain won't get the\n\u003e \u003e majority on it.\n\u003e \u003e\n\u003e \u003e In the event that the \u003e1mb chain does eventually win, I would\n\u003e \u003e expect Core to apply the patch and rejoin the consensus rather than\n\u003e \u003e lose all its users. That would take XT back to being a fairly small\n\u003e \u003e patchset to improve the network protocol.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e - Do you have contingency plans for what to do if the\n\u003e \u003e non-consensus hard-fork goes wrong and $3B is lost as a result?\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Where did you get the $3B figure from? The fork either doesn't\n\u003e \u003e happen, or it happens after quite a long period of people knowing\n\u003e \u003e it's going to happen - for example because their full node is\n\u003e \u003e printing \"You need to upgrade\" messages due to seeing the larger\n\u003e \u003e block version, or because they read the news, or because they heard\n\u003e \u003e about it via some other mechanisms.\n\u003e \u003e\n\u003e \u003e Let me flip the question around. Do you have a contingency plan if\n\u003e \u003e Bitcoin runs out of capacity and significant user disruption occurs\n\u003e \u003e that results in exodus, followed by fall in BTC price? The only one\n\u003e \u003e I've seen is \"we can perform an emergency hard fork in a few\n\u003e \u003e weeks\"!\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e As you can probably tell I think a unilateral fork without\n\u003e \u003e wide-scale consensus from the technical and business communities is\n\u003e \u003e a deeply inadvisable.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Gavin and I have been polling many key players in the ecosystem.\n\u003e \u003e The consensus you seek does exist. All wallet developers (except\n\u003e \u003e Lawrence), all the major exchanges, all the major payment\n\u003e \u003e processors and many of the major mining pools want to see the limit\n\u003e \u003e lifted (I haven't been talking to pools, Gavin has).\n\u003e \u003e\n\u003e \u003e This notion that the change has no consensus is based on you\n\u003e \u003e polling the people directly around you and people who like to spend\n\u003e \u003e all day on this mailing list. It's not an accurate reflection of\n\u003e \u003e the wider Bitcoin community and that is one of the leading reasons\n\u003e \u003e there is going to be a fork. A small number of people have been\n\u003e \u003e flatly ignoring LOTS of highly technical and passionate developers\n\u003e \u003e who have written vast amounts of code, built up the Bitcoin user\n\u003e \u003e base, designed hardware and software, and yes built companies.\n\u003e \u003e\n\u003e \u003e How do you think that makes Bitcoin Core look to the rest of the\n\u003e \u003e Bitcoin world? How much confidence does that give people?\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e Of the overall process, I think you can agree we should not be\n\u003e \u003e making technical decisions with this level of complexity and\n\u003e \u003e consensus risk with financial implications of this magnitude under\n\u003e \u003e duress of haste?\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e This debate will never end until a fork makes it irrelevant. There\n\u003e \u003e is no process for ending it, despite me begging Wladimir to make\n\u003e \u003e one.\n\u003e \u003e\n\u003e \u003e And there is no haste. We have been debating the block size limit\n\u003e \u003e for _years_. We have known it must be lifted for _years_. I kicked\n\u003e \u003e off this current round of debates after realising that Wladimir's\n\u003e \u003e release timeline wouldn't allow a block size limit to be released\n\u003e \u003e before the end of the year. The reason we're talking about it now\n\u003e \u003e and not next year is exactly to ensure there is plenty of time.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e I can sincerely assure you everyone does want to scale bitcoin and\n\u003e \u003e shares your long term objective on that\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e I really wish you were right, and I definitely feel you are one of\n\u003e \u003e the more reasonable ones Adam. But the overwhelming impression I\n\u003e \u003e get from a few others here is that no, they don't want to scale\n\u003e \u003e Bitcoin. They already decided it's a technological dead end. They\n\u003e \u003e want to kick end users out in order to \"incentivise\" (force) the\n\u003e \u003e creation of some other alternative, claiming that it's still\n\u003e \u003e Bitcoin whilst ignoring basic details ... like the fact that no\n\u003e \u003e existing wallets or services would work.\n\u003e \u003e\n\u003e \u003e Scaling Bitcoin can only be achieved by letting it grow, and\n\u003e \u003e letting people tackle each bottleneck as it arises at the right\n\u003e \u003e times. Not by convincing ourselves that success is failure.\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e ------------------------------------------------------------------------------\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________ Bitcoin-development\n\u003e \u003e mailing list Bitcoin-development at lists.sourceforge.net\n\u003e \u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e \u003e\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/5f789e97/attachment.html\u003e"}