Skip to content

Fix pk_len() for BareCtx#472

Merged
apoelstra merged 1 commit intorust-bitcoin:masterfrom
afilini:fix/pk-len-bare-ctx
Oct 8, 2022
Merged

Fix pk_len() for BareCtx#472
apoelstra merged 1 commit intorust-bitcoin:masterfrom
afilini:fix/pk-len-bare-ctx

Conversation

@afilini
Copy link
Copy Markdown
Contributor

@afilini afilini commented Oct 4, 2022

The pk_len() returned should account for the extra byte for the OP_PUSH opcode. This is true for all the other contexts, but not for BareCtx, so this commit fixes it.


This PR is based on the 7.0.0 tag because in my opinion it's worth applying this and releasing as 7.0.1 without waiting for 8.0.0 (BDK would naturally benefit from this because we are about to make one new release still based on 7.0.0 and it's tricky to workaround this issue in our code).

I think the patch is small enough that it can easily be applied on older releases as well, if you want to backport it too.

The `pk_len()` returned should account for the extra byte for the
OP_PUSH opcode. This is true for all the other contexts, but not for
`BareCtx`, so this commit fixes it.
Copy link
Copy Markdown
Contributor

@evanlinjin evanlinjin left a comment

Choose a reason for hiding this comment

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

ACK f3ae0d8

66
} else {
33
34
Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: Would it make sense to have 33 + 1 instead? This way we can explicitly show OP_PUSH... and <pk>.

Copy link
Copy Markdown

@vladimirfomene vladimirfomene Oct 6, 2022

Choose a reason for hiding this comment

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

Now I'm wondering if it is not better to have the 1 byte of the OP code outside of this function for all contexts. The name of the function pk_len communicates that it is calculating the length of the serialized public key but it does more than that by adding the byte for the PUSH opcode. Or maybe mention this fact in the docs.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Yeah it's mentioned in the docs:

/// Get the len of public key when serialized based on context
/// Note that this includes the serialization prefix. Returns
/// 34/66 for Bare/Legacy based on key compressedness
/// 34 for Segwitv0, 33 for Tap

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Re: 33 + 1 I'd be ok making that change, but let's see what the maintainers think about it

@apoelstra
Copy link
Copy Markdown
Member

concept ACK this. no preference about 34 vs 33 + 1 .

Can't test locally because of the honggfuzz arbitrary thing..maybe this needs a rebase or something, but no big deal in any case, the code is visibly correct.

Copy link
Copy Markdown
Member

@sanket1729 sanket1729 left a comment

Choose a reason for hiding this comment

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

ACK f3ae0d8

Copy link
Copy Markdown
Member

@apoelstra apoelstra left a comment

Choose a reason for hiding this comment

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

ACK f3ae0d8

@apoelstra apoelstra merged commit 2d113fb into rust-bitcoin:master Oct 8, 2022
sanket1729 added a commit to sanket1729/elements-miniscript that referenced this pull request Oct 21, 2022
heap-coder added a commit to heap-coder/rust-miniscript that referenced this pull request Sep 27, 2025
f3ae0d89f47c918ededb00a5f78115cff1aa85e6 Fix `pk_len()` for `BareCtx` (Alekos Filini)

Pull request description:

  The `pk_len()` returned should account for the extra byte for the OP_PUSH opcode. This is true for all the other contexts, but not for `BareCtx`, so this commit fixes it.

  ------

  This PR is based on the `7.0.0` tag because in my opinion it's worth applying this and releasing as `7.0.1` without waiting for `8.0.0` (BDK would naturally benefit from this because we are about to make one new release still based on `7.0.0` and it's tricky to workaround this issue in our code).

  I think the patch is small enough that it can easily be applied on older releases as well, if you want to backport it too.

ACKs for top commit:
  evanlinjin:
    ACK f3ae0d89f47c918ededb00a5f78115cff1aa85e6
  sanket1729:
    ACK f3ae0d89f47c918ededb00a5f78115cff1aa85e6
  apoelstra:
    ACK f3ae0d89f47c918ededb00a5f78115cff1aa85e6

Tree-SHA512: cc01c3a14708e081592b0a01d61ab7800ff5175047ef0b7315f56c898d84119270e5f680bb0de1d0997b4108be02af7d5896bab7c8cef8f053c99c979db9bf8b
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.

5 participants