Bitcoin Forum

Let's say I have a fork of the blockchain into chains A and B. My client currently only sees A and I submit a transaction.

Would it now be possible that someone else also applies the same transaction to B? Or is the transaction somehow bound to the chain (e.g. by specifying the hash of a chain block that must exist before the transaction is considered valid), so that a transaction submitted for fork A is invalid for fork B.

The reason why I'm asking is that some "Bitcoin banks" seem to only credit received coins after a given number of blocks have passed. If it would be possible to bind a transaction to a specific block chain (e.g., by specifying a required "previous" block) one could avoid this problem, by instantly crediting received coins, but by binding newly sent coins to the same fork of the chain where the previous coins have been received.

The correct chain is the longest one (the one with the greatest embedded difficulty, but it is usually the same thing).  In the case of a tie, the provisionally correct chain is the fork you saw first.

Eventually, one or the other will win.  Even if exactly half of the network considers each branch to be provisionally correct, it is very unlikely for both halves to find a valid continuation at the same time, so one fork will be longer.  A single block fork is unusual, but happens every few hundred blocks.  A two block fork is rare.  I don't think we've seen a three block fork yet.

When that happens, all transactions from the blocks that became invalid are reversed, and added to the pending transaction pool.  If a transaction is no longer valid because it attempts to re-spend previous transactions that were already redeemed in the winning chain, that transaction will not be accepted.

That is why people wait for several blocks to pass before they consider a transaction to be really confirmed.  The deeper it is into the block, the harder it will be to reverse.

That wouldn't solve the problem. Even if you specify a required previous block, there is still no way to know whether the subsequent block that contains this transaction will "win" until sufficient blocks have passed.

In fact, this would make things worse. In the present system, if the block containing the transaction doesn't win, at least you can still perform the transaction if the sender hasn't maliciously attempted a double spend. With your scheme, if the block containing the transaction doesn't win, there is no chance to still perform the transaction.