Orphaned blocks and transactions on them

[miln40]

So I was browsing the blockchain and found an split, which I guess happens relatively often.

http://blockchain.info/block/00000000000001cc6e543922dd64d6e1f743f678a9e5db96aaa6bd48c598d9ed

My questions are:
we have transactions on both blocks. What happens with the ones on the orphaned block? They are not carried out and then people have one less confirmation that they would normally have for the same time?

second, what determines if a block is orphaned? Why did the system choose one over the other?

Thanks,
M

[1714033129]

1714033129

[1714033129]

1714033129

[tiberiandusk]

If a block is found at nearly the same time I believe it goes to the timestamp to see which was first. If your transaction was only listed in the orphaned block you would just need to wait till the next block comes around.

[Stephen Gornick]

we have transactions on both blocks. What happens with the ones on the orphaned block?

Consider that there are two miners, Alice and Bob, and the last solved block was a block at height 100.  So both are trying to solve for block 101.  Bob may have some transactions that Alice doesn't yet include and vice-versa.

Then say both happen to solve a block 101 at about the same time and broadcast their 101 to their peers.

A peer node X happens to learn first of Alice's block 101. and any transactions in Alice's 101 will now show as 1/unconfirmed.   Then X learns of Bob's block 101.  X will still store that block (as a side branch) but will still treat Alice's block 101 as the last solved block.   Any transactions that were added exclusively by Bob in his block 101 will still show as 0/unconfirmed by node X.  

If another miner, Charlie, instead first learned of a block at height 101 from a peer relayed Bob's block 101, then it is trying to solve for block 102, Charlie solves it and broadcasts it and thus Charlie's peers propagate it and eventually it reaches X.

Now X confirms Charlie's 102 is valid and thus takes that side branch that included Bob's 101 and makes it the main branch after appending to it Charlie's block 102.   Alice's 101 is now a side branch (which causes her 101 to be an orphan).  If there were any transactions that Alice had shown as 1/unconfirmed in which neither Bob nor Charlie had added, then X will now display 0/unconfirmed for that transaction.  

 - http://en.bitcoin.it/wiki/Protocol_rules#.22block.22_messages

So to recap ...  when X learned of Alice's block 101 first it added it as being valid, and any other blocks for 101 that arrived later (e.g., Bob's block 101) were added to a side branch.  So the winner at any block height is the first valid block to arrive at each specific node.  Thus there is an incentive to miners to see their blocks propagate as quickly as possible, and the smaller the block (fewer transactions) the faster it will be verified and relayed by each node.  There are orphaned blocks pretty frequently  (e.g. daily) so this isn't just some odd quirk that happens only once in a blue moon.

[miln40]

Thanks for the nicely written out explanation, Stephen.

So the incentive to have fewer transactions is kind of a bummer...
Also, that means that right now when we use a full client not only do we store the main block chain, but also all these orphaned blocks? They should be deleted from the logs after some times has passed, in my opinion. No wonder Bitcoin takes 4 gigs on my harddrive!

[Stephen Gornick]

Also, that means that right now when we use a full client not only do we store the main block chain, but also all these orphaned blocks?

I don't think that is the case, perhaps they are held just in the node's memory pool.

[citboin]

So if I have a transaction on Alice's blockchain, my node will start to broadcast the transaction to miners again? It seems like a good idea for mining software to find and merge transactions in orphaned blockchains. Any reason this does not happen?

[Stephen Gornick]

So if I have a transaction on Alice's blockchain, my node will start to broadcast the transaction to miners again? It seems like a good idea for mining software to find and merge transactions in orphaned blockchains. Any reason this does not happen?

I'm not sure I'm understanding your question correctly.  

When a node running the Bitcoin.org client learns of a transaction and its inputs are unspent, it will always relay that transaction (with the exception of transactions that are too spammy, e.g., spending less than a bitcent and not paying a fee, for instance.)

So if you your node sees Alices block 101 as the longest, it will accept and relay any transaction whose inputs are not already spent.

There can be other clients that behave differently, but that's how the Bitcoin.org client handles it.

Does that answer your question?

[YSH]

Sorry to revive this topic.

But I have now today a transaction stuck in an orphaned block fore 9+ hours.

What is happening with my transaction? When will it get in a new block? Is it lost?

[kittycatbtc]

Sorry to revive this topic.

But I have now today a transaction stuck in an orphaned block fore 9+ hours.

What is happening with my transaction? When will it get in a new block? Is it lost?

I don't think transactions can get lost? that would be ridiculous 

[DannyHamilton]

Sorry to revive this topic.

But I have now today a transaction stuck in an orphaned block fore 9+ hours.

What is happening with my transaction? When will it get in a new block? Is it lost?

Transaction ID?

[Stephen Gornick]

I don't think transactions can get lost? that would be ridiculous 

Happens all the time.

Transactions that don't confirm (e.g., with six confirmations) eventually get dropped by the miners (due to the limited size of the transaction pool which is in-memory only.)  http://bitcoin.stackexchange.com/questions/9709

There is even the possibility for a confirmed transaction to get "lost".  That happened with the March 2013 hard fork where a customer deposit to OKPay had confirmed, but then that customer took advantage of the hard fork situation to create a double spend against OKPay.  Due to the situation, the miner that included the double spend (BTC Guild) had already known of the original transaction on the v0.8 side of the blockchain fork but then included the double spend of that same transaction when they switched to solving blocks on the pre-v0.8 side of the fork.      So BTC Guild "lost" the first spend transaction -- likely due to re-starting the client which, at the time, had no method of pulling the transaction memory pool from a peer or from permanent storage.   

That's a very, very rare situation.  Though it could have been a $10,000 loss to OKPay had the customer not returned the funds that were double-spent.

[ensurance982]

The transactions (in case they're valid and legal transactions) should occur in both chains when it comes to the initial transactions in the first block that's split off. A split mainly happens if two miners discover a valid new block virtually simultaneously. One of those chains has to "survive" eventually. If there are transactions on a chain that gets abandoned, they've effectively never happened...

[Lamigo]

I don't think transactions can get lost? that would be ridiculous 

Happens all the time.

Transactions that don't confirm (e.g., with six confirmations) eventually get dropped by the miners (due to the limited size of the transaction pool which is in-memory only.)  http://bitcoin.stackexchange.com/questions/9709

It is true that low priority transactions without fee will probably never be confirmed and eventually dropped by all miners.

But if the transaction is included in a block (but then the block gets orphaned), the transaction will likely be included in another block soon.