<div dir="ltr">The need to use opt-in RBF is in case transaction A, intended for broadcast on the core network, gets replayed* to the s2x network, and accepted into the mempool. This might happen if someone was deliberately replaying transactions, or there might be other more esoteric scenarios. In the case this happens (tx A ends up in the mempool of 2x nodes), I believe <a href="https://github.com/bitcoin/bitcoin/blob/c0e51394139822137ca090f23e60cfe0cad4d123/src/validation.cpp#L499">policy rules would reject</a> transaction B when you broadcast it since it is considered a double-spend, unless you use RBF.<div><div><br></div><div>And yes, I think doing it that way with two copies of electrum, one using a 1x node and one using a 2x, would work (though no guarantees it works every time).</div><div><div><br></div><div>(*or relayed! We expect these networks to be partitioned as soon as an invalid block gets relayed, ie post fork, but given the heterogeneity of nodes - XT, BU, glod knows what else - out there, who knows what might happen, particularly within the first block or two of divergence)<br></div></div></div></div><div class="gmail_extra"><br clear="all"><div><div class="gmail_signature" data-smartmail="gmail_signature"><p><b>Ben Kloester</b><br><span style="font-size:10.0pt;color:#595959"></span></p></div></div>
<br><div class="gmail_quote">On 27 October 2017 at 14:37, Peter <span dir="ltr">&lt;<a href="mailto:dizzle@pointbiz.com" target="_blank">dizzle@pointbiz.com</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="auto"><div>Thank you Ben. </div><div dir="auto"><br></div><div dir="auto">Looks like Electrum supports opt-in RBF. Is the need to use opt-in RBF because someone could be auto replaying the whole network? </div><div dir="auto"><br></div><div dir="auto">In that case if using Electrum should one have two instances connected to the two different chains and try to broadcast on both chains near simultaneously? Like version 1 to 1x and version 2 to 2x?</div><div dir="auto"><br></div><div dir="auto">Are there other GUIs for accomplishing this? </div><div dir="auto"><br></div><div dir="auto">There are python command line tools from Peter Todd. </div><div dir="auto"><br></div><div dir="auto">Regards </div><span class="HOEnZb"><font color="#888888"><div dir="auto">Peter </div></font></span><div><div class="h5"><div dir="auto"><br><div class="gmail_extra" dir="auto"><br><div class="gmail_quote">On Oct 25, 2017 10:16 PM, &quot;Ben Kloester via Bitcoin-segwit2x&quot; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.<wbr>linuxfoundation.org</a>&gt; wrote:<br type="attribution"><blockquote class="m_4556811626082706436quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I&#39;m not sure if you follow the Github but I believe the opt-in replay protection was removed. Hence this thread.<div><br></div><div>I gather the options are:</div><div><br></div><div><ol><li>Get a spend (w RBF) confirmed on one chain to an address you control. Spend the same utxo on the other chain to a different address you control, using RBF possibly with a higher fee. Hope the one that gets confirmed on the second chain is the different address, not the replayed transaction. If not, try again.<br><br><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">Pros: Supported by using existing wallets and block explorers (kind of). No need for help from third parties / miners. No specially constructed transactions.</blockquote><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">Cons: No guarantee it works each time, might take several tries, and fees could get expensive.<br><br></blockquote></li><li>Miners create transactions spending from coinbase outputs with signature hash type <code class="m_4556811626082706436m_-7228831121982685702gmail-highlighter-rouge" style="color:rgb(100,100,100);text-decoration-line:none;font-family:monospace,serif;padding:2px 4px;background-color:rgb(245,245,245);white-space:nowrap;border:1px solid rgb(204,204,204);border-radius:3px"><a href="https://bitcoin.org/en/glossary/sighash-anyonecanpay" title="A signature hash type which signs only the current input." class="m_4556811626082706436m_-7228831121982685702gmail-auto-link" style="color:rgb(100,100,100);text-decoration-line:none;font-family:&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif" target="_blank">SIGHASH_SINGLE|SIGHASH_AN<wbr>YONECANPAY</a></code>  and use some out-of-band means to make these &#39;templates&#39; available. Users can then add their inputs and outputs to the transaction.<br><br>Pros: Is essentially free, is guaranteed to work first try.<br>Cons: 100 blocks before you can spend coinbase outputs! <br><br>Also I think the out-of-band distribution and use of templates also requires some coordination between those wanting to use these &#39;template&#39; transactions to split their coins - in theory one of these templates could be used by many users who all append their inputs and outputs to it, I think, but even if you used 1 template per user wanting to split, you&#39;d ideally make sure that users didn&#39;t just grab the first template and add their splitting transaction to it, or you&#39;d flood the mempool with lots of partial duplicate incompatible transactions.<br><br></li><li>Miners create transactions spending from the bounty outputs, with signature hash type <code class="m_4556811626082706436m_-7228831121982685702gmail-highlighter-rouge" style="color:rgb(100,100,100);font-family:monospace,serif;padding:2px 4px;background-color:rgb(245,245,245);white-space:nowrap;border:1px solid rgb(204,204,204);border-radius:3px"><a href="https://bitcoin.org/en/glossary/sighash-anyonecanpay" title="A signature hash type which signs only the current input." class="m_4556811626082706436m_-7228831121982685702gmail-auto-link" style="color:rgb(100,100,100);text-decoration-line:none;font-family:&quot;Helvetica Neue&quot;,Helvetica,Arial,sans-serif" target="_blank">SIGHASH_SINGLE|SIGHASH_AN<wbr>YONECANPAY</a></code>  and use some out-of-band means to make these &#39;templates&#39; available. Users can then add their inputs and outputs to the transaction.<br><br>Pros: Is essentially free, is guaranteed to work straight away after the fork<br>Cons: No guarantee that the bounty transaction is still valid at the fork height. Same issues with coordinating the use of the templates.<br><br></li><li>Wait until one chain is a couple of blocks ahead of the other, and use an nLocktime transaction with valid height of the higher block height + 1. Since nLocktime transactions that are not yet valid (ie the lock height is above the next block) are not relayed or accepted into the mempool, this should confirm on the longer chain, and be discarded on the slow chain. You can then spend the same output with a different transaction on the slow chain.<br><br>Pros: No need for help from third parties, or coordination, posssibly more likely to work first try than RBF.<br>Cons: Have to wait for chains to diverge (likely tens of minutes only, but this could be an issue for exchanges who will have time pressure). Not clear if it is easily supported in existing wallets? </li></ol></div><div><br>Seems like 3 (assuming the bounty transaction stays valid) and 4 are probably the best options, or if you&#39;re in a hurry then perhaps 1.</div></div><div class="gmail_extra"><br clear="all"><div><div class="m_4556811626082706436m_-7228831121982685702gmail_signature" data-smartmail="gmail_signature"><p><b>Ben Kloester</b><br><span style="font-size:10.0pt;color:#595959"></span></p></div></div><div class="m_4556811626082706436elided-text">
<br><div class="gmail_quote">On 26 October 2017 at 06:41, Hugh Madden 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"><div dir="auto">If I understand correctly, using s2x&#39;s opt in replay protection is the only option that will work safe without needing ongoing splitting for every utxo.<div dir="auto"><br></div><div dir="auto">With ETH/ETH account based blockchain you could just do something to invalidate the nonce and job done.</div><div dir="auto"><br></div><div dir="auto">With 1X / 2X I think you need to split every single uxto.</div><div dir="auto"><br></div><div dir="auto">Easier I think to just use the opt-in replay protection.</div><div dir="auto"><br></div><div dir="auto">The helps with the sends side of the equation.</div><div dir="auto"><br></div><div dir="auto">The bigger issue is deposits and extended period chain reorgs due to flip flopping of hash rate over the two chains.</div><div dir="auto"><br></div><div dir="auto">I don&#39;t have any solution for this except an extended outage. Any thoughts on how many blocks are required to be safe from extended period chain reorgs ?</div></div><div class="m_4556811626082706436m_-7228831121982685702HOEnZb"><div class="m_4556811626082706436m_-7228831121982685702h5"><div class="gmail_extra"><br><div class="gmail_quote">On 25 Oct. 2017 11:08 am, &quot;Christophe Biocca via Bitcoin-segwit2x&quot; &lt;<a href="mailto:bitcoin-segwit2x@lists.linuxfoundation.org" target="_blank">bitcoin-segwit2x@lists.linuxf<wbr>oundation.org</a>&gt; wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><div><div>I&#39;ll also mention for completeness that the big-block bounty transaction (<a href="http://www.blockbounties.info/" target="_blank">http://www.blockbounties.info<wbr>/</a>) has many anyone-can spend outputs which are meant to be used to enable anyone else to add funds to the bounty, but also effectively can be used for splitting funds.<br><br></div>This is similar to the coinbase-tx approach, but can happen essentially immediately post fork (no need to wait 100 blocks).<br><br></div>The downside is that the originator of the transaction could invalidate it before the fork happens, so it&#39;s not 100% guaranteed to work.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 25 October 2017 at 04:24, Tomas 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"><u></u>




<div><span><div>On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote:<br></div>
<blockquote type="cite"><div dir="ltr"><div><br></div>
<div>Coinbase: Have miners agree to send a small amount of newly generated coins to wallet operators as quickly as possible after the fork, to allow wallet operators to split wallets<br></div>
</div>
</blockquote><div><br></div>
</span><div>I don&#39;t think miners actually need to send these coins to wallet operators. <br></div>
<div><br></div>
<div>A miner or someone else who has acquired some newly minted coins can create transactions with one input and one output that pay to self with SIGHASH_SINGLE | SIGHASH_ANYONECANPAY and provide these replay protected transaction &quot;templates&quot; in large numbers over an API for everyone to use.<br></div>
<div><br></div>
<div>Tomas<br></div>
<div>bitcrust<br></div>
</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>
<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></div>
</div></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>
<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></div></div>
</blockquote></div><br></div>