<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'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">https://github.com/btc1/bitcoin/issues/34#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'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="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x <span dir="ltr"><<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.linuxfoundation.org</a>></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>"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.</div><div><br></div><div>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).</div><div><br></div><div>I know some don'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="h5"><br><div class="gmail_quote">On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x <span dir="ltr"><<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>></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>
"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."<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_<wbr>contentious_hard_fork_event.<wbr>pdf</a><br>
<br>
This quote specifically calls out "or any other consensus breaking<br>
implementation". 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_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="HOEnZb"><font color="#888888">-- <br><div class="m_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">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>