Disentanglement Of Coins In Event of 2 Chains

[danielW]

So in a hypothetical scenario of XT Forking and Bitcoin surviving, we have two separate chains and two eco-systems.

I'm trying to understand what would the implications be for a typical user with some bitcoins on a full node  and some on a SPV wallet.


If he makes a transaction on any full client (XT or Bitcoin), that transaction will be valid on both chains right?

After the transaction(s) gets accepted in a block for each chain, the XT and original-Bitcoin coins are now 'separate'?

By separate I mean that such a user can send coins using an original-Bitcoin full client and that will not move the coins on the XT chain (and vice versa)?

They are not separate before that first transaction?

Now how would this work for coins on a SPV wallet? How would a user separate his coins then?


cheers for help

[1714098192]

1714098192

[1714098192]

1714098192

[1714098192]

1714098192

[Holliday]

You need an input that is invalid on one of the chains in order to safely spend on the other chain.

This could be a coin base mining reward specific to a chain (or children of it).

Also, you might manage to get a transaction to verify in one chain, then "double spend" (not really since its a different chain) those same coins to a different address on the other chain. Once they are confirmed to different addresses in each chain, they would be separate. This method is more complicated, but may be made easier due to different block sizes (get a low priority transaction confirmed in a large block size chain, then rebroadcast it with a high fee to a miner on a small block size chain). You could keep trying (sending coins to yourself so there is no risk) until you finally manage to get them separated.

I don't know of any other methods.

[danielW]

You need an input that is invalid on one of the chains in order to safely spend on the other chain.

This could be a coin base mining reward specific to a chain (or children of it).

Also, you might manage to get a transaction to verify in one chain, then "double spend" (not really since its a different chain) those same coins to a different address on the other chain. Once they are confirmed to different addresses in each chain, they would be separate. This method is more complicated, but may be made easier due to different block sizes (get a low priority transaction confirmed in a large block size chain, then rebroadcast it with a high fee to a miner on a small block size chain). You could keep trying (sending coins to yourself so there is no risk) until you finally manage to get them separated.

I don't know of any other methods.

Hmm, thats because transactions or inputs/outputs don't reference a block hash, right?

If they somehow referenced a block a node could validate that the block exists on the chain it sees.

Would that be possible as a change? It would require a softfork I think.


Moving coins from one address to another, for each block, hoping to separate them could be a very long process. Especially since for a few weeks after the fork the block-size of XT is likely to still be mostly below 1 mb.


There is no way to craft a transaction to get it accepted on one chain but not the other?


It seems separating the coins is actually very difficult to accomplish. Can anybody think of some other mothod?

[danielW]

Ok I think I know how this could work. It can even be a potentially profitable business idea, although thats not the main aim.


So there would be a web service(s). It would need to get hold of some coins (inputs) that were generated after the fork.

The coins could be from either XT or a Bitcoin Block. Any amount will do.


A user would send their bitcoins to the web service, to its address_1. The web service then sends the 'magical' after-fork coins to that address_1. The service then in one transaction moves all those coins to another address_2.

At this point the coins split as that transaction is valid for only one chain. The service then sends both sets of coins from address_1 and address_2 back to the user.


This would work, would it not?

[Holliday]

Ok I think I know how this could work. It can even be a potentially profitable business idea, although thats not the main aim.

So there would be a web service(s). It would need to get hold of some coins (inputs) that were generated after the fork.

The coins could be from either XT or a Bitcoin Block. Any amount will do.

A user would send their bitcoins to the web service, to its address_1. The web service then sends the 'magical' after-fork coins to that address_1. The service then in one transaction moves all those coins to another address_2.

At this point the coins split as that transaction is valid for only one chain. The service then sends both sets of coins from address_1 and address_2 back to the user.

This would work, would it not?

Send my coins to an address where someone else controls the private keys? No thanks.

How about the website simply sells dust from coin base rewards. Once obtained, people can mix it with their own coins easily enough.

The easiest way to get some dust (off the top of my head) is mine at P2Pool (supporting whichever chain you prefer). The coin base reward is split among the P2Pool miners. Of course, this means you'll have to know how to set up P2Pool mining and have some hardware capable of submitting enough valid shares.

[DannyHamilton]

If you know how to create and sign a raw transaction, then the service could work like this:

• Create an unsigned transaction that sends bitcoins that you control to an address (or addresses) that you control, but do not broadcast the transaction.
• Submit the unsigned transaction to the service.
• The service modifies the transaction to include an input that has already been isolated to just one chain (it doesn't matter which chain).
• The service adds to the transaction an output to an address that they control and which is the exact same value as the input that they added.
• The service signs their input, and sends the transaction back to you.
• You review the transaction and make sure that they did not change your inputs or your outputs at all.
• You sign your inputs and broadcast the transaction.

Using this method, your transaction will only be valid on the chain that the service's bitcoins were isolated.  On that chain your coins will move to the new address, on the old chain your coins will remain where they were.  As soon as the transaction is confirmed, the service can re-use their isolated coins to assist someone else.  Now that you have coins that are isolated on each chain, you can re-use those isolated coins (or any fraction of them) to isolate any other coins that you, your friends, or your family have or receive in the future.

[teukon]

There is no way to craft a transaction to get it accepted on one chain but not the other?


It seems separating the coins is actually very difficult to accomplish. Can anybody think of some other mothod?

After a day or so, the two forks will almost certainly differ in height by a few blocks (consider random walks).  At this point, old coins can be neatly separated to different addresses on the different forks using locktime.

[jonny1000]

There would be 7 classes of bitcoin, with potentially different prices:

1. Coins on both chains, which have not been split
2. XT coinbase coins, or coins merged with these
3. Core coinbase coins, or coins merged with these
4. Coins spent in a core block, but double spent to a different output in XT
5. Coins spent in an XT block, but double spent to a different core output.
6. Coins spent in a core block, but unconfirmed in XT
7. Coins spent in an XT block, but unconfirmed in core

This would be complete chaos

[BurtW]

I could imagine a service, kind of like a mixer, that takes two destination addresses and the Bitcoins as input, charges a small fee, taints the coins with some dust and walla!  Sends your coins + some dust - the fee to both outputs.  One would be the XT tainted output and the other the core tainted output.

100 BTC in -> take out 1 BTC (1% fee) -> output 99.01 to one output address and 99.01 to the other output address.

Business idea...

[vane91]

In the event of Fork the sensible thing to do is do not accept incoming deposits as confirmed until a chain/software version has win clearly and you have updated to that version.

[DannyHamilton]

There would be 7 classes of bitcoin, with potentially different prices:

While there might be a difference in value between coins on different blockchains, and I suppose early on there could be a slightly different value for coins that haven't yet been isolated to a single blockchain yet, that's only 3 classes.

1. Coins on both chains, which have not been split
2. XT coinbase coins, or coins merged with these
3. Core coinbase coins, or coins merged with these

There's your 3 classes.

4. Coins spent in a core block, but double spent to a different output in XT

There is no technical difference in spend-ability between these and types 2 & 3 above.  Those spent in a CORE block would be effectively the same as 3, those spent to a different output in XT would effectively be the same as 2.

5. Coins spent in an XT block, but double spent to a different core output.

There is absolutely no difference between 4 & 5.  You just said the same thing twice and reversed the order of the coins.

6. Coins spent in a core block, but unconfirmed in XT
7. Coins spent in an XT block, but unconfirmed in core

Anyone that is accepting unconfirmed coins in exchange for cash is a fool.  These should be treated the same as 2 & 3 until they confirm.

This would be complete chaos

Probably not any more chaotic than all the different altcoins and associated values that we already have.

[DannyHamilton]

In the event of Fork the sensible thing to do is do not accept incoming deposits as confirmed until a chain/software version has win clearly and you have updated to that version.

This is completely unnecessary.

[danielW]

In the event of Fork the sensible thing to do is do not accept incoming deposits as confirmed until a chain/software version has win clearly and you have updated to that version.

This is completely unnecessary.

Well it could be. If you have an XT client, somebody could send you split XT coins. If XT dies and core wins after two weeks those coins are worthless, and you actually have less Bitcoins then you thought. (well you can accept them but should be careful about providing goods or services in exchange).

and vice versa


In the even of a fork tho, I think its possible for two separate coins to emerge. Bitcoin and XT. These coins could exist side by side indefinitely. In-fact some people think it cant happen but I think its very likely.

[skang]

Danny Hamilton's idea is sort of like the atomic swap protocol but it works.
There are two problems though:
1. Everyone absolutely has to use a service to get their coins on a forked chain. Althuogh theoretically it doesn't look like it but conceptually this is a change in the protocol, because without this someone's old bitcoins don't work.
2. What if I double spend? I.e, I try to do the same on both chains simultaneously? Waiting for confirmation on other chain won't work, since it could lead to a deadlock & would require a semaphore to resolve which means requiring coordination between the chains.

[DannyHamilton]

1. Everyone absolutely has to use a service to get their coins on a forked chain.

Why does everyone have to use a service?  Who would run the service?  Would the service need to use a service?  If the service doesn't need to use a service, then nobody has to use a service, because they can all do whatever the service would have done.

Althuogh theoretically it doesn't look like it but conceptually this is a change in the protocol, because without this someone's old bitcoins don't work.

What do you mean "someone's old bitcoins don't work"?  There's no reason that old bitcoins wouldn't work jsut fine as long as there was enough hash power supporting that blockchain.

2. What if I double spend? I.e, I try to do the same on both chains simultaneously?

That's not a double-spend.  That's two completely different spends on two different blockchains.

Waiting for confirmation on other chain won't work, since it could lead to a deadlock & would require a semaphore to resolve which means requiring coordination between the chains.

I don't think you understand how bitcoin works.  Please avoid explaining bitcoin's functionality to new users until you've learned a bit more about the technical details.

[skang]

1. Everyone absolutely has to use a service to get their coins on a forked chain.

Why does everyone have to use a service?  Who would run the service?  Would the service need to use a service?  If the service doesn't need to use a service, then nobody has to use a service, because they can all do whatever the service would have done.

Althuogh theoretically it doesn't look like it but conceptually this is a change in the protocol, because without this someone's old bitcoins don't work.

What do you mean "someone's old bitcoins don't work"?  There's no reason that old bitcoins wouldn't work jsut fine as long as there was enough hash power supporting that blockchain.

2. What if I double spend? I.e, I try to do the same on both chains simultaneously?

That's not a double-spend.  That's two completely different spends on two different blockchains.

Waiting for confirmation on other chain won't work, since it could lead to a deadlock & would require a semaphore to resolve which means requiring coordination between the chains.

I don't think you understand how bitcoin works.  Please avoid explaining bitcoin's functionality to new users until you've learned a bit more about the technical details.

Firstly, you need to calm down Danny. We are just discussing a protocol; ad hominems only drive away respect.
Secondly, I do understand the technical details(perhaps better than you), so either you misunderstood me or I did you.

When I say old bitcoins won't work, I mean they stay entangled and work on both chains which is clearly the problem OP describes.
You gave a protocol for disentanglement, didn't you? I am saying if we don't use it we stay entangled.

In the second point, I did not say you double spent the coins; I said what if I use your protocol to send my pre-fork old coins to both the chains?

[BurtW]

I can and will spend my pre-fork coins on both chains.  That way I end up with all of my pre-forked coins on whatever chain "wins" and becomes the "true" Bitcoin and I also have an equivalent number of coins on the chain that basically becomes the new Alt-Bitcoin chain.

I will have twice as many coins as before the fork but really the same number of "Bitcoins" (on the chain that wins economically and gets to call itself Bitcoin) and the others on the new Alt coin chain.

Now explain what the heck you mean by "Disentaglement" given the scenario I just described.

[DannyHamilton]

Firstly, you need to calm down Danny.

Ok. But only because you told me to.

We are just discussing a protocol

Correct.

ad hominems only drive away respect.

I suppose you're right, but there is a lot of bad information being given by people that act like they are knowledgeable and act like they are sharing "facts".  This just leads to more users misunderstanding things and propagating bad information.

Secondly, I do understand the technical details

Glad to hear it.  So you're aware that there are no deadlocks or semaphores, and that coordination between the chains is not possible then, right?

(perhaps better than you),

Then I look forward to learning from you.  I'm always interested in gaining knowledge from those that know more than me.

so either you misunderstood me or I did you.

Perhaps.

When I say old bitcoins won't work, I mean they stay entangled and work on both chains which is clearly the problem OP describes.

So, they'll still work, but if the output is spent on either chain, it is possible that it will also move on the other chain.

You gave a protocol for disentanglement, didn't you? I am saying if we don't use it we stay entangled.

There are a variety of ways to separate the outputs on the two chains.  I described a method, as did a few other people.  Yes, if the outputs are not disentangled, then you are right they will still be entangled.

In the second point, I did not say you double spent the coins

I think you said:

2. What if I double spend?

I said what if I use your protocol to send my pre-fork old coins to both the chains?

Then one of four things might happen, and you'll need to wait for confirmations to find out which it is:

• The transaction that you send to CORE confirms on both chains.  The outputs are still "entangled"
• The transaction that you send to XT confirms on both chains.  The outputs are still "entangled"
• The transaction that you intend to confirm on the XT chain confirms ONLY on the chain where you intended. The outputs are "disentangeld" the way you wanted
• The transaction that you intend to confirm on the XT chain confirms ONLY on the CORE chain.  The outputs are "disentangeld", but not necessarily the way you intended

[teukon]

I can and will spend my pre-fork coins on both chains.  That way I end up with all of my pre-forked coins on whatever chain "wins" and becomes the "true" Bitcoin and I also have an equivalent number of coins on the chain that basically becomes the new Alt-Bitcoin chain.

I will have twice as many coins as before the fork but really the same number of "Bitcoins" (on the chain that wins economically and gets to call itself Bitcoin) and the others on the new Alt coin chain.

Now explain what the heck you mean by "Disentaglement" given the scenario I just described.

Suppose you have 5 bitcoins going into the fork.  After the fork you automatically have 5 core-coins and 5 XT-coins (outputs on different forks but protected by the same private key).  Suppose you want to spend 2 XT-coins on some alpaca socks.  How can you do this without also sending the merchant 2 core-coins?

To "disentangle" pre-fork coins is to somehow spend the corresponding core-coins and XT-coins to different addresses.

[BurtW]

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.  Are you trying to find something easier?

You could keep sending the same coins back to yourself until you get a transaction on each chain I suppose - but then you have transaction costs.

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

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