[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Barry Silbert barry at dcg.co
Tue Oct 10 12:17:51 UTC 2017

Hi Hubert,

To clarify, Core was invited.  Alex Morcos was kind enough to confirm via Reddit:


Barry Silbert
Founder & CEO, Digital Currency Group
e: barry at DCG.co<mailto:barry at DCG.co>
t: (212) 473-2408 | @BarrySilbert<https://twitter.com/BarrySilbert>
636 Avenue of the Americas (Entrance on 19th St.)
New York, NY 10011

From: bitcoin-segwit2x-bounces at lists.linuxfoundation.org [mailto:bitcoin-segwit2x-bounces at lists.linuxfoundation.org] On Behalf Of hubert maslin via Bitcoin-segwit2x
Sent: Tuesday, October 10, 2017 5:32 AM
To: BitGo - Mike Belshe <mike at bitgo.com>
Cc: bitcoin-segwit2x at lists.linuxfoundation.org
Subject: Re: [Bitcoin-segwit2x] Strong 2-Way Replay Protection

I get your frustration that the ecosystem resists a lot to something that's a no-brainer upgrade for you, but this resistance is a feature, not a bug, and in my opinion Segwit2X was the wrong vehicle to achieve an upgrade of this kind from the beginning.

Bitcoin is not an enterprise database that your supplier can upgrade in a week, it's a *shared* global decentralised ledger, it's an infrastructure used by millions (and hopefully billions in the future) of people who all have their own reasons to use it and their own preferences. It's to be expected by upgrading such a thing will be a long and contentious process.

If you want the support of developers, investors and power users, you have to make this 2X base block size (now block weight) increase palatable to them, by asking them whether they might to see some other changes bundled with it, and also by having enough time to develop, test and deploy the fork (for example 6 months for development/testing and a year for deployment). Replay protection is also a must, so that those whose wishes haven't been fulfilled by the fork can easily stay on their chain, without feeling like they're marginalised, or held hostages.

I know this isn't a psychology or anthropology mailing list, but I'd like to make a point about human nature, that explains why debates get so heated so easily.
People don't like to back down to so much as the smallest slights or disrespect, because of the implicit assumption that such a retreat would only lead to greater agression or disrespect in the future - this is why violent conflicts often arise from seemingly benign squabbles. This assumption is literally built in us; it's a by-product of our evolution, because those humans who reacted to threats of agression instead of waiting for an actual agression to take place might have had better odds of survival. Suppose that we do as you wish and agree on this fork: what tells us that a year from now some other group of CEOs will not come up with a perfectly valid reason to implement address blacklisting at the protocol level, or change Bitcoin's inflation schedule? Having backed down to the November 2017 2X hard fork would make it harder for us to resist the ones to come.
The fact that we mistrust people whose objectives and group membership differ from ours is a truth as fundamental as the fact that we breathe, eat or drink. To disarm this natural mistrust, the process that leads to the definition and implementation of the fork has to be as inclusive, egalitarian and open as possible, so that all voices can be heard. The process might actually matters even more than its own product - the fork design - because the process itself is an expression of the balance of economic power among the different stakeholders; and it would be dangerous to artificially sway this balance through manipulation, disinformation or outrage.

You refer to the risk of the hard fork being small. But focusing on pure technical risks misses the point: the main risk of this fork (and the main reason why so many of us are opposed to it) is the fact that it opens the door to further contentious changes in the future. There's an element of recursion here - the fork is contentious because it sets a bad precedent of a contentious change having been made -  and that's because the design process it stems from wasn't open and collaborative.

You can't get together at a private meeting (from what I've understood, developers other than those closely affiliated to you weren't invited), agree among yourselves to redesign Bitcoin and expect other stakeholders to follow you. It's sad that Segwit2X chose that path, because many early adopters and investors are realistic and understand that a block weight increase will very likely be needed in the future, because even if we could get a large part of the bitcoin economy to use paiement channels, we would still have to have enough room to settle them.

I'm afraid it's too late to call off the fork, as you've all already invested so much time and energy in it. I think (and hope) that the fork will fail, and that the B2X chain will never gain any significant economic value - precisely because it would be so vulnerable to arbitrary changes in consensus rules from external actors.

In any case I hope that the next iterations of the scaling debate will be more open and collaborative, and see cool heads prevail.


2017-10-09 22:27 GMT+02:00 Mike Belshe <mike at bitgo.com<mailto:mike at bitgo.com>>:
Thanks for the lengthy reply.  Your argument can go both ways; why not support this 2mb block size increase?  The risk has already been mitigated - miners will adopt it, businesses will support it, and its compatible with 99.5% of existing wallets. Now, if the core team would start trying to help it work, instead of fighting it for pride and emotional reasons, we'd even have all the developer support behind it....   There are no technical arguments remaining against it - just lengthy prose about misunderstandings and what not.

You imply that planning for growth/scalability has a correlated risk of destabilization that accompanies it.  If we took that as our guiding principle, we wouldn't implement segwit either.  Sure, segwit is opt-in at the user level, but its not opt-in at the chain level - we all are dependent on it working properly or the chain which we share breaks for all of us. The 2x part of Segwit2x is, by any measure, a simpler technical change.   I would never say that changes carry no risk, but as far as risk goes, this one is really small.

It's a good opportunity now to just move to 2mb blocks, and there are literally no technical objections left.


On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org<mailto:bitcoin-segwit2x at lists.linuxfoundation.org>> wrote:
Hello Mike, I understand that you're meaning well and want, as we all do, bitcoin to succeed over long term, and by reading your messages on this thread I've once again noticed that the current rift within the Bitcoin community actually springs from a few disagreements that have more to do with culture and process rather than with long term goals. I'm going to talk about those disagreements and hopefully state the "pro decentralisation" position in a way that's conducive to intelligent debate and perhaps, ultimate agreement.

We want to bring Bitcoin to more users because it has unique features and qualities (namely permissionless-ness, resistance to tx censorship, resistance to inflation, pseudonymity) that the existing financial system doesn't offer. The presence of these features is contrary to the interests of many powerful entities (the legacy banking system, governments and their surveillance agencies) and only survive thanks to Bitcoin's decentralisation and absence of centralised points of failure. Being willing to sacrifice or endanger Bitcoin's decentralisation to achieve scaling isn't wise or forward thinking, and is completely self-defeating. What's the point of on-boarding an ever greater number of users if you run the risk of weakening those features and give those users the same experience than current centralised paiement systems offer, e.g. tx censorship, vulnerability to inflation, and government surveillance? This would be a nonsensical and unproductive thing to do.

Doing this would be all the more absurd that we now know (as we have since 2015) that, before increasing base block size, we can greatly increase throughput through more efficient of block space (with Segwit and, in the near future, with MAST, Schnorr signatures and signatures aggregation) and more importantly, with second layer technologies such as the Lightning Network or sidechains. These technologies are under rapid development, and will soon alleviate scaling.

Presenting the scaling debate as a dichotomy between "onboard users fast and break things" and "let's for ever stay a store of value for rich people" is a mistake, because we know we can already greatly improve scaling, within the next few months and years. Was scaling slower than anticipated, we should err on the side of caution, and not give our potential adversaries any lever that they might pull to weaken those features.

And this is why this scheduled hard fork worries me. Regardless of the blockchain bloating issue, changing consensus rules without wide community consensus - and in particular without the consensus of the community members that value decentralisation and privacy the most - is precisely such a lever for governments or other antagonists to pull.
It would set an extremely bad precedent. The particulars of this fork -  the fact that it doesn't have replay protection, that it lays a claim on the Bitcoin brand, that it relies on the imperfect security models of SPV wallets to make them follow new consensus rules - make things worse.

if this fork is successful and the entire community shifts to the S2X chain (which, barring a prolonged 51% attack on the original chain, seems extremely unlikely to me), this would signals to external actors that consensus rules can be changed by exercising the right pressure on the right companies - and we're literally talking of a dozen mining pools and a dozen major paiement processors and exchanges, spread in only a few jurisdictions. This would cast doubt on the entire ability of cryptocurrencies to remain decentralised and act as censorship-resistant medium of exchange and inflation-resistant store of value. Bitcoin's sole comparative advantage over centralised systems would vanish.

Even if this fork wasn't a base block size doubling but a simple, symbolic increase of one byte to base block size, it would still be a bad thing, because it would show that consensus rules - and therefore the very nature of the currency people use - can be changed by external actors. To me and to many other people, this debate isn't about block size anymore: it's about the survivability of Bitcoin as a decentralised system. The Bitcoin community should be as amorphous and resistant to change as possible - even to more technically sound changes like Segwit, and even when these changes come from competent devs with a solid track record of defending decentralisation and privacy.

Just because only a few thousands or dozens of thousands of early users and cypherpunks out of a dozen million of users disagree with this fork doesn't mean we can be ignored: Bitcoin rose to its current popularity (and value) because we invested our time, our hopes and our money in it, and millions of politically unresponsive BitPay or Coinbase customers will not make up for our absence on a centralised chain.

Claiming that Segwit2X has consensus with the now standard line "those who oppose it are only a few thousands, while NYA signatories have millions of customers" is akin to the NSA claiming that a majority of citizens endorses surveillance, "because only a few thousands nerds care about it". Claiming the silence of a majority of stakeholders as a tacit endorsement of some policy is a dangerous (and I would add immoral) thing to do, and is what has led to the creation of the centralised institutions that Bitcoin aims at replacing.

Bitcoin is a formidable opportunity to bring greater monetary, economic and political freedom to all humans, and the single best hope of freedom-loving persons in this otherwise authoritarian and freedom-hating century. Regardless of whatever understanding or sympathy we may have for you and other NYA signatories, we who care about those things can not accept cooptation by companies who effectively are centralised points of failure at the mercy of governments.

If I could sum up my position (and the position of many users preoccupied with decentralisation), it would be: "let us scale wisely, without making short-term compromises that would weaken Bitcoin's unique features". Merely increasing base block size as soon as we lack space would be akin to kicking the can down the road to serfdom. And changing consensus rules at a whim - or worse, engaging in a 51% attack to coerce the community into following the new rules - would get us there in no time.

And to respond to one of your points, Mike, wishing for both chains to survive is certainly not about "pride": it's about giving a durable, decentralised consensus system to the world, a system that can't be coopted, coerced or censored.

Mike, if you have any question or wish to continue this chat privately feel free to respond directly to this email. I feel that the differences between our respective camps are born out of cultural differences and absurd misunderstandings, and magnified by our good ol' tribal instincts; there is no reason why we should go through a messy divorce when we all agree on making Bitcoin the world's sole currency, used for both small purchases and storing large amount of values. This is Bitcoin's destiny, and our squabbles are petty in comparison.


Bitcoin-segwit2x mailing list
Bitcoin-segwit2x at lists.linuxfoundation.org<mailto:Bitcoin-segwit2x at lists.linuxfoundation.org>


Mike Belshe
CEO, BitGo, Inc

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171010/be16a657/attachment-0001.html>

More information about the Bitcoin-segwit2x mailing list