On a blockchain of nearly immediate finality

The main idea: include all conflicting transactions in a block and check competing blockchains for mutual domination to achieve near immediate transactions finality 

0. Posts on this blog are ranked in decreasing order of likeability to myself. This entry was originally posted on 03.02.2025, and the current version may have been updated several times from its original form. 

1.1 Since we’re after shaving time, you start by taking the Proof of Work out of the blockchain. You still need to hash the block’s contents with its predecessor’s hash to establish a sequence, but there are no further requirements made of the hash itself. This will become important for efficiently checking long chains soon.

1.2 Next, you allow all potentially double-spent transactions to be included in the chain without rendering the chain invalid. You still omit transactions that are invalid due to issues with signatures or whatnot, but if you have two otherwise valid transactions that rely on the same inputs (double spends) you include them both.

1.3 Next, you add metadata to the block to indicate which of the transactions included are valid, based on earliest transaction timestamped. An invalid transaction cannot be found in an earlier block than a valid one, without invalidating the chain. 

1.4 Next, you only consider blockchains to be valid if they contain no fundamentally invalid transactions (business as usual here), have marked their included transactions as valid or invalid correctly (a valid transaction must be the first timestamped to rely on their inputs, an invalid transaction must have an earlier valid transaction with the same inputs in the blockchain) and – and here’s the key – they are not dominated by any other blockchain.

1.5 Block A is dominated by block B if and only if block B includes all transactions that block A includes, plus at least one more transaction. In short, only if Block B is a more complete version of block A. If two blocks contain at least one transaction that the other lacks, neither dominates the other.

1.6 Expanding on the above, blockchain B dominates blockchain A if and only if blocks found in the same order in blockchain B either dominate those found on blockchain A, or else contain the exact same transactions.

1.7 Note how easy it would be to check if two competing chains are dominated or not by one-another. We just check the hashes of equivalent blocks at random lengths (there's no nonces, so the same blocks will have the same hash) until we pinpoint the block at which the two chains diverge. From then on, we check each couple of blocks for mutual domination, and stop as soon as we find to blocks at the same length that are non-dominated by one-another, or dominating blocks included in alternate chains at different lengths (ex. block 1014 of chain A dominated block 1014 of chain B, but block 2256 of chain B dominates block 2256 of chain A). 

1.8 Further note how trivially easy it is to dominate a blockchain A if one knows of one transaction that was not included in blockchain A, even if this transaction is a double spend of one that was: just add this transaction in any block, mark it as valid or not as the case may be, and your version of the blockchain will dominate blockchain A.

1.9 Also note how easy it is to merge two chains none of which dominates the other, say chain A and B. Use either as a start, and just include the missing transactions from the other. 

1.10 Say, we use chain A, and forge chain AA by adding the missing transactions found in chain B. Chain AA will dominate chain A but, due to the new transactions probably being placed in non-comparable blocks, it will not be able to dominate chain B as well. No matter though, as all nodes will still adopt chain AA since it would be a lot of work for a competing miner to overtake chain AA now working off chain B instead. 

1.11 When we only allow nodes to consider non-dominated chains and, at the same time, allow these to feature double-spent transactions without being invalidated, we create an incentive to always include the full history of all transactions in one’s blockchain, for fear of being rendered obsolete.

1.12 Once a transaction is broadcast, it is in every miner’s interest to include it immediately in the blockchain, working on their current non-dominated chain. If a competing transaction with an earlier timestamp comes to light afterwards (perhaps the node was not online when the original was broadcast), it will have to redo all blocks from the point at which the newly-found double-spend is placed. Or it could just adopt the competing chain where it found the original transaction, adding the double-spend correctly marked as such to create a dominating chain.

1.13 Whilst the above would suffice to create consensus on its own, there may be a lot of wasted effort and orphan chains if we just rely on domination. We must also somehow limit the creation of spurious chains that force the network to check forever, as well as account for sybil attacks. We can’t reintroduce Proof of Work, even if lightweight, as we’d be introducing however slight a finality delay. 

1.14 So, in order to avoid finality delays, we ask each miner for Proof of Burn before broadcasting a chain, with a minimum amount of one unit required. To temper reasonable fears of centralisation, we count the square root of the amount burned and instruct all nodes to adopt whichever non-dominated chain encodes the highest sum of the square roots of units burned over all blocks.

1.15 So, what would an attacker have to do to double-spend here? Take the dominating chain the moment before they spend the first, valid transaction, and omit it. Then double-spend, and include only this transaction. Then broadcast the chain, making sure to burn enough to ensure that their chain will propagate at the expense of the honest chains that may include the original transaction, hoping no other honest chain has already seen and included both their original and their double spend. 

1.16 But if they succeed so far, some nodes do have the original transaction, and are now given a golden opportunity to dominate the new chain. Just add the original in the same block as the now correctly marked double spend, redo all subsequent block as exact copies of the dishonest chain, burn the minimum amount, and dominate the dishonest chain, burning the attacker’s funds for nothing.

1.17 Double-spends may live for a bit due to propagation delays, but they will come to light as soon as these allow for. Original transactions will, on the other hand, entrench themselves the moment they are broadcast, and will never be superseded by double-spends for more than a time. 

1.18 This is the quickest finality that one may have in a blockchain design. 

1.19 I realise this relies on strong timestamps, and am not sure if the security we have today would suffice. I think one may be able to switch to a “first seen” approach, by having whichever transaction is encoded earlier found to be the valid one even if timestamps are not deemed secure enough, but it would be far less optimal. 

1.20 I also see that we would have to impose transaction fees as a matter of course, regardless of what block rewards are otherwise. I propose both a % fee and a nominal fee added together as the optimal fee.

1.21 But otherwise, seems pretty alright.