rust-bitcoin / rust-bitcoin/rust-miniscript

Better error messages on satisfiers

Open
#721 1 comment 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Rust
Stars
426
Forks
200
Avg merge
7d 17h
Merged PRs (30d)
8

Description

I've been learning rust-miniscript, and when attempting to try out timelocks, I kept hitting a CouldNotSatisfy when finalizing my psbt. The reason turned out to be totally of my own doing - I had inadvertantly used a Sequence::MAX instead of a Sequence::ZERO when constructing my spend transaction. I had effectively disabled locktime usage, because I had done this:

 let txin = TxIn {
        previous_output,
        ..Default::default()
    }; 

instead of this:

 let txin = TxIn {
        previous_output,
        sequence: Sequence::ZERO,
        ..Default::default()
    }; 

I was so preoccupied trying to figure out how signing worked, how to use the plan module etc that I didn't notice this.

In order to figure out the problem, I ran my own local forks of bdk_wallet, rust-miniscript, and bitcoin crates, instrumenting them with printlns until I figure out what the (dumb, self-inflicted) problem was.

It would be supersonic if satisfier errors gave a more specific reason for failure - I wonder if it would be possible for instance to turn CouldNotSatisfy into something like CouldNotSatisfy("here is the reason")? Or perhaps something more typed like (in the case I just dealt with) CouldNotSatisfy(LockTimeDisabled)?

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing the satisfier errors around CouldNotSatisfy, especially when finalizing a PSBT and using the plan module. Reproduce the timelock case with Sequence::MAX versus Sequence::ZERO, then determine how failure reasons should be represented. Done means callers receive a more specific, actionable explanation for satisfier failures.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
blockchain, cryptography
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.