[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