Bitcoin Headerchain verification

[prajwolrg]

Description

Implements code for block header verification.

The chain of block headers provides everything a light client needs to validate the proof of work and the correct arrangement of blocks in the chain. When receiving a block header the light client checks it against Bitcoin's consensus rules:

1. The block hash has to be below the current target - a number that represents a hash with a certain amount of leading zeros. Closely related to the block's difficulty.
2. The encoded previous block hash of the current block is indeed the previous block's hash.
3. The block's timestamp is not below the median of the preceding eleven blocks' timestamps and not above the network time plus two hours.
   4.The correct target is encoded in the block. In case a retarget happened the new target was correctly derived from the epoch timestamps.

While rules 1 and 2 directly enforce the correct formation and mining of the chain, rules 3 and 4 are required so that no one can adjust the target to their own will. Otherwise, they were able to mine new blocks at a faster rate than honest nodes by increasing the target (which can be done by decreasing the epoch's timestamp delta) or they could decrease the target to make it artificially harder to mine blocks.

Copied from: https://geometry.xyz/notebook/A-light-introduction-to-ZeroSync

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature/Enhancement (non-breaking change which adds functionality or enhances an existing one)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Documentation update
• Refactor

Checklist

• I have performed a self-review of my code.
• I have commented my code where necessary.
• I have updated the documentation if needed.
• My changes do not introduce new warnings.
• I have added tests that prove my changes are effective or that my feature works.
• New and existing tests pass with my changes.

Related Issues

[codecov]

Codecov Report

Attention: Patch coverage is 97.24138% with 4 lines in your changes missing coverage. Please review.

Project coverage is 59.10%. Comparing base (6f75f6f) to head (88bc45a).
Report is 27 commits behind head on master.

Files with missing lines	Patch %	Lines
crates/prover/btc-headerchain/src/lib.rs	98.11%	2 Missing ⚠️
crates/test-utils/src/bitcoin.rs	94.11%	2 Missing ⚠️

@@            Coverage Diff             @@
##           master     #259      +/-   ##
==========================================
+ Coverage   58.47%   59.10%   +0.63%     
==========================================
  Files         123      124       +1     
  Lines       13618    13546      -72     
==========================================
+ Hits         7963     8007      +44     
+ Misses       5655     5539     -116     

Files with missing lines	Coverage Δ
crates/prover/bitcoin-blockspace/src/block.rs	92.15% <100.00%> (ø)
crates/prover/btc-headerchain/src/lib.rs	98.11% <98.11%> (ø)
crates/test-utils/src/bitcoin.rs	96.72% <94.11%> (-3.28%)	⬇️

... and 21 files with indirect coverage changes

[delbonis]

A bit scared by seemingly reimplementing Bitcoin validation logic here, would like it if we looked into being able to reuse the logic from the bitcoin-pow crate or another one. There was another crate that I saw that had no-std versions of all of these, but I don't remember the name now.

Also the inconsistency between the names of the bitcoin-blockspace and btc-headerchain crate names is a bit weird, was there a logic to this?

[delbonis]

These should all be configurable for whichever Bitcoin chain we're using, perhaps again with env!.

[delbonis]

🚩

Do the other Rust Bitcoin crates used f64? We so want to avoid using floats if possible, this isn't natively supported in the riscv arch that r0 or sp1 supports so this would be a huge prover cost to use if it's being emulated by the codegen. Plus floats are screwy in general.

It looks like this isn't being used, what's it for?

[prajwolrg]

total_accumulated_pow is used as:

L148: self.total_accumulated_pow += header.difficulty_float();

This will later used in the Challenge-Response game to determine the right fork of the bitcoin. The chain with highest accumulated PoW is considered valid.

f64 was used because rust-bitcoin already had a function internally to convert difficulty to f64 and this seems to be how the difficulty was displayed in the UI.

[delbonis]

Maybe add a prefix to this like the other one so it's clear what it's for. Was this extracted with a tool? If it's something bespoke then add it to a new contrib directory.

[prajwolrg]

Sure I'll attach the prefix! I wrote a simple binary to fetch the block headers.

[prajwolrg]

I looked into rust-bitcoin, which seems to have the logic but is was not yet released. I didn't look into other crates for this. Will checkout bitcoin-pow.

Edit: bitcoin-pow impl requires BlockIndex which has a lot of redundant fields.

Thanks for pointing the inconsistency out.

[prajwolrg]

I will try to resolve all the comments here in PR #268