[Bitcoin-segwit2x] Notes on segwit2x and anti-replay methods

Jared Lee Richardson jaredr26 at gmail.com
Thu Jul 27 23:46:31 UTC 2017


> (Note that option b requires both chains to push a change to invalidate post-HF txs by default.  It seems extremely unlikely that either chain will do this if the other doesn't.)

I would support this proposal but I find it extremely unlikely that
both chains would implement and roll-out those rule changes.  Barring
that, an optional replay protection mechanism would be the least
disruptive choice for this hardfork based on the support currently
measurable.

Jared

On Thu, Jul 27, 2017 at 11:41 AM, Jacob Eliosoff via Bitcoin-segwit2x
<bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> Let me make another plug for "breaking wallets" -
>
> I understand many both believe and hope that the Nov HF will be decisive and
> ~all of Bitcoin will move onto the 2x chain.  But the fact is it's still
> likely that some subset of users will stick to the old 1x chain (perhaps
> itself forked).  I support Segwit2x, but those 1x users are Bitcoin users
> too and the outcome for them deserves consideration.  In particular I see
> two main realistic options:
>
> a) Both 2x and 1x chains cheerfully accept un-upgraded post-HF transactions.
>    Downside: some users sending txs from old wallets find they've
> accidentally sent on both chains (replay effect).
>
> b) Both chains reject post-HF txs, until the wallet has been upgraded.
>    Downside: users have to upgrade their software, and specify which chain
> they mean, before they can send any the post-HF txs.
>
> (Note that option b requires both chains to push a change to invalidate
> post-HF txs by default.  It seems extremely unlikely that either chain will
> do this if the other doesn't.)
>
> I would argue that:
>
> The inconvenience of having to upgrade software sometime in the next 4
> months is not comparable to the inconvenience of accidentally sending on the
> wrong chain
> In practice most software will be upgraded:
> - The HF is getting plenty of press
> - The software changes required to enable post-HF txs should be minor
> - Many end-users transact via websites/services that can be expected to
> upgrade
>
> Sergio or his upcoming BIP may shed further light, but I believe "breaking
> wallets" in this easily-fixable way is the lesser evil here.
>
>
> On Thu, Jul 27, 2017 at 9:02 AM, Jeff Garzik via Bitcoin-segwit2x
> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>> Quick addendum:
>>
>> 7) I'm a big fan of luke-jr's OP_CHECKBLOCKATHEIGHT personally
>> https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
>>
>> That seems worth mentioning in this thread, though out of scope of
>> segwit2x charter and seemingly in need of further review and noodling.
>>
>>
>>
>> On Thu, Jul 27, 2017 at 8:52 AM, Jeff Garzik <jeff at bloq.com> wrote:
>>>
>>> Given recent threads, it seemed useful to summarize the status of
>>> segwit2x vis anti-replay.
>>>
>>> 1) Thanks to all for some healthy debate on btc1 Slack's #debate channel,
>>> as well as in public.
>>>
>>> 2) anti-replay is currently an open issue:
>>> https://github.com/btc1/bitcoin/issues/34  Being an open issue implies that
>>> we are actively soliciting suggestions and solutions.
>>>
>>> 3) In informal discussions, I've termed segwit2x a "node HF", meaning
>>> that it is somewhat of a hybrid fork, somewhere between soft fork and hard
>>> fork.
>>>
>>> 3a) In a soft fork, nodes and SPV wallets auto-accept new rules
>>> (opt-out).  At most a "new rules!" warning is emitted, but operation
>>> otherwise continues under the new ruleset.
>>>
>>> 3b) In a "pure" hard fork, nodes and SPV wallets do not auto-accept new
>>> rules, and must upgrade to adopt (opt-in).
>>>
>>> 3c) In segwit2x, nodes and SPV wallets split the difference.  nodes do
>>> not auto-accept new rules, but many wallets, notably SPV wallets, will.
>>>
>>> 4) It is good to provide some sort of facility such that SPV wallets may
>>> also emit a "new rules" warning for the segwit2x 2M HF upgrade, to match the
>>> experience of an opt-out soft fork upgrade.  James Hilliard's PR was
>>> re-opened for this purpose: https://github.com/btc1/bitcoin/pull/46
>>>
>>> 5) It is not good to include a change that breaks all wallets (meaning,
>>> requires upgrade to continue working post-2M HF).  The likely case is that
>>> the NYA participants and 80+% hashpower will upgrade to 2M BBSI.  Thus, in
>>> the the likely "one chain" outcome, a break-all-wallets change would be
>>> unnecessarily disruptive to users (to make a large understatement).
>>>
>>> 6) This leaves us with a range of solutions that include opt-in replay
>>> protection (#34) and HF visibility via block version bit (#46).  Gavin's
>>> suggestion is in #34.  Sergio had another suggestion on twitter last night.
>>> Both seem viable, because they are opt-in.
>>>
>>> --
>>> Jeff Garzik
>>> CEO and Co Founder
>>> Bloq, Inc.
>>>
>>
>>
>>
>> --
>> 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
>


More information about the Bitcoin-segwit2x mailing list