<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 8 October 2017 at 22:00, Alex Bosworth 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">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.<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></blockquote><div><br></div><div>Apologies in advanced if I've missed something here. I think the following is a technical argument that's worth pointing out explicitly.<br></div><div><br>Without replay protection, doesnt publishing a transaction to a block or even the UXTO, amount to publishing sensitive customer / user information. <br><br>For example, would it not be similar to publishing the credit card details of one of your customers.<br><br></div><div>If so, I would suspect that this would violate the law in many, if not all, jurisdictions.<br><br></div><div>If my above assumptions are correct (there may be a flaw in my logic that I've not seen), does that not mean almost all the companies supporting seg2x will have to implement replay protection individually.<br><br></div><div>Therefore, would it not make sense to just do it at the protocol level, or holding off the timing of the release of the fork until the futures market indicates there will not be a chain split?<br></div> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<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></div></div>