Disentanglement Of Coins In Event of 2 Chains

[teukon]

OK I have 5 BTC before the fork, these coins are deemed good by both types of nodes and miners.

I buy some dust that is only valid on the XT chain, and some dust that is only valid on the Core chain.

I then send the 5 BTC + the XT dust to an address I control.  These 5 BTC + XT dust are only valid and only seen by the XT nodes and miners on the XT chain.  The transaction will be rejected by the Core nodes, miners and chain.

I send the same 5 BTC + the Core dust to an address I control. These 5 BTC + Core dust are only valid and only seen by the Core nodes and miners on the Core chain.  The transaction will be rejected by the XT nodes, miners and chain.

Then all I need to do is keep track of which address contains my XT coins and which address contains my Core coins.

I think that will work.

Yes, this is one solution.  It has been suggested that this kind of functional taint could be offered as a trustless service.

Are you trying to find something easier?

Not myself, I'm happy with my locktime solution.  Still, something even cleaner would be interesting.

[1715554585]

1715554585

[1715554585]

1715554585

[1715554585]

1715554585

[1715554585]

1715554585

[danielW]

OK I have 5 BTC before the fork, these coins are deemed good by both types of nodes and miners.

I buy some dust that is only valid on the XT chain, and some dust that is only valid on the Core chain.

I then send the 5 BTC + the XT dust to an address I control.  These 5 BTC + XT dust are only valid and only seen by the XT nodes and miners on the XT chain.  The transaction will be rejected by the Core nodes, miners and chain.

I send the same 5 BTC + the Core dust to an address I control. These 5 BTC + Core dust are only valid and only seen by the Core nodes and miners on the Core chain.  The transaction will be rejected by the XT nodes, miners and chain.

Then all I need to do is keep track of which address contains my XT coins and which address contains my Core coins.

I think that will work.

Yes, this is one solution.  It has been suggested that this kind of functional taint could be offered as a trustless service.

Are you trying to find something easier?

Not myself, I'm happy with my locktime solution.  Still, something even cleaner would be interesting.

Do you mind explaining how you would split them using locktime ?

[teukon]

Do you mind explaining how you would split them using locktime ?

Not at all.  The two forks would commonly have different heights (consider random walks).  I would broadcast a transaction with a locktime equal to the height of the longest fork, spending my coins to address X.  This transaction would be accepted into the longer fork's blockchain but would have to wait in the mempool of the shorter fork for a while before it could be similarly included.  After getting a couple of confirmations on the longer fork, I would broadcast a second transaction (without locktime), spending my coins to address Y.  This transaction would be invalid on the longer fork (the coins have already been spent) but would be fine on the shorter fork (an update to a locktime transaction in the mempool).

Should the two forks be close in height (say within 10 blocks of one another) I would just wait for them to diverge.