None of the quotes you referenced from the paper specify a specific ordering within a block, none.
The paper's parts on the timestamp server match my earlier post that a block is the timestamp server's unit of record and all transactions in a block share the same timestamp.
The base unit in Bitcoin's security model is a block, all transactions in the block have the same number of confirmations, share the same level of security, and share the same timestamp.
Your confusion comes from this quote.
Assume the following sequence of transactions, A -> B -> C, where B spends A's outputs and C spends B's output.
Consider a block with the transactions in the following order: Header, transaction B, transaction C, transaction A. Now ask what timestamp these transactions have, the answer is they all have the same timestamp, meaning they happened simultaneously. Now ask if they are valid, the answer is yes because they all spend valid outputs, the outputs spent by transactions B and C are created in this block, but they share the same timestamp and thus are not out of order. A client has to search the block and verify this, but after doing so can confirm they are valid.
Note this is the exact same validation logic that happens with TTOR where transactions come in A then B then C order. Just as in the example above, the outputs spent by B and C are created in the same block which is valid because they share the same timestamp. The validation logic is the same, it's just easier for the client to search to validate.
So again, show me where in the paper an intra-block ordering is specified, because I've read that paper several times over the past several years and reviewed the code, and nothing specifies an ordering, even the quotes you gave.
BTW, one thing I am playing with now is how a BSV storage server would operate to serve up OP_RETURN data, I can assure you none of the approaches would use TTOR if they were to be cost effective...
Edit: Welcome to the thread, I always appreciate it when people take time to explain their thinking, even if I think it's misplaced.
The paper's parts on the timestamp server match my earlier post that a block is the timestamp server's unit of record and all transactions in a block share the same timestamp.
The base unit in Bitcoin's security model is a block, all transactions in the block have the same number of confirmations, share the same level of security, and share the same timestamp.
Your confusion comes from this quote.
You assume 5) defines an intra-block transaction ordering, it does not. You also state "where the inputs do not exist yet". This is a fundamental misunderstanding, the inputs do exist, they exist in the same block with the same timestamp.The steps to run the network are as follows:
1) New transactions are broadcast to all nodes.
2) Each node collects new transactions into a block.
3) Each node works on finding a difficult proof-of-work for its block.
4) When a node finds a proof-of-work, it broadcasts the block to all nodes.
5) Nodes accept the block only if all transactions in it are valid and not already spent.
6) Nodes express their acceptance of the block by working on creating the next block in the chain, using the hash of the accepted block as the previous hash.
Read step 5) again:
5) Nodes accept the block only if all transactions in it are valid and not already spent.
Let me ask you: Can you spend a transaction (ie: is it "valid") where the inputs do not exist yet? Remember, we cannot appeal to "outside" or "true time" because any other timestamps are faulty and not backed by PoW.
Assume the following sequence of transactions, A -> B -> C, where B spends A's outputs and C spends B's output.
Consider a block with the transactions in the following order: Header, transaction B, transaction C, transaction A. Now ask what timestamp these transactions have, the answer is they all have the same timestamp, meaning they happened simultaneously. Now ask if they are valid, the answer is yes because they all spend valid outputs, the outputs spent by transactions B and C are created in this block, but they share the same timestamp and thus are not out of order. A client has to search the block and verify this, but after doing so can confirm they are valid.
Note this is the exact same validation logic that happens with TTOR where transactions come in A then B then C order. Just as in the example above, the outputs spent by B and C are created in the same block which is valid because they share the same timestamp. The validation logic is the same, it's just easier for the client to search to validate.
So again, show me where in the paper an intra-block ordering is specified, because I've read that paper several times over the past several years and reviewed the code, and nothing specifies an ordering, even the quotes you gave.
BTW, one thing I am playing with now is how a BSV storage server would operate to serve up OP_RETURN data, I can assure you none of the approaches would use TTOR if they were to be cost effective...
Edit: Welcome to the thread, I always appreciate it when people take time to explain their thinking, even if I think it's misplaced.
Last edited: