8

What happens when a forked chain becomes longer than the main block chain?

Let's assume the forked chain that just became longer has no transactions in it, so it is as if every transaction in the last n blocks never happened.

As I understand it, the official Bitcoin client will recognize that any recent transactions it sent no longer exist and will re-broadcast them. By question is,

  • What age transactions will be re-issued? Will a transaction that is years old still be reissued? What's the cutoff?
  • Does the exact transaction get reissued or does an equivalent transaction get created? i.e. will it attempt to send the exact same Bitcoins (which, due to the fork, might no longer actually be owned) or will it create an equivalent transaction based on Bitcoins that it still owns? What if the client doesn't have enough Bitcoins?

Edit: Since I can't find where I first saw it anymore, I guess I should also ask: does the official client, in fact, reissue transactions in the event of a block chain fork?

Improve this question

2 Answers 2

Reset to default
3

Transactions you've sent will be resent forever (every 30 minutes or so), even if they have no chance of getting in the chain because they are now invalid. The same transactions are sent -- new ones aren't created.

Improve this answer
2
  • This conflict's with sipa's answer. You wrote "even if they have no chance of getting in the chain because they are now invalid" and he wrote "under the condition that they are valid in the new chain". Who's right?
    – Chris Moore
    Mar 10, 2012 at 21:29
  • 3
    We were talking about different things: * the owner of the transaction will retransmit under the condition his transaction is not accepted (anymore), even if it has no chance. * other nodes will, in the case of a reorganization, move transactions back to the memory pool, if they are valid in the new chain. This is unrelated to rebroadcasting.
    – Pieter Wuille
    Mar 11, 2012 at 0:43
6

In the case of a reorganization, the transactions that were 'lost' in the previous longer chain are moved back to the memory pool, under the condition that they are valid in the new chain. This means that if the inputs do not exist anymore in the new chain, they are lost. This is precisely how a "double spend attack" works: try to fork the chain, and spend the coins in both branches.

The effect of moving transactions back to the memory pool is only that the client does not forget them (it will not reannounce, or download them from peers when told about them), and if the node is a miner, they will be candidates for inclusion in the next block created.

In general, this means that there are no retransmits: miners and the rest of the network try their best to not forget about these lost transactions. If that fails however, and for some reason (too little fee, for example) the transaction does not survive, it is the responsibility of the node that originally sent the transaction out to rebroadcast. So yes, there are retransmits as well, but only by the original owner, and only when it detects the transaction is not or no longer in the block chain.

It's always a byte-for-byte identical transaction, not an equivalent using different inputs.

Improve this answer
5
  • "under the condition that they are valid in the new chain" - where's this condition in the code? I just scanned for it but didn't see it.
    – Chris Moore
    Mar 10, 2012 at 21:35
  • 1
    ::Reorganize in main.cpp resurrects the lost transactions by feeding them to AcceptToMemory pool, which calls the same checks that are done as on transactions that arrive as a tx message.
    – Pieter Wuille
    Mar 11, 2012 at 0:42
  • It does, but it does it before RemoveFromMemoryPool is called for the transactions which were on the previous best fork, and so isn't it the case that the checks could pass due to transactions which only existed on the old branch, and will soon no longer exist?
    – Chris Moore
    Mar 11, 2012 at 6:28
  • 1
    vConnect is the list of transactions in the newly connected branch.
    – Pieter Wuille
    Mar 11, 2012 at 15:13
  • > "it will not reannounce" So it isn't in the sender's best interest to re-announce if planning to double spend. Sounds like an attack vector to address.
    – Stephen Gornick
    Mar 15, 2013 at 4:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.