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

Jared Lee Richardson jaredr26 at gmail.com
Tue Jul 25 17:58:39 UTC 2017


> I think it's quite clear at this point that if segwit2x proceeds with a
HF in November, then there will be a split and there will be two
currencies.

If this was quite clear, there would be evidence to support it.  Where's
the evidence?

> Even just the minor forking of Bitcoin Cash has created quite a stir from
users all throughout the ecosystem who don't understand what precautions
they may need to take.

Right, but in that case there is readily available evidence that their
split will still leave a viable competing chain.  Requesting evidence is
not an insurmountable bar.

We don't have the ability to control any fears that may be spread by
individuals supporting the legacy chain, and if there is to be two coins
then I agree that a discussion regarding replay protection is warranted.
Though I would argue it is responsibility of the chain lacking measurable
overwhelming support to add replay protection, at least I'd be open to the
discussion.  But as far as the evidence shows, the two competing coins
situation appears unlikely, and as stated before there are major costs
associated with the decision.

If exchanges and wallets feel that replay protection is necessary, I'm sure
many of them will speak up, especially as Jeff mentioned that there is an
outreach process (see also the recent compatibility summary on github).
Evidence supporting the two-chain situations' likelihood would also help
this.

Jared

On Jul 25, 2017 10:00 AM, "Alex Morcos via Bitcoin-segwit2x" <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> I apologize since I know that this list is not the correct place for
> posturing about whose fork is bigger, but I do think it would make a lot of
> sense for the segwit2x project to have a serious conversation with hosted
> wallets, exchanges and other custodial entities about the risks associated
> with not providing replay protection.  I think it's quite clear at this
> point that if segwit2x proceeds with a HF in November, then there will be a
> split and there will be two currencies.  You may be right that the legacy
> coin ends up non-viable, but I don't see any way to be assured of that
> ahead of time, and quite frankly, I believe the opposite.  Even just the
> minor forking of Bitcoin Cash has created quite a stir from users all
> throughout the ecosystem who don't understand what precautions they may
> need to take. Please, let's not end up with a last minute scramble in
> November.
>
>
>
> On Tue, Jul 25, 2017 at 12:37 PM, Jeff Garzik via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>
>> Requiring all wallets to update / breaking all wallets is a non-starter.
>>
>>
>> On Tue, Jul 25, 2017 at 12:14 PM, Hugh Madden via Bitcoin-segwit2x <
>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>>> Any and all forks can add replay protection. It doesn't signify winner
>>> and loser, it signifies the maintainers of the [non]fork have a desire to
>>> provide tools to make it easier to protect customer funds.
>>>
>>> On Jul 26, 2017 12:02 AM, "Jared Lee Richardson via Bitcoin-segwit2x" <
>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>>
>>>> If the legacy chain had measurable support indicating that it would
>>>> remain viable, this would be important.  Do you have evidence that the
>>>> legacy chain has enough support to be viable post fork?
>>>>
>>>> Right now between signalling and signatories, btc1 has ~95% of the
>>>> hashpower.  ~5% of the hashpower is not enough to be viable without a
>>>> hardfork, in which case it would be more appropriate and less damaging for
>>>> the ecosystem for the non-majority hardfork to add replay protection.
>>>> Thus, replay protection would be a net loss for everyone if added to btc1.
>>>>
>>>> Please provide evidence that the legacy chain will be viable to justify
>>>> btc1 adding replay protection.  With no evidence, this request isn't going
>>>> to go anywhere.
>>>>
>>>> Jared
>>>>
>>>> On Jul 25, 2017 5:24 AM, "Peter Todd via Bitcoin-segwit2x" <
>>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>>>
>>>>> Good example of forkcoin doing the right thing here:
>>>>>
>>>>> https://github.com/Bitcoin-ABC/bitcoin-abc/commit/e49826c1fc
>>>>> c36e5ae26de0ad4d06e2063a759e73
>>>>>
>>>>> 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
>>>>>
>>>>> _______________________________________________
>>>>> Bitcoin-segwit2x mailing list
>>>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Bitcoin-segwit2x mailing list
>>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>>
>>>>
>>> _______________________________________________
>>> Bitcoin-segwit2x mailing list
>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>
>>>
>>
>>
>> --
>> Jeff Garzik
>> CEO and Co Founder
>> Bloq, Inc.
>>
>>
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>
>>
>
> _______________________________________________
> 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/20170725/5fd46f30/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list