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

Ben Kloester benkloester at gmail.com
Thu Oct 26 02:16:58 UTC 2017


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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/attachments/20171026/b07794dd/attachment-0001.html>


More information about the Bitcoin-segwit2x mailing list