9

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?

Improve this question

1 Answer 1

Reset to default
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.

Improve this answer
5
  • 1
    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
    Commented Oct 25, 2011 at 7:36
  • 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
    Commented Oct 25, 2011 at 7:43
  • 3
    Transactions 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
    Commented Oct 25, 2011 at 8:30
  • 2
    It 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
    Commented Oct 25, 2011 at 20:53
  • 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
    Commented Oct 26, 2011 at 1:42

Your Answer

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

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