Great Consensus Cleanup

Date: April 8, 2024

Transcript By:

How bad are the bugs?

How good are the mitigations?

Improvements to mitigations in the last 5 years?

Anything else to fix?

Time warp

What is it?
- Off by one in the retargeting period
- 2015 blocks instead of 2016
Impact
- Spam (since difficulty is 1 and block times are what restricts tx)
  - UXTO set growth for the same reason
- 40 days to kill the chain
- Empowers 51% attacker
- Political games (users individually incentivized short-term to benefit from more block space, miners individually incentivized short-term to benefit of more subsidy)
- Minority miners not incentivized to try but it doesn’t cost anything
- Original mitigation is good
  - Mandating new restrictions on the timestamp of the first block of a retarget period in relation to last blocks timestamp

Fake SPV inclusion
- <visual merkle tree diagram illustrating issue>
- Years ago the attack required more work than proof of work, so was less of a concern, not so now
- Arbitrary confs, less work
- Simple mitigation
  - Require the coinbase transaction too, as all transactions on the same level of the merkle tree
Block malleability
- Separate but similar attack
- Fork nodes
- Simple mitigation
  - Dont cache context-less checks
BIP’s original Mitigation
- Forbid <=64 byte transactions
  - No need to disable <64 bytes transactions, since 64 is the issue
  - Concern about existing, unbroadcasted 64 byte transaction?
    - Would have to be insecurely small
- AJ has an implementation

Was able to come up with 3 minutes block validation time on modern laptop, 90 minutes on Rpi4B
- Quadratic hashing: 700GB
Bypass mitigations from the original proposal
How much data is too much?
- Down to 1.2GB with simple mitigations, more requires being aggressive
How bad is it?
- Attack other miners
- Stall cheap hardware
- Anything else? Block propagation?
What about transactions >100k? Confiscation concern
- Simple hack, only apply new rules after outputs created after a certain block height

Not in the original GCC proposal, but could be useful to add
BIP30 validation after block 1,983,702 turned back on
- Originally enabled around block 200k
  - BIP30 was activated earlier, BIP34 was around this height.
- Duplicate coinbase transactions
Height in nLockTime? Mandate witness commitment?
- Or use version field?
Hardcode the two historical BIP34 block violations?
- It was later pointed out this wouldn’t work. It’s unclear whether this can be done short of using a checkpoint.
Does any early block exist with an OP_RETURN output which could be interpreted as a witness commitment (ie could technically be duplicate in the future). Sjors checked and there is no OP_RETURN output in any of the coinbase transactions prior to BIP34 activation.

Wishlist: Additional items to consider for inclusion?

None discussed
Fixing the year 2106 problem, but this is a hard fork so would rather not bundle it with the other more pressing mitigations.