[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Jacob Eliosoff jacob.eliosoff at gmail.com
Sun Oct 8 20:31:48 UTC 2017

Alex, this has of course been much discussed.  My 2c:

   1. 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.

   2. 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 <(408)%20718-6885>
> _______________________________________________
> 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/76a12f1a/attachment-0001.html>

More information about the Bitcoin-segwit2x mailing list