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

[Jeff Garzik]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20170727/c0c0772c/attachment-0001.html>