Skip to content

WitnessVersion type#562

Closed
dr-orlovsky wants to merge 2 commits intorust-bitcoin:masterfrom
BP-WG:feat/witness-version
Closed

WitnessVersion type#562
dr-orlovsky wants to merge 2 commits intorust-bitcoin:masterfrom
BP-WG:feat/witness-version

Conversation

@dr-orlovsky
Copy link
Copy Markdown
Collaborator

Part of Taproot epic (should be listed in #503)

@dr-orlovsky dr-orlovsky added the API break This PR requires a version bump for the next release label Jan 30, 2021
@dr-orlovsky dr-orlovsky mentioned this pull request Jan 30, 2021
Copy link
Copy Markdown
Contributor

@sgeisler sgeisler left a comment

Choose a reason for hiding this comment

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

Looks good and improves the API quite a bit imo. I left a few nits regarding some expects and comments.

impl From<WitnessVersion> for ::bech32::u5 {
/// Converts `WitnessVersion` instance into corresponding Bech32 u5-value
fn from(ver: WitnessVersion) -> Self {
::bech32::u5::try_from_u8(ver.into_version_no()).expect("WitnessVersion is broken")
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.

Maybe this error text could be more descriptive, e.g. "WitnessVersion is always in 0..=16"

pub fn from_script(script: &script::Script) -> Option<Payload> {
Some(if script.is_p2pkh() {
Payload::PubkeyHash(PubkeyHash::from_slice(&script.as_bytes()[3..23]).unwrap())
Payload::PubkeyHash(PubkeyHash::from_slice(&script.as_bytes()[3..23]).expect("hash engine broken"))
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.

The failure has nothing to do with the hash engine but with supplying a byte slice of a wrong length.

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

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

Removed expect at all by using infallible from_inner

}


impl FromStr for WitnessVersion {
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.

Is this actually useful? Where do we directly (de)serialize a witness version? Isn't it always part of some other data structure with its own encoding?

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

I could imagine it being useful somewhere, and it's not much extra code.

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.

Yeah, it's not too bad now that I noticed even without it the UnparsableWitnessVersion error variant can't be made more expressive.

Payload::ScriptHash(ScriptHash::from_slice(&script.as_bytes()[2..22]).expect("hash engine broken"))
} else if script.is_witness_program() {
// We can unwrap the u5 check and assume script length
// We can unwrap assume script length
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.

I think the and has to stay in the comment for it to make any sense.

@dr-orlovsky
Copy link
Copy Markdown
Collaborator Author

Fixed @sgeisler suggestions & force-pushed. Ready for re-review

@dr-orlovsky dr-orlovsky requested a review from sgeisler March 14, 2021 12:18
@sgeisler
Copy link
Copy Markdown
Contributor

Does this really still have to be its own PR? Afaik it's included in #563 (idk if based on an up to date version) and fits in there quite well. It's a breaking change anyway.

@sanket1729
Copy link
Copy Markdown
Member

I have left some feedback on #563 for this commit.

@dr-orlovsky
Copy link
Copy Markdown
Collaborator Author

Updated with review suggestions from #563

@sgeisler
Copy link
Copy Markdown
Contributor

sgeisler commented Apr 8, 2021

Again, would anyone be opposed to closing this in favor of merging it with #563? It's just so related and reviewing #563 together with the #562 changes seemed easy enough. #563 is also close to merge ready imo, maybe a third review would be nice and we need to decide if we want to release 0.26.1 before that, but there's nothing fundamentally blocking just merging #563 all at once after that.

@dr-orlovsky
Copy link
Copy Markdown
Collaborator Author

Agree, closing this now

@dr-orlovsky
Copy link
Copy Markdown
Collaborator Author

Reopened as #617

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

Labels

API break This PR requires a version bump for the next release

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants