[Bitcoin-segwit2x] replay protection and spinoffs vs collaboration

Jacob Eliosoff jacob.eliosoff at gmail.com
Tue Jul 25 23:29:34 UTC 2017


1. THE REAL ISSUE: UN-UPGRADED USERS

I think this replay discussion has been dancing around the real issue.  No
one objects in principle to "protecting" one chain from the other's
transactions or "protecting" users from replay confusion.  The real issue
is, if in Dec some user opens her old wallet and sends a transaction, which
chain does it transact on?

a) Both: almost definitely not what she intended
b) Segwit2x chain but not legacy: but this will harm some legacy users, and
gives Segwit2x a big inertial/Schelling advantage
c) Legacy chain but not Segwit2x: same problem in reverse
d) Neither - the transaction fails, she has to update her software (and
specify which chain): fair and avoids wrong-chain accidents, but obviously
disruptive

There is no purely technical fix here: none of these four options are
ideal, and yet one of them must happen.  So it's disingenuous for
*either* chain's
advocates to make arguments like "Why don't you just..." or "It's a basic
precaution to...".  Both chains want these un-upgraded users, and I think
we're more likely to find solutions if we're upfront about it.


2. A PROPOSAL: PUT THE USERS FIRST - PROTECT THEM BY MAKING THEM CHOOSE

Here's a plug for d) above: force users to explicitly choose one chain or
the other in their transactions.  (Symmetrically, as Staf described.)
 Details could vary, but eg:

1. Add a chain-marker field to transactions that specifies either "legacy"
or "2x"
2. Core rolls out a soft fork that, after block 494784 (the late-Nov hard
fork), *rejects transactions that don't specify "legacy"*
3. Similarly, Segwit2x adds logic that after block 494784, *rejects
transactions that don't specify "2x"*
4. Wallets and other businesses are then strongly encouraged to implement
logic that, after block 494784, requires users to specify which
chain-marker to include.  Until they do, their transactions are (to be
safe) rejected by *both* chains.

I realize many in Core are deeply averse to a change like this that
explicitly breaks old software.  But frankly - this is what a truly
customer-oriented organization would do, if the alternative was to risk
users accidentally sending on the wrong chain.  And the realistic
alternative I see is, you demand Sw2x make their own blocks invalid, they
refuse, the HF happens and many wallets end up following hashrate.  Is that
really a better outcome for users?

I believe the ~4 months until the HF is enough time for clients to
implement the logic above.  Note that Poloniex implemented full support for
ETH/ETC (trading, withdrawals, deposits) in ~4 days
<https://twitter.com/Poloniex/status/757068619234803712>.

And btw, I'd make an exactly analogous argument (as Zooko already has
<https://twitter.com/zooko/status/877874435147124736>) about naming: both
chains want the name "Bitcoin"; but *at least for now,* let's give them two
clear names ("Bitcoin 1x" and "Bitcoin 2x"?).  Frankly, for both chains to
insist on trying to keep the name "Bitcoin" right from the moment of the HF
is putting partisan squabbling ahead of users.


On Tue, Jul 25, 2017 at 6:58 PM, Staf Verhaegen via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> Jared Lee Richardson schreef op di 25-07-2017 om 14:54 [-0700]:
> > > This way users really determined to not go the segwit2x route can
> > > upgrade and generate transaction not going in the segwit2x chain.
> > > Non-upgraded wallets just signal then that they don't mind to which
> > > chain they will be going to.
> >
> > This would be one-way strictly optional replay protection, which BCC
> > originally planned to include.
> >
> > I think I could support that, but it would be of limited use and is
> > almost certain to be unsatisfactory for those demanding strong two-way
> > replay protection.
>
> Analog, a don't-include-in-core signal can be PRed to Core to have a
> fully symmetrical solution. In the future we may have this generalized
> so that each hard fork includes a way for transactions to signal to not
> include them in a block on the forked chain.
> This would be a fully symmetrical solution giving the users who care a
> means to choose and at least it removes the argument that users are
> forced into something.
>
> As far as I have seen a strong two-way replay protection is in conflict
> with keeping compatibility with current wallet implementations.
>
> greets,
> Staf.
>
>
>
> _______________________________________________
> 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/c87a6c2a/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list