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

Hugh Madden hugh at anxintl.com
Tue Jul 25 20:57:59 UTC 2017


> If exchanges and wallets feel that replay protection is necessary
I'm saying yes, and IMO all the others will say yes, particularly if they
experienced ETC/ETH.

Can it be done without breaking existing wallets and client implements?

ETH added it without breaking existing wallets and clients; admittedly I
haven't looked at the details.

Should we chalk this up as a request for proposal ?

On Jul 26, 2017 1:58 AM, "Jared Lee Richardson via Bitcoin-segwit2x" <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> > 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
>>
>>
> _______________________________________________
> 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/20170726/ea4fcef2/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list