Return TapSighashType parse error in PsbtSighashType FromStr
What the developer wrote
Authored by Mitchell Bagot
Return TapSighashType parse error in PsbtSighashType FromStr
The FromStr trait for PsbtSighashType uses the TapSighashType FromStr
to parse from a string. On failure, this generates the same
SighashTypeParseError that is currently returned. Rather than manually
constructing the error, we can just return the error result from
attempting to parse s as a TapSighashType.
Return the error result of the TapSighashType FromStr impl rather than
manually constructing a new error in PsbtSighashType FromStr impl.
What changed, and why it matters
This is a small code-quality change in how a Bitcoin-related Rust library reports parsing errors for a special sighash type. It makes the error message come directly from the underlying Taproot parser instead of being manually rebuilt. There is no direct security vulnerability here, but it slightly improves error-message accuracy and removes a tiny bit of duplicated logic.
No urgent action required. Treat as routine maintenance. If reviewing, verify that downstream consumers do not depend on the exact content of SighashTypeParseError::unrecognized for the previously manually constructed error string.
Security signals we found
Error-handling refactor with minor externally visible behavior change
No cryptographic, memory-safety, or input-validation weakness introduced
No privilege escalation, remote execution, or consensus-critical change evident
Evidence from the diff
The commit refactors PsbtSighashType::from_str in rust-bitcoin so that, when parsing a string as a TapSighashType fails, the original SighashTypeParseError from TapSighashType::from_str is propagated instead of constructing a fresh SighashTypeParseError with the full input string. The functional change is that the returned error now carries the unconsumed remainder from the inner parser rather than the whole original string. This is a behavior-shaping cleanup, not a memory-safety or cryptographic bug fix.
Changed components
bitcoin/src/psbt/map/input.rsPsbtSighashType FromStr implementationInspect captured patch +7 / −5
diff --git a/bitcoin/src/psbt/map/input.rs b/bitcoin/src/psbt/map/input.rs
index 4e2fbe30..a77f7d7c 100644
--- a/bitcoin/src/psbt/map/input.rs
+++ b/bitcoin/src/psbt/map/input.rs
@@ -10,7 +10,7 @@ use hashes::{hash160, ripemd160, sha256, sha256d};
use crate::bip32::KeySource;
use crate::crypto::key::{LegacyPublicKey, XOnlyPublicKey};
use crate::crypto::{ecdsa, taproot};
-use crate::prelude::{btree_map, BTreeMap, Borrow, Box, ToOwned, Vec};
+use crate::prelude::{btree_map, BTreeMap, Borrow, Box, Vec};
use crate::psbt::map::Map;
use crate::psbt::serialize::Deserialize;
use crate::psbt::{error, raw, Error};
@@ -165,16 +165,18 @@ impl FromStr for PsbtSighashType {
// NB: some of Taproot sighash types are non-standard for pre-Taproot
// inputs. We also do not support SIGHASH_RESERVED in verbatim form
// ("0xFF" string should be used instead).
- if let Ok(ty) = s.parse::<TapSighashType>() {
- return Ok(ty.into());
- }
+ let parse_res = match s.parse::<TapSighashType>() {
+ Ok(ty) => return Ok(ty.into()),
+ Err(e) => e,
+ };
// We accept non-standard sighash values.
if let Ok(inner) = u32::from_str_radix(s.trim_start_matches("0x"), 16) {
return Ok(Self { inner });
}
- Err(SighashTypeParseError { unrecognized: s.to_owned() })
+ // TapSighashType returns the SighashTypeParseError with unconsumed as the `s` string
+ Err(parse_res)
}
}
impl From<EcdsaSighashType> for PsbtSighashType {
Why this scored 19/100
Community notes
Notes can correct, qualify, or add evidence to the AI analysis. Every note shown here has been validated by a human moderator.
The AI analysis stands alone for now. Submit a note if you can add evidence or important context.