<div dir="ltr"><div>So just to be clear, segwit2x no longer believes there will not be a chain split come November? <br><br></div>-Chris<br></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 8, 2017 at 4:20 PM, Jared Lee Richardson 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"><span class="">&gt; 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.<br>
<br>
</span>Great, so either Core can compromise after 2 years of refusing, or<br>
Core should be adding strong two-way replay protection the fork that<br>
is rejecting overwhelming consensus.  The window is probably passing<br>
for both sides to symmetrically fork as I proposed months ago.<br>
<br>
Either way, this project is taking the correct actions with the best<br>
chance of keeping the community together - Optional replay protection<br>
for those who care about the drama.<br>
<br>
Jared<br>
<div class="HOEnZb"><div class="h5"><br>
On Sun, Oct 8, 2017 at 1:40 PM, Jameson Lopp via Bitcoin-segwit2x<br>
&lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; It seems clear to me that there is going to be a chain split, so the<br>
&gt; question comes down to who is going to put in the effort to protect users<br>
&gt; from accidentally sending crypto assets that they had no intention of<br>
&gt; sending. Without strong native two way replay protection at the protocol<br>
&gt; level, the responsibility will fall upon every wallet and service provider.<br>
&gt; As a result I&#39;d expect to see a longer period of disruption /<br>
&gt; inaccessibility than we saw with the BCH fork, and probably several orders<br>
&gt; of magnitude greater instances of nontechnical users making mistakes to<br>
&gt; their own detriment.<br>
&gt;<br>
&gt; I suspect that such a situation is destined to happen sooner or later given<br>
&gt; the permissionless nature of forks. The grand experiment must go on!<br>
&gt;<br>
&gt; On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x<br>
&gt; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;<br>
&gt;&gt; Alex, this has of course been much discussed.  My 2c:<br>
&gt;&gt;<br>
&gt;&gt; A lot of the replay debate comes down to, will the 2x chain accept txs<br>
&gt;&gt; sent post-split, by non-upgraded wallet software?  As Mike said, there&#39;s<br>
&gt;&gt; strong consensus among Segwit2x folks that proposals which reject these txs<br>
&gt;&gt; (eg, the Bitcoin Cash approach) are a no-go, and a waste of time.<br>
&gt;&gt;<br>
&gt;&gt; That said - I and others would love to see good 2-way replay protection if<br>
&gt;&gt; it meets that backwards-compatibility constraint, and there are approaches<br>
&gt;&gt; that do: see eg<br>
&gt;&gt; <a href="https://github.com/btc1/bitcoin/issues/34#issuecomment-329251611" rel="noreferrer" target="_blank">https://github.com/btc1/<wbr>bitcoin/issues/34#<wbr>issuecomment-329251611</a>.  Yes, the<br>
&gt;&gt; two chains are competing for users, but there are still ways we could<br>
&gt;&gt; protect all users from unintended sends (which no one wants to happen) if<br>
&gt;&gt; we&#39;re civilized about it.  Unfortunately these approaches are unlikely to<br>
&gt;&gt; happen without buy-in from Core (eg, to make the 1x chain reject txs<br>
&gt;&gt; explicitly specifying 2x, in exchange for vice versa).<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x<br>
&gt;&gt; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Alex -<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; &quot;Replay protection&quot;, as you call it, splits the chain.  It simply doesn&#39;t<br>
&gt;&gt;&gt; make sense- you&#39;d suddenly be breaking 10+million SPV clients that otherwise<br>
&gt;&gt;&gt; work just fine.  It is a goal of segwit2x to help avoid this.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Today, we&#39;re on course to deploy segwit2x with a vast majority of miners<br>
&gt;&gt;&gt; still signaling for it.  On top of that, 99.94% of nodes &amp; SPV clients will<br>
&gt;&gt;&gt; automatically follow that longest chain (segwit2x).<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; I know some don&#39;t want Bitcoin to work this way, but this is the way that<br>
&gt;&gt;&gt; Bitcoin upgrades are implemented.<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Mike<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x<br>
&gt;&gt;&gt; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; In June of this year I asked about the provisions for strong 2-way<br>
&gt;&gt;&gt;&gt; replay protection. Strong 2-way replay protection means transactions<br>
&gt;&gt;&gt;&gt; valid on one chain should be invalid on the other, and vice-versa. I<br>
&gt;&gt;&gt;&gt; also asked about wipe-out protection, and that has since been<br>
&gt;&gt;&gt;&gt; implemented, which is great.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I talked about the possibility of a contentious hard fork, where<br>
&gt;&gt;&gt;&gt; significant value persists across multiple chains. Support for the NYA<br>
&gt;&gt;&gt;&gt; hard fork is still lacking from Bitfinex, Local Bitcoins (the largest<br>
&gt;&gt;&gt;&gt; volume peer to peer exchange), Slush Pool, Trezor, Ledger, Electrum,<br>
&gt;&gt;&gt;&gt; and many others in the industry and individuals in the development and<br>
&gt;&gt;&gt;&gt; broader community.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I know there has been some fervent hope that the contentious<br>
&gt;&gt;&gt;&gt; possibility of this hard fork would abate or become minimal in the<br>
&gt;&gt;&gt;&gt; remaining time, and that indeed was a laudable goal. But since June,<br>
&gt;&gt;&gt;&gt; contention has only risen. Instead of adding significant support to<br>
&gt;&gt;&gt;&gt; the agreement, important and longstanding Bitcoin companies such as<br>
&gt;&gt;&gt;&gt; BitWala, F2Pool, and others have pulled out of the New York Agreement<br>
&gt;&gt;&gt;&gt; that prompted this project. A number of signers have since decided to<br>
&gt;&gt;&gt;&gt; devote their energies to other currency projects, partially or in<br>
&gt;&gt;&gt;&gt; full.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Early results from futures trading shows significant market demand for<br>
&gt;&gt;&gt;&gt; both sides of the fork.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I can now say that preparations have begun in earnest to support both<br>
&gt;&gt;&gt;&gt; chains. The possibility of a contentious hard fork now looks like the<br>
&gt;&gt;&gt;&gt; probable future reality. Thus, this hard fork should provide strong<br>
&gt;&gt;&gt;&gt; 2-way replay protection. This means that transactions valid on one<br>
&gt;&gt;&gt;&gt; chain should be invalid on the other, and vice-versa. Without this<br>
&gt;&gt;&gt;&gt; protection, users would only be able to safely transact on the chains<br>
&gt;&gt;&gt;&gt; separately by using explicit splitting techniques, which puts<br>
&gt;&gt;&gt;&gt; excessive burden on the end user.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; I can restate suggestions from this list from Sergio Lerner and<br>
&gt;&gt;&gt;&gt; WuJihan who have pointed to encouraging multiple visions to coexist,<br>
&gt;&gt;&gt;&gt; potentially using a simple sighash modification that will fix the very<br>
&gt;&gt;&gt;&gt; simple technical problem that a valid signature authorizing a<br>
&gt;&gt;&gt;&gt; transaction of one currency should not be also used as a valid<br>
&gt;&gt;&gt;&gt; signature authorizing the transaction of another currency.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; Strong 2-way replay protection will help all businesses regardless of<br>
&gt;&gt;&gt;&gt; their position, and help regular users as well. I can quote from an<br>
&gt;&gt;&gt;&gt; industry statement regarding the previous contentious hard fork<br>
&gt;&gt;&gt;&gt; proposal BTU, which also proposed a hard fork coordinated around 3/4<br>
&gt;&gt;&gt;&gt; hash power signaling:<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; &quot;However, none of the undersigned can list BTU unless we can run both<br>
&gt;&gt;&gt;&gt; chains independently without incident. Consequently, we insist that<br>
&gt;&gt;&gt;&gt; the Bitcoin Unlimited community (or any other consensus breaking<br>
&gt;&gt;&gt;&gt; implementation) build in strong two-way replay protection. Failure to<br>
&gt;&gt;&gt;&gt; do so will impede our ability to preserve BTU for customers and will<br>
&gt;&gt;&gt;&gt; either delay or outright preclude the listing of BTU.&quot;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; <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>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; This quote specifically calls out &quot;or any other consensus breaking<br>
&gt;&gt;&gt;&gt; implementation&quot;. The statement was signed by companies such as<br>
&gt;&gt;&gt;&gt; Bitstamp, Bitfinex, bitso, bitsquare, bittrex, btcc, btcchina,<br>
&gt;&gt;&gt;&gt; coinfloor, itbit, Kraken, QuadrigaCX, and ShapeShift.<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt;<br>
&gt;&gt;&gt;&gt; --<br>
&gt;&gt;&gt;&gt; Sent from my iPhone<br>
&gt;&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt;&gt; Bitcoin-segwit2x mailing list<br>
&gt;&gt;&gt;&gt; <a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;&gt;&gt; <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>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; --<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; Mike Belshe<br>
&gt;&gt;&gt; CEO, BitGo, Inc<br>
&gt;&gt;&gt; <a href="tel:408-718-6885" value="+14087186885">408-718-6885</a><br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt;<br>
&gt;&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt;&gt; Bitcoin-segwit2x mailing list<br>
&gt;&gt;&gt; <a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt;&gt; <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>
&gt;&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; ______________________________<wbr>_________________<br>
&gt;&gt; Bitcoin-segwit2x mailing list<br>
&gt;&gt; <a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
&gt;&gt; <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>
&gt;&gt;<br>
&gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; Bitcoin-segwit2x mailing list<br>
&gt; <a href="mailto:Bitcoin-segwit2x@lists.linuxfoundation.org">Bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a><br>
&gt; <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>
&gt;<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>
</div></div></blockquote></div><br></div>