6
3
For example, one bitcoin from address A to address B, then from address B to address C,
Assuming that prior to the transfer from address A to address B, no bitcoin had been sent to address B.
If the above is broadcast in the same block, would address C receive the bitcoin?
7
Yes, this is possible. This is seen happening today in MtGox's green address implementation. The two transactions are not guaranteed to be included in the same block, because the second transaction has a lower priority for miners to include it; but it's possible, and seems to happen in a lot of cases.
Quoting from MagicalTux:
Actually if you look at : http://blockexplorer.com/address/1LNWw6yCxkUmkhArb2Nf2MPw6vG7u5WG7q
Look at transactions 597d00408b... and 557c87f205....
597d00408b... is "A to B"
557c87f205... is "B to C"Both happened in the same block, which is the expected behaviour.
Previous tests did not always end in the same block, so I believe some miners may consider the second transaction lower priority as it involves not yet confirmed coins. In the case of those two transactions it was as fast as a normal transaction, but it cannot be guaranteed in 100% of the cases.
If we look at the previous transactions we can see it was sometimes coming out with a difference of 1 block, or even more. If pools could put priority on green addresses it'd (mostly) solve this issue.
You can also pay a higher fee on the second transaction in order to compensate for the lower priority.
Interesting fact: transactions listed earlier in a block's transaction list are considered to exist chronologically earlier than later transactions in the same list, so transactions like these will always be in the expected ordering. – theymos – 2011-10-25T07:36:45.057
1@theymos That is interesting, though how do the miners know in which order to include transactions in the block? So for this example, the two transactions are broadcasted at (or about) the same time. Some miners may receive the second transaction first. Wouldn't the same Byzantine Generals' Problem be present that the block chain tries to solve in the first place? – dvide – 2011-10-25T07:43:41.443
3Transactions are put at the bottom of the block as soon as the miner decides that they're valid. If two unrelated transactions are received at the same time, then the ordering doesn't really matter. If dependent transactions are received out of order, then the dependent one will initially be an orphan (invalid) until its parent is received and included in the block. Then the orphan will become valid and will be put in immediately after its parent. (Parent-child transaction ordering is required by the network -- the other ordering is not.) – theymos – 2011-10-25T08:30:18.683
2It should be pointed out that the standard client will never generate such transactions -- it will never spend coins that don't have at least one confirmation. This safety exists for a variety of reasons (that don't apply to the Mt. Gox implementation). One of them is to avoid accidentally spending coins that are subsequently revoked by a block reorganization. – David Schwartz – 2011-10-25T20:53:43.693
1@DavidSchwartz Bitcoin will spend 0-conf coins if you were the sender of the coins (from change or sends-to-self). It prefers to not do this, though. – theymos – 2011-10-26T01:42:12.050