[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Marcel Jamin marcel at jamin.net
Tue Oct 10 13:33:00 UTC 2017


For visibility -- Gregory Maxwell's reply to Alex Morcos:

> The message you relayed was
> https://0bin.net/paste/T0xP9qKeBmLiOybE#bw8g7mxCLgO1d2Yp29nayYij3lUxv7AgYjBuxz1ynPB
> which requested we endorse a specific prefabricated statement, "I/we
> agree to immediately support the activation of Segregated Witness and
> commit to effectuate a block size increase to 2MB within 12 months"
> which had a long list of signers. This was on May 16th, after they'd
> been circulating this stuff for weeks.

> As you noted, the whole thing was wildly inappropriate and people would have
> rejected attending if they were invited under its stated goals. But I don't
> agree that we were meaningfully invited to collaborate either-- you don't send
> a finished agreement with a long list of signers to someone whos opinion you
> value--, and certainly not under a framework we wouldn't have seen as wildly
> inappropriate.

> Though sure, we at least had a theoretical short notice opportunity to
> attend-- not to actually influence the result, but to add legitimacy to it,
> "gee thanks". :)


On 10 October 2017 at 14:17, Barry Silbert via Bitcoin-segwit2x
<bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> Hi Hubert,
>
>
>
> To clarify, Core was invited.  Alex Morcos was kind enough to confirm via
> Reddit:
>
>
>
> https://www.reddit.com/r/Bitcoin/comments/6d1r96/is_it_not_telling_that_the_core_devs_were_not/dhzc46v/?sh=f688cb33&st=J7CBGTHU
>
> https://www.reddit.com/r/Bitcoin/comments/6cwg98/barry_silbert_bitcoin_scaling_agreement/dhy4oeo/?sh=76d1d2d1&st=J7CBG00Q
>
>
>
>
>
> Barry Silbert
>
> Founder & CEO, Digital Currency Group
>
> www.DCG.co
>
> e: barry at DCG.co
>
> t: (212) 473-2408 | @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.
>
>
>
> Cheers.
>
> Hubert
>
>
>
> 2017-10-09 22:27 GMT+02:00 Mike Belshe <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.
>
>
> Mike
>
>
>
>
>
>
>
>
>
> On Mon, Oct 9, 2017 at 9:58 AM, hubert maslin via Bitcoin-segwit2x
> <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.
>
>
>
> Cheers.
>
> Hubert
>
>
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
>
>
>
>
> --
>
> Mike Belshe
> CEO, BitGo, Inc
> 408-718-6885
>
>
>
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>


More information about the Bitcoin-segwit2x mailing list