[Bitcoin-segwit2x] Bitcoin Cash's mandatory replay protection - an example for B2X

[Peter Todd]

Good example of forkcoin doing the right thing here:

https://github.com/Bitcoin-ABC/bitcoin-abc/commit/e49826c1fcc36e5ae26de0ad4d06e2063a759e73

tl;dr: They took advantage of the fact that some SIGHASH bits are undefined,
and non-standard. 0x40 is defined as SIGHASH_FORKID, and setting that bit is
required by the standardness rules when the coin launches and thus splits off
from the Bitcoin consensus.

The disadvantage of this just being a standardness rule is that miners could
still maliciously mine transactions intended for the other chain, but given
that BCC is launching in just a few days - and the theoretical problem of
nLockTime'd transactions - I think it just being a standardness rule is a
reasonable compromise. They can soft-fork in mandatory enforcement of it later
as well.

Note the discussion around the issue: https://github.com/Bitcoin-ABC/bitcoin-abc/issues/24

It's very clear that wallets, merchants, and exchanges need strong replay
protection to be able to support new currencies; the B2X forkcoin will be no
different. Equally, failing to do so will expose users to losses due to
valuable tokens being accidentally sent when they didn't intend to.

Given that Garzik has made clear that the exact consensus rules of 2x are open
to change in the bit4/bit1 post a few days ago, we have every reason to
implement proper replay protection, and unlike BCC, we have a few months to get
this right.


Concretely, I would suggest we do two things:

1) Redefine another unused SIGHASH bit as a replay-protection _opt-out_, to
allow nLockTime'd transactions to choose not to be protected by replay.

2) Change SignatureHash() to so that signatures for non-opt-out transactions
are incompatible. A simple way to do this would be to re-hash the signature
digest with a B2X-specific tag.


Also worth considering is creating a way for signatures to commit to a recent -
but not too recent - block hash as an additional replay/rollback protection.
Large reorgs are an issue here, which is why previous discussions of this idea
in the Bitcoin dev community have resulted in the proposal of only allowing
blocks >100 deep to be committed to in this way, similar to how genesis outputs
can be spent only after 100 confirmations.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170725/bacf9bc7/attachment.sig>