[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Sjors Provoost sjors at sprovoost.nl
Tue Oct 10 16:07:39 UTC 2017

> Op 10 okt. 2017, om 16:11 heeft Jeff Garzik via Bitcoin-segwit2x <bitcoin-segwit2x at lists.linuxfoundation.org> het volgende geschreven:
> All,
> This is not an extension of social media.  This is a technical mailing list for discussions related to segwit2x.
> It is self-evident that (1) _not_ upgrading past 1M base block size has been contentious and does not have consensus, and (2) the segwit-only path did not have consensus.  segwit2x solves these problems.
> If there are technical suggestions, please send a technically-specific email or file a PR at github.

I really like RFC 7282 as it suggests a more precise definition of technical rough consensus than what I see on this list. In particular it distinguishes between technical objections and non-technical objections. I assume you're referring to that when saying "consensus". If not, let me know, so we're on the same page with regards to the expected process.

It is my understanding that only miners objected to the SegWit-only path (2) and that they did so without technical arguments. RFC 7282 explicitly addresses situations like that and states that such non-technical objections should be ignored. More precisely, it suggests insisting the miners communicate their technical objections (though perhaps not on this list, as it's too late for that).

It also cautions against the use of polls to measure the level of (dis)agreement, which cuts both ways here.

This RFC makes no guarantees that things move quickly and defaults to doing nothing.

It has a bias towards a more complex solution, when this addresses all issues raised against the simpler solutions, e.g. initial size increase via SegWit soft-fork and various wallet upgrades, rather than just a consensus HF.

It has a bias towards slower deployments and no hard deadlines, since fewer people believe those to be unsafe. Hence Spoonnet HF at some ill defined time in the future, vs. a specific time commitment that SegWit2x signatories would prefer.

This can be quite frustrating. People might even see it as a fatal flaw, still others see it as a strength.

My impression of the SegWit2x deal is that it (temporarily and selectively) abandons RFC 7282 in favor of making progress (in the eyes of its participants).

More important than a size increase, at least to me [1], is that I see this pattern at a more detailed level. There are many unanswered questions about the precise workings of a contentious hard-fork. Specific technical objections against pull requests were raised, but not addressed. These PR's were merged despite that, again for the sake of expediency. The re-opening of the replay attack issue is a good example; it should not have been merged (yet), given that the objections cited for reopening it were raised before the merge. If these objections had been addressed before the merge, there would have been no need to reopen it.

As much as I'm in favor of good replay protection (opt-in both ways at minimum), changing consensus rules five weeks before a hard-fork seems quite dangerous. There's a high likelihood of some critical security bug not getting detected in time. There's even some political and economic incentive to withhold such vulnerabilities until the last moment (e.g. to speculate on BT2 tokens). In addition future scaling work might be hindered, although sunset code could help with that.

Another process issue to think about, is that although a code freeze was scheduled for some time ago, there wasn't a clear fallback plan for when issues were found after the freeze. For example, a good policy could be to postpone the fork to at least N months after any new issue is found. The current deal doesn't provide room for this, which I think people pointed this out from day one. It's probably unwise to set a date in stone before a proposal and working code are fully fleshed out and thoroughly reviewed and tested. It prevents conundrums like having to choose between (a) sticking to the code freeze and not adding replay protection, (b) rushing it in and risking a zero-day or (c) renegotiating a HF block that miners are already signaling for.


[0] https://tools.ietf.org/html/rfc7282 <https://tools.ietf.org/html/rfc7282> (HT Rusty Russel)
[1] this may be my own bias, as it's easier for me to understand these specific problems whereas the scaling debate is quite complex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171010/c03f05ff/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171010/c03f05ff/attachment-0001.sig>

More information about the Bitcoin-segwit2x mailing list