[Bitcoin-segwit2x] Strong 2-Way Replay Protection

Mike Belshe mike at bitgo.com
Sun Oct 8 20:16:02 UTC 2017

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.


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

More information about the Bitcoin-segwit2x mailing list