8

Every block in the block chain contains a list of transactions. This list has a certain order which is basically set by the miner introducing the block. The merkle root in the block header requires that this order is fixed.

Therefore there is a fixed order for all transactions in the blockchain which cannot be modified at a later time (except for the usual temporary forking).

Is that correct?

Improve this question

1 Answer 1

Reset to default
3

Yes, you are correct. There is a fixed order, as ensured by the merkle root and the proof of work. Both the blocks and the transactions within each block are strictly ordered.

This order is actually necessary for validation of the transactions within. For example, you could have a transaction Y that depends on the output of transaction X in the same block. If Y came before X in the list of transactions in the block, then the block would be an invalid block.

With that said, although the order of transactions within a particular chain snapshot cannot change, the chain itself can change from time time. This happens when there is a fork in the network. Look at this image below:

enter image description here

Let's say you knew about block A and you thought it was the tip of the best chain. Then all of the sudden the other chain comes out, and block A is replaced by block B. The order of transactions in A might not be the same as the order in B.

It may also interest you to know that to enable Gavin's O(1) block propagation proposal, there is a canonical ordering for transactions in a block.

Improve this answer
2
  • 1
    "If Y came before X in the list of txns in the block, then the block would be an invalid block", how can the user ensure that the miner will place X first and then Y if both were issued very close in time? Both X and Y will be in the unconfirmed pool at the same time, and the miner will order them arbitrarily, right? If the miner sees that the Y->X order is invalid, will it try to order them as X->Y? And what if it was both Y1 and Y2 that depended on X, but the user only wanted Y1 to go through and Y2 to be invalid (insufficient funds), how can user ensure that miner won't put Y2 before Y1?
    – Joe MB
    Commented Jun 14, 2018 at 12:55
  • 1
    Miner software is smart enough to detect dependencies in transactions and order them appropriately. If two transactions try to use the same output from a transaction, then the miner software will only use one of the two transactions, but how they choose is not enforced. They could choose by first-seen, or they could choose by highest-fee, or any other criteria they want. Same thing applies even when the output that both transactions are trying to spend is in a previous block.
    – morsecoder
    Commented Jun 14, 2018 at 14:23

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.