[Bitcoin-segwit2x] Strong 2-Way Replay Protection

bitPico bitpico at icloud.com
Sun Oct 8 20:43:04 UTC 2017


We will not be altering our non-Satoshi codebase to implement something that is:

1. Not needed (1x is legacy code)
2. Splits the chain (for no good reason)
3. Breaks all existing SPV nodes including ours (see 2.)

There are at least four other non-Satoshi code full nodes and it’s unlikely they will modify their code either for the same reasons above.

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

More information about the Bitcoin-segwit2x mailing list