[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Alex Morcos morcos at gmail.com
Tue Oct 10 13:38:50 UTC 2017


To set the record straight.
It was clear to me that Barry would have liked us to attend the meeting
regardless of any intention to sign the agreement.
It is possible I did not convey that clearly to a half dozen other Core
developers in passing on the invitation although I tried to.

But I was biased against any Core developers attending because:
a) I did not feel the other participants in the meeting would have
appreciated us being there if our intention was not to "compromise"
b) I did not feel it was Core's place to represent the opposition to the
intended agreement or negotiate on behalf of the opposition. (i.e. ever
attend a meeting like this)



On Tue, Oct 10, 2017 at 9:33 AM, Marcel Jamin via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> For visibility -- Gregory Maxwell's reply to Alex Morcos:
>
> > The message you relayed was
> > https://0bin.net/paste/T0xP9qKeBmLiOybE#bw8g7mxCLgO1d2Yp29nayYij3lUxv7
> AgYjBuxz1ynPB
> > 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
> >
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171010/95fb3a18/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list