<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"><<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"><span class="">> As a result I'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>
<<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
> It seems clear to me that there is going to be a chain split, so the<br>
> question comes down to who is going to put in the effort to protect users<br>
> from accidentally sending crypto assets that they had no intention of<br>
> sending. Without strong native two way replay protection at the protocol<br>
> level, the responsibility will fall upon every wallet and service provider.<br>
> As a result I'd expect to see a longer period of disruption /<br>
> inaccessibility than we saw with the BCH fork, and probably several orders<br>
> of magnitude greater instances of nontechnical users making mistakes to<br>
> their own detriment.<br>
><br>
> I suspect that such a situation is destined to happen sooner or later given<br>
> the permissionless nature of forks. The grand experiment must go on!<br>
><br>
> On Sun, Oct 8, 2017 at 4:31 PM, Jacob Eliosoff via Bitcoin-segwit2x<br>
> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>><br>
>> Alex, this has of course been much discussed. My 2c:<br>
>><br>
>> A lot of the replay debate comes down to, will the 2x chain accept txs<br>
>> sent post-split, by non-upgraded wallet software? As Mike said, there's<br>
>> strong consensus among Segwit2x folks that proposals which reject these txs<br>
>> (eg, the Bitcoin Cash approach) are a no-go, and a waste of time.<br>
>><br>
>> That said - I and others would love to see good 2-way replay protection if<br>
>> it meets that backwards-compatibility constraint, and there are approaches<br>
>> that do: see eg<br>
>> <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>
>> two chains are competing for users, but there are still ways we could<br>
>> protect all users from unintended sends (which no one wants to happen) if<br>
>> we're civilized about it. Unfortunately these approaches are unlikely to<br>
>> happen without buy-in from Core (eg, to make the 1x chain reject txs<br>
>> explicitly specifying 2x, in exchange for vice versa).<br>
>><br>
>><br>
>><br>
>> On Sun, Oct 8, 2017 at 4:16 PM, Mike Belshe via Bitcoin-segwit2x<br>
>> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>><br>
>>> Alex -<br>
>>><br>
>>> "Replay protection", as you call it, splits the chain. It simply doesn't<br>
>>> make sense- you'd suddenly be breaking 10+million SPV clients that otherwise<br>
>>> work just fine. It is a goal of segwit2x to help avoid this.<br>
>>><br>
>>> Today, we're on course to deploy segwit2x with a vast majority of miners<br>
>>> still signaling for it. On top of that, 99.94% of nodes & SPV clients will<br>
>>> automatically follow that longest chain (segwit2x).<br>
>>><br>
>>> I know some don't want Bitcoin to work this way, but this is the way that<br>
>>> Bitcoin upgrades are implemented.<br>
>>><br>
>>> Mike<br>
>>><br>
>>><br>
>>> On Sun, Oct 8, 2017 at 1:00 PM, Alex Bosworth via Bitcoin-segwit2x<br>
>>> <<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>> wrote:<br>
>>>><br>
>>>> 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>
>>>><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 "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>
>>>><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>
>>><br>
>>><br>
>>><br>
>>><br>
>>> --<br>
>>><br>
>>> Mike Belshe<br>
>>> CEO, BitGo, Inc<br>
>>> <a href="tel:408-718-6885" value="+14087186885">408-718-6885</a><br>
>>><br>
>>><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>
>><br>
>><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>
><br>
><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>
______________________________<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>