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

Bitcoin Error Log bitcoinerrorlog at gmail.com
Tue Jul 25 18:17:08 UTC 2017


Jared,

What type of data or evidence do you require to agree that the "legacy"
chain will survive and deserve protection? Please provide a standard that
is actually achievable and reasonable. I personally believe you are being
obtuse and that it is quite clear that many users will continue to support
the original Bitcoin, and that your position is unwarranted. The great
majority of Bitcoin developers do not support segwit2x (
https://en.bitcoin.it/wiki/Segwit_support) significant portion of users
enacted BIP148, and afaik, few are even running actual btc1 code and are
merely signaling intent.

~John

On Tue, Jul 25, 2017 at 2:00 PM Jared Lee Richardson 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.
>
> As Jeff Garzik said, this isn't free of costs for the ecosystem to add.
> It requires breaking many things that would otherwise be compatible.
>
> If the evidence shows that the demands/needs for this will be greater than
> the costs, it should be discussed further.  If the only evidence available
> shows that this is an unnecessary burden that is unlikely to provide
> meaningful benefits, it shouldn't be done.  I've provided one important
> data point indicating that this is unlikely to be either necessary or
> helpful.
>
> If there's no data or evidence to counter that, there's not much more
> discussion that can happen.
>
> Jared
>
>
> On Jul 25, 2017 9:14 AM, "Hugh Madden" <hugh at anxintl.com> 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/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
>>>
>>> _______________________________________________
>>> 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
>
-- 

John C
Bitcoin Error Log
www.bitcoinerrorlog.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170725/ba7c65ba/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list