Topic: Orphaned block? (Read 971 times)

Here is the transaction:
https://blockchain.info/tx/ae082e9d47be8b8cfaee90a1a50fd64d22e6c37d063302b1b4cc50c9da084ec5

Strange, I hadn't thought to check other transactions in the block. I also noticed the unconfirmed inputs had already been spent and confirmed with 93 confirmations. Kind of confused.

I can't tell for certain unless you tell us which transactionID is your transaction, but I spot checked a few dozen transactions from that block and they all have over 100 confirmations already.

Hey all, still a bit of a newbie with the technical stuff. I made a bitcoin payment last night, about 12 hours ago, and to my surprise when I opened my wallet this morning, the tx showed as unconfirmed, even though I sent a miner's fee (default through blockchain.info). Anyway, when I look at the tx, it was relayed in this block -- https://blockchain.info/block-index/448701 -- which was orphaned.

Does this mean this tx will eventually fail and the original inputs spendable again?

BAM: https://blockchain.info/charts/n-orphaned-blocks

I suspect you are right.

I wonder how often blocks are orphaned, can anyone point to any data? They must be rare enough that Bitpay can justify doing zero-confirmation invoicing.

This block was timestamped 13 hours ago, and there have been 88 blocks found since. I suspect it won't be confirmed....

don't worry, just wait for another block 

Hey all, still a bit of a newbie with the technical stuff. I made a bitcoin payment last night, about 12 hours ago, and to my surprise when I opened my wallet this morning, the tx showed as unconfirmed, even though I sent a miner's fee (default through blockchain.info). Anyway, when I look at the tx, it was relayed in this block -- https://blockchain.info/block-index/448701 -- which was orphaned.

Does this mean this tx will eventually fail and the original inputs spendable again?

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.