Haircomb Hard Forks

Over the years, Haircomb has undergone a number of consensus changes (hard forks).

2019-11-06 Supply Fix Hard Fork

On November 1, 2019, it was reported that the subsidy was 0.00000001 less COMB than expected. The true total supply of the coin should be 12423823.39976706 COMB, while the incorrect supply of the coin at that time was 12423823.18141419. The difference amounted to 21835287 Nats, with one Nat for every individual wrong block starting from the BTC genesis. However, 26 power-of-2 blocks [1 to 16777216], including the genesis, weren't wrong even before the fork. The formula used for the calculation was: 0 = 210000000 - FLOOR((LOG(21835287 + 26) / LOG(2))^6).

The formula above calculates, that the subsidy for the last block drops to zero.

2020-01-03 Liquidity Stack Coin Loops

Before the fork, any coins that revisited the same liquidity stack entry would have been deleted by the loop detector. After the fork, the coins triggered by the stack had their visited address map cleared, allowing them to recirculate safely into the same stack, and they would proceed to the stack change address. This upgrade was dubbed Liquidity Stack Coin Loops.

2020-02-02 File Format Fork

Transactions with more than 9999 outputs or blocks with more than 9999 transactions would overflow, causing the commitments to be counted from 0 again. The fix was to add another block-internal counter with a capacity of 99999999 commitments per block. Starting with block 620000, the fork was activated, and commitment chain positions began to be compared by the new counter. This fork persists to this day in LevelDB. The current LevelDB limits are higher, however, with 65535 transactions, 65535 outputs, and 4294901759 block outputs.

There are 3 transactions on the BTC chain with more than 9999 outputs, but they occurred prior to SegWit (block 481824) and can be safely ignored. There was 1 block on the BTC chain with more than 9,999 transactions, which also occurred prior to SegWit and can be safely ignored.

2022-11-10 Security Issue

The problem was that each tooth was verified individually, comparing any UTXO tags with the initial UTXO tag of the tooth commit.

For example, in the case of Decider, the attacker would choose 4 commitments from the two Decider legs. The attacker could then commit these 4 values in various orders, some of which were not caught by the double-spend checking.

By first determining the last UTXO tag of the 21 commitments (the frontier) and then comparing the last UTXO tag with UTXO tags on all the teeth, the problem was resolved both for Haircomb (21 commitment frontier) and for Decider (2 commitment frontier).