You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This rule is weird and wrong in a number of ways. It was introduced in
PR rust-bitcoin#97c93bdef which was the massive PR
that introduced the Ctx parameter. This particular rule wasn't commented
on, but we can infer some things:
* From the docs on the error and my vague memory, the problem was that
we couldn't estimate satisfaction for a pubkeyhash fragment because we
didn't know if the key was 33 or 65 bytes ahead of time.
* Therefore, the code bans this in a legacy context, but not in bare
contexts (in bare contexts there is a comment saying that bare
fragments "can't contain miniscript because of standardness rules" so
maybe we thought about this ... but that comment has never been true,
so we thought wrong..). We should've banned the fragment in bare
contexts as well.
* Also, while the error is called MalleablePkH, none of this has
anything to do with malleability!
Later, in rust-bitcoin#431, we introduced the RawPkH fragment and put a pubkey into
the PkH fragment. At that point, for PkH we always knew the pubkey and
could just directly compute its size using the `is_uncompressed`
accessor. The RawPkH fragment was a second-class citizen which didn't
even have a string serialization. At this point we should have dropped
the MalleablePkH rule.
Still later, in rust-bitcoin#461, we introduced `ExtParams` and the ability to parse
"insane" scripts in a more flexible way, including enabling the
experimental `expr_raw_raw_pkh` fragment. We then gained an error
`Analyzable::ContainsRawPkh` which conceptually overlaps with
`ScriptContextError::MalleablePkH` but which isn't tied to any context,
just whether the user has enabled this second-class feature.
0 commit comments