Summary
tinyminiscript accepts bare miniscript expressions, but rejects a bare miniscript when multi(...) appears nested inside a larger expression.
Minimal repro
or_i(multi(1,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798),1)
Observed behavior
The parser rejects with:
DescriptorVisitorError(
InvalidFragmentForDescriptor { position: 6, expected: wsh, found: bare }
)
Control case
This top-level bare miniscript is accepted by the same parser:
multi(1,0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798)
Cross-check
The nested form above is parse-accepted by:
rust-miniscriptbitcoin/bitcoinembitbitcoinerlab/miniscriptNBitcoinelements-miniscript
Some of those later reject it as not sane at typecheck time, but they all agree it is syntactically valid bare miniscript.
Why this looks like a real bug
- current upstream source exposes bare miniscript parsing
- the top-level bare
multi(...) control is accepted
- the reject only appears when
multi(...) is nested inside a larger bare expression
- the failure comes from descriptor validation leaking into the bare parser surface
Summary
tinyminiscriptaccepts bare miniscript expressions, but rejects a bare miniscript whenmulti(...)appears nested inside a larger expression.Minimal repro
Observed behavior
The parser rejects with:
Control case
This top-level bare miniscript is accepted by the same parser:
Cross-check
The nested form above is parse-accepted by:
rust-miniscriptbitcoin/bitcoinembitbitcoinerlab/miniscriptNBitcoinelements-miniscriptSome of those later reject it as not sane at typecheck time, but they all agree it is syntactically valid bare miniscript.
Why this looks like a real bug
multi(...)control is acceptedmulti(...)is nested inside a larger bare expression