5
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?
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.
1Transactions 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 – 2012-05-30T09:01:49.590
@PieterWuille Thanks. I updated my answer accordingly. – Chris Moore – 2012-05-30T10:02:22.660
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 – 2012-05-30T18:03:26.727
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 – 2012-05-30T18:33:46.407
@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 – 2012-05-30T23:13:02.680
How does one specify those dependencies between transactions? How does a miner know about dependencies? – Mitar – 2016-03-28T22:57:09.117
1The 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 – 2012-05-30T07:54:49.157