Bitcoin Protocol Assumptions

[prestwich]

Initial list. @mhluongo anything else you can think of?

• Headers

  • double-sha2 (hash256) proof of work
  • double-sha2 (hash256) txid tree
  • 80 byte header
  • exact order:
  • 4 bytes version
  • 32 bytes prevhash
  • 32 bytes tx merkle root (use coinbase txid if only 1 tx)
  • 4 bytes timestamp
  • 4 bytes nbits
  • 4 bytes nonce

• difficulty adjustment

  • 10 minute block time
  • target changes no more than factor of 4
  • retarget ONLY when height % 2016 == 0

• Transaction Format

  • secp256k1 is allowed
  • double-sha256 txid
  • keep output is p2wpkh
  • other outputs may be anything
  • inputs are native witness
  • we probably want to change this, but I'll hate it

• SPV Work

  • 6 headers at current diff is reasonable for validating txns
  • 12 headers at previous diff is reasonable for changing diff in the diff oracle

[mhluongo]

If we assume the BTC supply asymptote, we can fit a TBTC balance with 3 additional decimals sub-satoshi into a uint64.... :grinning:

[prestwich]

but why? we don't actually get anything. a uint64 costs the same to store and basically the same to operate on as a uint256. I think we want 18 decimals for TBTC anyway

[mhluongo]

I assumed there was cool struct packing we can do.... Boo :(

Do you just want to list assumptions we're relying on, or assumptions we believe we can rely on?

[prestwich]

I assumed there was cool struct packing we can do.... Boo :(

actually maybe. bitshifts got in with constantinople, so this may be a thing now :o

Do you just want to list assumptions we're relying on, or assumptions we believe we can rely on?

I think listing assumptions we do rely on is more important, and we should try to be very aware of and closely examine any new ones

[mhluongo]

actually maybe. bitshifts got in with constantinople, so this may be a thing now :o

Looks like we'd have to replace the standard ERC-20 address to balance mapping to use hashed structs to get any benefit...

The naive attempt is more expensive https://ethfiddle.com/D45VXJ5QN-

I'll play around, code golf sounds fun

I think listing assumptions we do rely on is more important, and we should try to be very aware of and closely examine any new ones

Agreed. Part of why I ask is we could intentionally relax some assumptions (eg less strict difficulty SPV) to have fewer protocol assumptions in code, though the validation will be weaker

[prestwich]

I'll play around, code golf sounds fun

code golf is a never-ending rabbithole :)

[mhluongo]

I'll play around, code golf sounds fun

Narrator It wasn't.