[Bitcoin-segwit2x] August Status Report for SegWit2x

Will M will.madden at gmail.com
Thu Aug 24 18:37:15 UTC 2017


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

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 BTC,
> until the emergency difficulty adjustment activates. I definitely replied there
> too quickly. :)
>
> Of course, that's still a potential problem, albeit one averted by the EDA: in
> 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 the
> 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
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170824/e164cfa1/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list