<div dir="ltr">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&#39;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.<div><br></div><div>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!</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff 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"><div dir="ltr">Alex, this has of course been much discussed.  My 2c:<div><ol><li>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&#39;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.<br><br></li><li>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 <a href="https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611" target="_blank">https://github.com/btc1/<wbr>bitcoin/issues/34#<wbr>issuecomment-329251611</a>.  Yes, the two chains are competing for users, but there are still ways we could protect <i>all</i> users from unintended sends (which no one wants to happen) if we&#39;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).<br></li></ol><div><br></div></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x <span dir="ltr">&lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.<wbr>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"><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"><div><div class="m_-5536704206310079866h5"><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.linuxf<wbr>oundation.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.com<wbr>/assets/exchange_handling_of_c<wbr>ontentious_hard_fork_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="m_-5536704206310079866m_6964632136269496479HOEnZb"><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" target="_blank">Bitcoin-segwit2x@lists.linuxfo<wbr>undation.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-s<wbr>egwit2x</a><br>
</font></span></blockquote></div><br><br clear="all"><div><br></div></div></div><span class="m_-5536704206310079866HOEnZb"><font color="#888888">-- <br><div class="m_-5536704206310079866m_6964632136269496479gmail_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)"><a href="tel:(408)%20718-6885" value="+14087186885" target="_blank">408-718-6885</a></span></p></div></div></div></div></div></div></div></div></div></div>
</font></span></div>
<br>______________________________<wbr>_________________<br>
Bitcoin-segwit2x mailing list<br>
<a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">Bitcoin-segwit2x@lists.linuxfo<wbr>undation.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-s<wbr>egwit2x</a><br>
<br></blockquote></div><br></div>
</div></div><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>
<br></blockquote></div><br></div>