Skip to content

docs(commitments): record Merkle branch boundary - #66

Open
brenorb wants to merge 1 commit into
solving-bitcoin:mainfrom
brenorb:docs/merkle-branch-boundary
Open

brenorb wants to merge 1 commit into
solving-bitcoin:mainfrom
brenorb:docs/merkle-branch-boundary

Conversation

@brenorb

@brenorb brenorb commented Sep 11, 2026

Copy link
Copy Markdown
Contributor

Summary

  • document why the existing unary hash path is not a conventional binary Merkle proof
  • add a reproducible compile-only boundary for the closest 64-byte SHA-256 workaround
  • record NR-045 and OP-021 with a falsifiable path toward standard HASH256(left || right) verification

Measured boundary

  • one 64-byte SHA-256 layer: 1,060,200 script bytes
  • 770,481 static non-push opcodes
  • 129 bytes maximum serialized witness for 64 one-byte inputs
  • zero auxiliary hints

These figures exclude double hashing, branch routing, and output conversion, so they are not a complete Merkle verifier metric.

Validation

  • cargo run --locked --example merkle_branch_boundary
  • cargo test --locked --lib commitments::hash_path::tests (7 passed)
  • python3 tools/kb.py validate
  • cargo fmt --check
  • git diff --check
  • full repository test skipped as requested

Copy link
Copy Markdown
Contributor

Review recommendation: fix before merging.

The reported 129-byte witness is a fixture size, not the general maximum for 64 numeric byte inputs. Canonical ScriptNum encodings of 128..255 require two payload bytes, so the maximum serialized data witness is 1 + 64 * (1 + 2) = 193 bytes, excluding orientation, script and control block. The example uses one-byte-valued items and reproduces 129.

Label the fixture-specific value accurately or report the general maximum. Also qualify the claimed lower boundary: the size of one selected SHA256 backend does not establish a lower bound across available representations/backends. Integrate the corrected text with #14/#17 and keep their consensus/policy distinctions accurate. Evidence: the example output is locally-reproduced; the scope/serialization mismatch is inspected.

September 11 local validation (unchanged PR head): python3 tools/kb.py validate passed; the boundary example ran successfully.

Integration: rebase on current main, resolve any catalog/NR/OP ID collisions, and run the affected correctness tests and focused metric checks.

Reviewed commit: ec2ae119e3a31f76a416b42df5f2b25330316d82.

@brenorb
brenorb force-pushed the docs/merkle-branch-boundary branch from ec2ae11 to 57b9e85 Compare September 18, 2026 22:07
@brenorb

brenorb commented Sep 18, 2026

Copy link
Copy Markdown
Contributor Author

Updated in place and rebased onto current main. Corrected the 129-byte value to a one-byte fixture and added the canonical 193-byte maximum for 64 two-byte ScriptNum payloads; both are 64 data items with zero hints and exclude orientation, script, and control-block items. Qualified the 1,060,200-byte / 770,481-opcode result as an unoptimized, compile-only sha2_u32 backend profile rather than a universal lower bound or complete verifier. Kept ordinary HASH256 Merkle composition distinct from Taproot TapBranch, reused NR-057 and OP-021, and avoided the existing NR/OP ID collisions. Added an active merkle_branch_boundary_metrics_are_current check. The example, focused metric test, knowledge-base tests, full primitive_metrics (106 passed, 1 ignored), cargo fmt, and kb validation pass. Commit 57b9e85.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants