Skip to content

Implement binary encoding for raw::Key using bitcoin-consensus-encoding crate#57

Draft
nymius wants to merge 11 commits intorust-bitcoin:masterfrom
nymius:feat/impl-binary-encoding-for-psbt
Draft

Implement binary encoding for raw::Key using bitcoin-consensus-encoding crate#57
nymius wants to merge 11 commits intorust-bitcoin:masterfrom
nymius:feat/impl-binary-encoding-for-psbt

Conversation

@nymius
Copy link
Collaborator

@nymius nymius commented Feb 6, 2026

Description

This is a proof of concept of how to implement raw::Key binary encoding using bitcoin-consensus-encoding.

This is what I understood was the idea behind #48, and this is the reason why I opened rust-bitcoin/rust-bitcoin#5611.

I applied @mpbagot suggestion (thanks!). I couldn't figure out another way to do it without the extra allocation.
I think that something like BytesVecDecoder::without_length_prefix(length: usize) would avoid the allocation and consume directly from the same byte slice. But I don't know if this is undesired from an API perspective.

Notes to the reviewers

I've imported bitcoin-encoding-consensus from the git path because CompactSizeEncoder::encoded_size is not available in the published 1.0.0-rc.3 release from crates.io.

@nymius nymius force-pushed the feat/impl-binary-encoding-for-psbt branch from 2435cbd to 2f65ba1 Compare February 6, 2026 20:29
@nymius nymius force-pushed the feat/impl-binary-encoding-for-psbt branch from 2f65ba1 to 78c5aa2 Compare February 6, 2026 20:43
@tcharding
Copy link
Member

I've imported bitcoin-encoding-consensus from the git path because CompactSizeEncoder::encoded_size is not available in the published 1.0.0-rc.3 release from crates.io.

We should be able to use internals to do this calculation: https://docs.rs/bitcoin-internals/latest/bitcoin_internals/compact_size/fn.encoded_size.html

#[cfg_attr(feature = "serde", derive(Serialize, Deserialize))]
pub struct Key {
/// The `keytype` of this PSBT map key (`keytype`).
pub type_value: u8,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On master branch of bitcoin this is a u64 now.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@tcharding
Copy link
Member

Good work man, the logic looks correct to me. I am a bit of a brain dead reviewer; even knowing the high level design of this code it took me a while to work out what was going on. We can probably iterate on a bunch of the identifiers and also we could help readers with some code comments about how the decoder works in two passes because that is the surprising bit.

Props for the idea @mpbagot, its was a decent creative leap.

@nyonson
Copy link
Collaborator

nyonson commented Feb 10, 2026

I've imported bitcoin-encoding-consensus from the git path because CompactSizeEncoder::encoded_size is not available in the published 1.0.0-rc.3 release from crates.io.

We should be able to use internals to do this calculation: https://docs.rs/bitcoin-internals/latest/bitcoin_internals/compact_size/fn.encoded_size.html

I dropped the internals dep in #47, and I think my reasoning still applies. Unless you think this is just a temp dep until we release consensus_encoding?

@tcharding
Copy link
Member

I don't mind having a dep on internals but I also didn't mind you removing it because less deps is better. But if we need it we need it. I'm not too fussed either way. rust-bitcoin/rust-bitcoin#5487 shouldn't be too far away anyways.

@nymius
Copy link
Collaborator Author

nymius commented Feb 11, 2026

The method I'm using here is already merged, so I can hold this until we have the method in the release, or next release candidate.

State::KeyType(type_and_data, decoder) => {
let key_type = decoder.end().map_err(|e| E(Inner::Type(e)))?;

let is_valid = matches!(key_type, 0x00..=0x18 | 0xFB | 0xFC);
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

3 participants