[Bitcoin-segwit2x] August Status Report for SegWit2x

Jacob Eliosoff jacob.eliosoff at gmail.com
Thu Aug 24 19:03:53 UTC 2017

I mostly agree with Will, but I disagree that replay protection should be
left to the "weaker version", especially since 3 months out we can't be
sure which version that will be.  I'd like to make another plug for simple,
voluntary replay protection on both chains, *at least* on an opt-in basis:
that is, making it easy for wallet/sending software to prevent *in advance*
accidental sends on the wrong chain.  Sergio has sketched a simple version
bits implementation: see eg
https://twitter.com/JaEsf/status/900440066446823424 and

This seems to me an approach that harms no one, would protect the majority
of users on both chains in advance, and - unlike most other replay
proposals - would have good prospects of actually getting adopted.

On Aug 24, 2017 2:42 PM, "Will M via Bitcoin-segwit2x" <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

I may be confused, but I don’t think that’s correct. Had the EDA not
triggered today, the very *first* block of BCC may have confused lite
clients; however, the first BCC block would still confirm with different
transactions than “sister" block on the BTC chain. Because the block header
contains the merkle root of the hash of all transactions in the block, and
also contains the block header hash of the *previous* block, the second
block of BCC would have a different block header hash even without the EDA
difficulty adjustment change. I’m rusty, but I think that’s how it would

Correct or not, what a fascinating conversation! My view is that Bitcoin
Cash had no chance of attaining a majority hash power on the day of the
fork, and because replay protection is not technically very hard or
particularly dangerous to implement, there was every reason to include it.
There was no chance BCC would be compatible 1:1 with existing
wallets/infrastructure, so why not?

That is *not* the case between Segwit2x and Segwit1x. Building in replay
protection will break much of the infrastructure built on top of Bitcoin
for the version that implements it. This puts the implementing version at a
disadvantage by creating more work/cost/risk for the community to support
their project. Since Segwit2x is intentionally designed to become “Bitcoin”
and replace Segwit1x, why would they implement replay protection? Why break
existing infrastructure for itself in order to benefit the version it aims
to replace?

If the weaker version feels threatened, they should implement replay
protection and build contingency plans to mitigate excessively long block
confirmation times. We should all be civil, but it’s OK to not be on the
same “team”, and I think our energy would be better spent if we got back to
focusing on how to make each project more valuable. I’ll just leave it
there. Fascinating read.

On Aug 24, 2017, 11:43 AM -0600, Peter Todd via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org>, wrote:

On Thu, Aug 24, 2017 at 07:31:34PM +0200, Gianluigi Crimi wrote:

The main problem in that statement is not if EDA was triggered or not.
The problem is that it is not and cannot be a soft-fork.
With soft-forks you can increase the difficulty but you cannot decrease it.
If you increase the difficulty with new rules there will not be backward
compatibility issues, but if the difficulty decreases old clients will mark
blocks mined with low POW as invalid.

That's a good point too - using the term "soft-fork" isn't correct. What I
should have said is simply that that BCH's header chain is compatible with
until the emergency difficulty adjustment activates. I definitely replied
too quickly. :)

Of course, that's still a potential problem, albeit one averted by the EDA:
different circumstances where the EDA had not activated, I was correct in
saying that we'd still have a problem for lite clients. Given that the EDA
definitely required lite clients to upgrade anyway it would have been
better if
BCH had also made their block header *always* incompatible with BTC. Making
nVersion incompatible would have been a simple and effective way to do that.

https://petertodd.org 'peter'[:-1]@petertodd.org

Bitcoin-segwit2x mailing list
Bitcoin-segwit2x at lists.linuxfoundation.org

Bitcoin-segwit2x mailing list
Bitcoin-segwit2x at lists.linuxfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170824/ec47cc3f/attachment.html>

More information about the Bitcoin-segwit2x mailing list