[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Melvin Carvalho melvincarvalho at gmail.com
Tue Oct 10 01:52:46 UTC 2017

On 9 October 2017 at 22:27, Mike Belshe via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> 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.

Thanks for the insight

There are technical arguments surrounding the argument of increasing the
block size from "1MB" to "2MB", as such.

These, imho, were well articulated by adam back at in his talk this weekend
at the hcpp hackers congress [1].  I did raise a question on this topic at
th end,

We can scale highly if we used a central mint to solve double spend.

Somewhere between 2 nodes and billions of nodes lies a sweet spot that
offers the utility of trade, in combination with the defense of

I think the consensus in core is to increase block size in a practical way
with storage (ie moore's law).

This whole problem is a timing question (assuming we stick with proof of
work) and it also involves social issues.

Why dont we just agree the expert consensus is to increase capacity, but
that the timeline for that is not yet agreed.

Heavy handed techniques are likely to be counter productive, when
essentially most parties are in agreement.

[1] https://www.youtube.com/watch?v=mmSuxqaKR2U

> 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 <%28408%29%20718-6885>
> _______________________________________________
> 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/b6514012/attachment.html>

More information about the Bitcoin-segwit2x mailing list