[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Sun Oct 8 22:46:30 UTC 2017

So just to be clear, segwit2x no longer believes there will not be a chain
split come November?

-Chris

On Sun, Oct 8, 2017 at 4:20 PM, Jared Lee Richardson via Bitcoin-segwit2x <
bitcoin-segwit2x at lists.linuxfoundation.org> wrote:

> > As a result I'd expect to see a longer period of disruption /
> inaccessibility than we saw with the BCH fork, and probably several orders
> of magnitude greater instances of nontechnical users making mistakes to
> their own detriment.
>
> Great, so either Core can compromise after 2 years of refusing, or
> Core should be adding strong two-way replay protection the fork that
> is rejecting overwhelming consensus.  The window is probably passing
> for both sides to symmetrically fork as I proposed months ago.
>
> Either way, this project is taking the correct actions with the best
> chance of keeping the community together - Optional replay protection
> for those who care about the drama.
>
> Jared
>
> On Sun, Oct 8, 2017 at 1:40 PM, Jameson Lopp via Bitcoin-segwit2x
> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> > It seems clear to me that there is going to be a chain split, so the
> > question comes down to who is going to put in the effort to protect users
> > from accidentally sending crypto assets that they had no intention of
> > sending. Without strong native two way replay protection at the protocol
> > level, the responsibility will fall upon every wallet and service
> provider.
> > As a result I'd expect to see a longer period of disruption /
> > inaccessibility than we saw with the BCH fork, and probably several
> orders
> > of magnitude greater instances of nontechnical users making mistakes to
> > their own detriment.
> >
> > I suspect that such a situation is destined to happen sooner or later
> given
> > the permissionless nature of forks. The grand experiment must go on!
> >
> > On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x
> > <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> >>
> >> Alex, this has of course been much discussed.  My 2c:
> >>
> >> A lot of the replay debate comes down to, will the 2x chain accept txs
> >> sent post-split, by non-upgraded wallet software?  As Mike said, there's
> >> strong consensus among Segwit2x folks that proposals which reject these
> txs
> >> (eg, the Bitcoin Cash approach) are a no-go, and a waste of time.
> >>
> >> That said - I and others would love to see good 2-way replay protection
> if
> >> it meets that backwards-compatibility constraint, and there are
> approaches
> >> that do: see eg
> >> https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611.
> Yes, the
> >> two chains are competing for users, but there are still ways we could
> >> protect all users from unintended sends (which no one wants to happen)
> if
> >> we're civilized about it.  Unfortunately these approaches are unlikely
> to
> >> happen without buy-in from Core (eg, to make the 1x chain reject txs
> >> explicitly specifying 2x, in exchange for vice versa).
> >>
> >>
> >>
> >> On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x
> >> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> >>>
> >>> Alex -
> >>>
> >>> "Replay protection", as you call it, splits the chain.  It simply
> doesn't
> >>> make sense- you'd suddenly be breaking 10+million SPV clients that
> otherwise
> >>> work just fine.  It is a goal of segwit2x to help avoid this.
> >>>
> >>> Today, we're on course to deploy segwit2x with a vast majority of
> miners
> >>> still signaling for it.  On top of that, 99.94% of nodes & SPV clients
> will
> >>> automatically follow that longest chain (segwit2x).
> >>>
> >>> I know some don't want Bitcoin to work this way, but this is the way
> that
> >>> Bitcoin upgrades are implemented.
> >>>
> >>> Mike
> >>>
> >>>
> >>> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x
> >>> <bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
> >>>>
> >>>> In June of this year I asked about the provisions for strong 2-way
> >>>> replay protection. Strong 2-way replay protection means transactions
> >>>> valid on one chain should be invalid on the other, and vice-versa. I
> >>>> also asked about wipe-out protection, and that has since been
> >>>> implemented, which is great.
> >>>>
> >>>> I talked about the possibility of a contentious hard fork, where
> >>>> significant value persists across multiple chains. Support for the NYA
> >>>> hard fork is still lacking from Bitfinex, Local Bitcoins (the largest
> >>>> volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum,
> >>>> and many others in the industry and individuals in the development and
> >>>> broader community.
> >>>>
> >>>> I know there has been some fervent hope that the contentious
> >>>> possibility of this hard fork would abate or become minimal in the
> >>>> remaining time, and that indeed was a laudable goal. But since June,
> >>>> contention has only risen. Instead of adding significant support to
> >>>> the agreement, important and longstanding Bitcoin companies such as
> >>>> BitWala, F2Pool, and others have pulled out of the New York Agreement
> >>>> that prompted this project. A number of signers have since decided to
> >>>> devote their energies to other currency projects, partially or in
> >>>> full.
> >>>>
> >>>> Early results from futures trading shows significant market demand for
> >>>> both sides of the fork.
> >>>>
> >>>> I can now say that preparations have begun in earnest to support both
> >>>> chains. The possibility of a contentious hard fork now looks like the
> >>>> probable future reality. Thus, this hard fork should provide strong
> >>>> 2-way replay protection. This means that transactions valid on one
> >>>> chain should be invalid on the other, and vice-versa. Without this
> >>>> protection, users would only be able to safely transact on the chains
> >>>> separately by using explicit splitting techniques, which puts
> >>>> excessive burden on the end user.
> >>>>
> >>>> I can restate suggestions from this list from Sergio Lerner and
> >>>> WuJihan who have pointed to encouraging multiple visions to coexist,
> >>>> potentially using a simple sighash modification that will fix the very
> >>>> simple technical problem that a valid signature authorizing a
> >>>> transaction of one currency should not be also used as a valid
> >>>> signature authorizing the transaction of another currency.
> >>>>
> >>>> Strong 2-way replay protection will help all businesses regardless of
> >>>> their position, and help regular users as well. I can quote from an
> >>>> industry statement regarding the previous contentious hard fork
> >>>> proposal BTU, which also proposed a hard fork coordinated around 3/4
> >>>> hash power signaling:
> >>>>
> >>>> "However, none of the undersigned can list BTU unless we can run both
> >>>> chains independently without incident. Consequently, we insist that
> >>>> the Bitcoin Unlimited community (or any other consensus breaking
> >>>> implementation) build in strong two-way replay protection. Failure to
> >>>> do so will impede our ability to preserve BTU for customers and will
> >>>> either delay or outright preclude the listing of BTU."
> >>>>
> >>>>
> >>>> https://fs.bitcoinmagazine.com/assets/exchange_handling_
> of_contentious_hard_fork_event.pdf
> >>>>
> >>>> This quote specifically calls out "or any other consensus breaking
> >>>> implementation". The statement was signed by companies such as
> >>>> Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina,
> >>>> coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift.
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Sent from my iPhone
> >>>> _______________________________________________
> >>>> Bitcoin-segwit2x mailing list
> >>>> Bitcoin-segwit2x at lists.linuxfoundation.org
> >>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
> >>>
> >>>
> >>>
> >>>
> >>> --
> >>>
> >>> Mike Belshe
> >>> CEO, BitGo, Inc
> >>> 408-718-6885
> >>>
> >>>
> >>> _______________________________________________
> >>> 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
> >
> _______________________________________________
> 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/20171008/2f0f2e32/attachment-0001.html>