<div dir="ltr">Alex -<div><br></div><div>&quot;Replay protection&quot;, as you call it, splits the chain.  It simply doesn&#39;t make sense- you&#39;d suddenly be breaking 10+million SPV clients that otherwise work just fine.  It is a goal of segwit2x to help avoid this.</div><div><br></div><div>Today, we&#39;re on course to deploy segwit2x with a vast majority of miners still signaling for it.  On top of that, 99.94% of nodes &amp; SPV clients will automatically follow that longest chain (segwit2x).</div><div><br></div><div>I know some don&#39;t want Bitcoin to work this way, but this is the way that Bitcoin upgrades are implemented.  </div><div><br></div><div>Mike</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x <span dir="ltr">&lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">In June of this year I asked about the provisions for strong 2-way<br>
replay protection. Strong 2-way replay protection means transactions<br>
valid on one chain should be invalid on the other, and vice-versa. I<br>
also asked about wipe-out protection, and that has since been<br>
implemented, which is great.<br>
<br>
I talked about the possibility of a contentious hard fork, where<br>
significant value persists across multiple chains. Support for the NYA<br>
hard fork is still lacking from Bitfinex, Local Bitcoins (the largest<br>
volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum,<br>
and many others in the industry and individuals in the development and<br>
broader community.<br>
<br>
I know there has been some fervent hope that the contentious<br>
possibility of this hard fork would abate or become minimal in the<br>
remaining time, and that indeed was a laudable goal. But since June,<br>
contention has only risen. Instead of adding significant support to<br>
the agreement, important and longstanding Bitcoin companies such as<br>
BitWala, F2Pool, and others have pulled out of the New York Agreement<br>
that prompted this project. A number of signers have since decided to<br>
devote their energies to other currency projects, partially or in<br>
full.<br>
<br>
Early results from futures trading shows significant market demand for<br>
both sides of the fork.<br>
<br>
I can now say that preparations have begun in earnest to support both<br>
chains. The possibility of a contentious hard fork now looks like the<br>
probable future reality. Thus, this hard fork should provide strong<br>
2-way replay protection. This means that transactions valid on one<br>
chain should be invalid on the other, and vice-versa. Without this<br>
protection, users would only be able to safely transact on the chains<br>
separately by using explicit splitting techniques, which puts<br>
excessive burden on the end user.<br>
<br>
I can restate suggestions from this list from Sergio Lerner and<br>
WuJihan who have pointed to encouraging multiple visions to coexist,<br>
potentially using a simple sighash modification that will fix the very<br>
simple technical problem that a valid signature authorizing a<br>
transaction of one currency should not be also used as a valid<br>
signature authorizing the transaction of another currency.<br>
<br>
Strong 2-way replay protection will help all businesses regardless of<br>
their position, and help regular users as well. I can quote from an<br>
industry statement regarding the previous contentious hard fork<br>
proposal BTU, which also proposed a hard fork coordinated around 3/4<br>
hash power signaling:<br>
<br>
&quot;However, none of the undersigned can list BTU unless we can run both<br>
chains independently without incident. Consequently, we insist that<br>
the Bitcoin Unlimited community (or any other consensus breaking<br>
implementation) build in strong two-way replay protection. Failure to<br>
do so will impede our ability to preserve BTU for customers and will<br>
either delay or outright preclude the listing of BTU.&quot;<br>
<br>
<a href="https://fs.bitcoinmagazine.com/assets/exchange_handling_of_contentious_hard_fork_event.pdf" rel="noreferrer" target="_blank">https://fs.bitcoinmagazine.<wbr>com/assets/exchange_handling_<wbr>of_contentious_hard_fork_<wbr>event.pdf</a><br>
<br>
This quote specifically calls out &quot;or any other consensus breaking<br>
implementation&quot;. The statement was signed by companies such as<br>
Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina,<br>
coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Sent from my iPhone<br>
______________________________<wbr>_________________<br>
Bitcoin-segwit2x mailing list<br>
<a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>segwit2x</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><p style="font-size:12.8px"><b style="font-size:12.8px;line-height:17px"><font color="#0b5394">Mike Belshe<br></font></b><b style="font-size:12.8px;line-height:17px"><font color="#0b5394">CEO, BitGo, Inc<br></font></b><span style="font-size:12.8px;line-height:17px;color:rgb(102,102,102)">408-718-6885</span></p></div></div></div></div></div></div></div></div></div></div>
</div>