separate BRK and mempool output types

[mattfaltyn]

Summary

• separate BRK-native output type names from Esplora/mempool.space names
• expose distinct p2pk33 and p2pk65 hash-prefix routes with exact payload validation
• keep TxOut.scriptpubkey_type mempool-compatible through OutputTypeNormalized
• regenerate the Rust, JavaScript, and Python clients

Native and normalized behavior

OutputType now uses BRK-native values such as p2pk33, p2pk65, p2wpkh, p2wsh, p2tr, p2ms, and opreturn. TxOut.scriptpubkey_type continues to use mempool.space values such as p2pk, v0_p2wpkh, v0_p2wsh, v1_p2tr, multisig, and op_return through the new OutputTypeNormalized.

Compatibility impact

Native BRK routes, JSON, formatting, OpenAPI, and generated clients no longer accept compatibility aliases. /p2pk33/... and /p2pk65/... query their exact stores, while the old /p2pk/... route is no longer accepted. Persisted binary state is unchanged because the native enum order and representation are preserved.

Generated clients and docs

The Rust, JavaScript, and Python clients now emit native route values and enforce exact 33-byte and 65-byte P2PK payload lengths. The affected JavaScript API documentation and native addr_type wording were updated.

Validation

• cargo test --workspace
• cargo clippy -p brk_types -p brk_query -p brk_bindgen -p brk_client --all-targets -- -D warnings
• cargo clippy -p brk_server --all-targets --features bindgen -- -D warnings
• npm run test:hash-prefix
• uv run --frozen pytest tests/test_hash_prefix.py -q
• scoped rustfmt --edition 2024 --check
• git diff --check
• bindgen rerun with no additional diff

Fixes #37

[nym21]

thanks ! didn't really expect anyone to use p2pk hashes tbh haha

[nym21]

so PR is good but I think we should just do p2pk33 and p2pk65 like everywhere else for consistency

like me know if you wanna do it

[mattfaltyn]

Yep, happy to update it. Just to confirm scope: should p2pk33/p2pk65 apply only to the hash-prefix route while mempool-compatible responses keep serializing P2PK as p2pk, or do you want the OutputType wire values changed globally too? The global change would also affect scriptpubkey_type, addr_type, OpenAPI, and the generated clients.

[nym21]

basically we should remove serde and strum from:

  #[serde(rename = "p2pk")]
  #[strum(serialize = "p2pk")]
  P2PK65,

  #[serde(rename = "p2pk")]
  #[strum(serialize = "p2pk")]
  P2PK33,

to be consistent with the rest of the codebase, I did it a bit too fast and didn't think it through fully

but we still wanna be 100% compatible with mempool.space, thus we need to fix the trout.rs serialize method, and more specifically this one:

state.serialize_field("scriptpubkey_type", &output_type)?;

should be output_type.normalized(, which probably should be its own type (OutputTypeNormalized?) thus we could remove (or actually "move") all the other serde/strum to that other enum

better and cleaner separation of what's BRK and what's esplora/mempool.space

[mattfaltyn]

Done. BRK APIs now use native output types, including p2pk33 and p2pk65, while TxOut.scriptpubkey_type stays mempool-compatible through the new normalized type. I regenerated the clients and docs and reran the checks.

[nym21]

thank you ! will merge into next after I merge next-next there