[Bitcoin-segwit2x] Orderly Process for Coin-Splitting after the fork

Fri Oct 27 04:15:36 UTC 2017

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 policy
rules would reject
<https://github.com/bitcoin/bitcoin/blob/c0e51394139822137ca090f23e60cfe0cad4d123/src/validation.cpp#L499>
transaction B when you broadcast it since it is considered a double-spend,
unless you use RBF.

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).

(*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)

*Ben Kloester*

On 27 October 2017 at 14:37, Peter <dizzle at pointbiz.com> wrote:

> Thank you Ben.
>
> Looks like Electrum supports opt-in RBF. Is the need to use opt-in RBF
> because someone could be auto replaying the whole network?
>
> 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?
>
> Are there other GUIs for accomplishing this?
>
> There are python command line tools from Peter Todd.
>
> Regards
> Peter
>
>
> On Oct 25, 2017 10:16 PM, "Ben Kloester via Bitcoin-segwit2x" <
> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>
> I'm not sure if you follow the Github but I believe the opt-in replay
> protection was removed. Hence this thread.
>
> I gather the options are:
>
>
>    1. 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.
>
>    Pros: Supported by using existing wallets and block explorers (kind
>    of). No need for help from third parties / miners. No specially constructed
>    transactions.
>
>    Cons: No guarantee it works each time, might take several tries, and
>    fees could get expensive.
>
>    2. Miners create transactions spending from coinbase outputs with
>    signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
>    <https://bitcoin.org/en/glossary/sighash-anyonecanpay>  and use some
>    out-of-band means to make these 'templates' available. Users can then add
>    their inputs and outputs to the transaction.
>
>    Pros: Is essentially free, is guaranteed to work first try.
>    Cons: 100 blocks before you can spend coinbase outputs!
>
>    Also I think the out-of-band distribution and use of templates also
>    requires some coordination between those wanting to use these 'template'
>    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'd
>    ideally make sure that users didn't just grab the first template and add
>    their splitting transaction to it, or you'd flood the mempool with lots of
>    partial duplicate incompatible transactions.
>
>    3. Miners create transactions spending from the bounty outputs, with
>    signature hash type SIGHASH_SINGLE|SIGHASH_ANYONECANPAY
>    <https://bitcoin.org/en/glossary/sighash-anyonecanpay>  and use some
>    out-of-band means to make these 'templates' available. Users can then add
>    their inputs and outputs to the transaction.
>
>    Pros: Is essentially free, is guaranteed to work straight away after
>    the fork
>    Cons: No guarantee that the bounty transaction is still valid at the
>    fork height. Same issues with coordinating the use of the templates.
>
>    4. 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.
>
>    Pros: No need for help from third parties, or coordination, posssibly
>    more likely to work first try than RBF.
>    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?
>
>
> Seems like 3 (assuming the bounty transaction stays valid) and 4 are
> probably the best options, or if you're in a hurry then perhaps 1.
>
> *Ben Kloester*
>
> On 26 October 2017 at 06:41, Hugh Madden via Bitcoin-segwit2x <
> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>
>> If I understand correctly, using s2x's opt in replay protection is the
>> only option that will work safe without needing ongoing splitting for every
>> utxo.
>>
>> With ETH/ETH account based blockchain you could just do something to
>> invalidate the nonce and job done.
>>
>> With 1X / 2X I think you need to split every single uxto.
>>
>> Easier I think to just use the opt-in replay protection.
>>
>> The helps with the sends side of the equation.
>>
>> The bigger issue is deposits and extended period chain reorgs due to flip
>> flopping of hash rate over the two chains.
>>
>> I don'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 ?
>>
>> On 25 Oct. 2017 11:08 am, "Christophe Biocca via Bitcoin-segwit2x" <
>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>
>>> I'll also mention for completeness that the big-block bounty transaction
>>> (http://www.blockbounties.info/) 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.
>>>
>>> This is similar to the coinbase-tx approach, but can happen essentially
>>> immediately post fork (no need to wait 100 blocks).
>>>
>>> The downside is that the originator of the transaction could invalidate
>>> it before the fork happens, so it's not 100% guaranteed to work.
>>>
>>> On 25 October 2017 at 04:24, Tomas via Bitcoin-segwit2x <
>>> bitcoin-segwit2x at lists.linuxfoundation.org> wrote:
>>>
>>>> On Tue, Oct 24, 2017, at 22:41, Moe Adham via Bitcoin-segwit2x wrote:
>>>>
>>>>
>>>> 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
>>>>
>>>>
>>>> I don't think miners actually need to send these coins to wallet
>>>> operators.
>>>>
>>>> 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 "templates" in large numbers over an API for everyone to use.
>>>>
>>>> Tomas
>>>> bitcrust
>>>>
>>>> _______________________________________________
>>>> Bitcoin-segwit2x mailing list
>>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Bitcoin-segwit2x mailing list
>>> Bitcoin-segwit2x at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>>
>>>
>> _______________________________________________
>> Bitcoin-segwit2x mailing list
>> Bitcoin-segwit2x at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>>
>>
>
> _______________________________________________
> Bitcoin-segwit2x mailing list
> Bitcoin-segwit2x at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-segwit2x
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171027/9d15814a/attachment-0001.html>