Build and sign covenant spends from JavaScript

[lukachi]

A wallet driving this SDK from JavaScript could not express several things a covenant spend needs, and one of them was silently wrong. Each change below was found while performing a deployed SimplicityHL lending protocol end to end on Liquid testnet from a browser extension: seven distinct actions, all confirmed on chain.

Issuance on both input shapes

addWalletIssuanceInput and addContractIssuanceInput are exposed to JavaScript, so a transaction that creates an asset can be assembled from the browser. Both report the asset id, entropy and reissuance token they derived, which lets the caller compare them against its own derivation instead of trusting one side.

Parameter types across the boundary

contractParameterTypes(source) answers what a contract's parameters are declared as, from the source alone and before there are any arguments to build with. SimplicityHL declares no type at a parameter site — the type checker works it out from the position the parameter is used at — so the compiler is the only thing that can say, and a caller was previously left guessing at the encoding.

A covenant is rebuilt from the parts it was committed to

Contract now takes the extra taproot leaves and the build mode alongside the source and arguments. All four decide the script a covenant locks to, so building with only the first two derives an address for a different contract — one whose spend the covenant refuses at execution, after signing.

A transaction can declare its lock height

FinalTransaction::set_locktime_height (setLocktimeHeight in wasm) writes the height onto every input that does not already carry one. A covenant branch guarded by check_lock_height reads the transaction's own locktime, and one that declares none satisfies no such branch.

The bug this fixes is in PartialInput::to_input. It wrote Some(Height(0)) into required_height_locktime whenever an input carried no lock height of its own. PSET reads a present-but-zero height as a constraint rather than as its absence, so locktime() returned zero for the whole transaction and every timelocked spend failed. A zero height is now treated as no height:

let height_locktime = match self.locktime {
    LockTime::Blocks(value) if value.to_consensus_u32() > 0 => Some(value),
    LockTime::Blocks(_) | LockTime::Seconds(_) => None,
};

A refusal that can be diagnosed

SignerError::CovenantExecution carries the transaction's locktime and the input's sequence in its message. Both decide whether a timelocked branch runs, and without them a refusal is indistinguishable from any other execution failure.

Checks

cargo check --workspace --all-targets and cargo test -p smplx-sdk pass on this branch, rebased onto dev at c9cae5d. The nineteen SDK tests include two new ones pinning a declared transaction locktime and its absence through extract_pst.

[Arvolear]

This and the next functions are super weird. What do they do? Do they have to be in the root of the file?

[Arvolear]

This has nothing to do with the contract. This is just a 32-byte randomness.

[Arvolear]

Is this IssuanceReport constructor?

[Arvolear]

Should this be in the root?