6

It seems to be random or up to the miner from what I can tell.

But to store blocks, one must keep the order of the transactions (in some position column, etc) because regenerating the block for later retrieval requires putting the transactions back in the same order. Is this correct?

Improve this question
1
  • 1
    The sequence of blocks is critical (and accommodated as each block is chained to a specific prior block), but the sequence of transactions within a single block is not.
    – Stephen Gornick
    Commented May 30, 2012 at 7:54

1 Answer 1

Reset to default
5

The first transaction has to be the miner's reward. The other transactions can't be miner rewards. Transactions have to appear after any transactions upon which they depend. Other than that the order is up to the miner. Changing the order of the transactions is one of the things a miner can do to change the block hash once he has tried all possible values of nonce.

I don't know what you're referring to with your "regenerating the block for later retrieval". As far as I know blocks aren't regenerated. They're created by a miner, passed around the network, and stored on disk. There's no need to regenerate them.

Improve this answer
6
  • 1
    Transactions can depend on other transactions. For example, when you spend change from a previous output that was not yet confirmed. In this case, both transactions can be mined into the same blocks, but the dependent one has to be last.
    – Pieter Wuille
    Commented May 30, 2012 at 9:01
  • @PieterWuille Thanks. I updated my answer accordingly.
    – Chris Moore
    Commented May 30, 2012 at 10:02
  • Thanks Chris for your answer, this is helpful. To clarify regenerating the block, I'm thinking about storing the blocks in a relational database. Instead of storing the merkle tree in the database (giant blob of text) I'm storing the order of the transactions with a position column on the transactions table. Then I can regenerate the merkle tree and wouldn't need to duplicate all the tx hashes. But I'm still debating...just keeping the merkle tree in the blocks table would negate the need to regenerate it each time and store tx position.
    – Brian Armstrong
    Commented May 30, 2012 at 18:03
  • OK, so you will need to have a column that stores the order of the transactions. When you 'regenerate' the block from your database and pass it to a peer, the peer will want to be able to hash it and make sure the hash is less than the required target, which it won't be if you have reordered the transactions.
    – Chris Moore
    Commented May 30, 2012 at 18:33
  • @BrianArmstrong: I wouldn't recommend trying to convert the block into any other format and expecting to be able to perfectly regenerate the block. Unless you're using a protocol that's specifically designed to be distinguished, there's always a risk that some unusual thing in the block will break your attempt to regenerate it. My advice would be to either store the block as is or do not attempt to regenerate it.
    – David Schwartz
    Commented May 30, 2012 at 23:13

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.