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
{{ message }}
Repository navigation
Bug in pruning [sendrawtransaction RPC error -26 (Trailing bytes after final byte of witness)] #391
We've run into an issue pruning our contracts after upgrading simplicityhl to version 0.8.0.
Given that simplicity-lang was updated previously and this issue existed, we can provide contract examples related to this comment: BlockstreamResearch/SimplicityHL#391 (comment).
Errors
Simplex returns this kind of error after sending a formed transaction to a node:
Error: Broadcast failed with HTTP 400 for http://127.0.0.1:52982/tx: sendrawtransaction RPC error -26: non-mandatory-script-verify-flag (Trailing bytes after final byte of witness)
SimplicityHL tests are failing with this error regarding the precision of the first encoded bytes.
bitstream had trailing bytes 0x04...
What happened?
We encountered this error in the simplicityhl-std repo across all our testing contracts. On the previous version of simplicity-lang(0.8.0), everything was fine.
Now I'm trying to migrate them to the latest version, but the migration is failing.
Why am I reporting this issue here?
After locally reverting the changes from this PR #379, everything works.
I'm sure that something went wrong in pruning after this commit: 4c7be1b.
Pruning doesn't prune redundant branches, and later decoding fails.
You can see this in our contracts because we have lots of redundant branches (we use them, but in certain places).
If we use values more carefully, we can have no inactive branches. All will be fine, as in this test single_none_without_inactive_branch_roundtrips.
Steps to Reproduce
I've created a minimal reproducible repository with replicated examples using both simplex and raw simplicityhl here: https://github.com/ikripaka/example.
Simplex tests (To install simplex, use this guide: https://github.com/blockstreamResearch/smplx#installation.): simplex test minimal_pruning_none_happy_path__smplx_test assert_original_none_256_happy_path__smplx_test assert_none_256_happy_path__smplx_test --no-fail-fast
There you can find different contract configurations:
asssert_original.simf, assert_original_lib.simf, assert_original_dispatch.simf - represent simplified version of real testing case;
If you are going to use a LLM to generate these massive textwalls, why not use the LLM to reproduce the bug using the library that you're filing against? rust-simplicity does not have anything to do with RPC or HTTP or simf files.
Busy adding more regression tests here BlockstreamResearch/SimplicityHL#445. Will then fix rust-simplicity. It appears #379 fixed one bug but introduced another
Activity
apoelstra commentedon Oct 16, 2026
If you are going to use a LLM to generate these massive textwalls, why not use the LLM to reproduce the bug using the library that you're filing against? rust-simplicity does not have anything to do with RPC or HTTP or simf files.
ikripaka commentedon Oct 16, 2026
Yeah, I've already reproduced it with raw
simplicity-langpruning, without any HTTP or RPC calls.You can find it here: https://github.com/ikripaka/example/blob/c66093907cbf3a1e9e14c938109e85666a07d23e/tests/pruning_encoding_test.rs#L169.
stringhandler commentedon Oct 16, 2026
Busy adding more regression tests here BlockstreamResearch/SimplicityHL#445. Will then fix rust-simplicity. It appears #379 fixed one bug but introduced another
apoelstra commentedon Oct 16, 2026
cc #339