Skip to content

lwk_wasm: no way to read TxOutSecrets for a PSET output blinded by the wallet #177

Description

@bitwalt

Context

In a caller-funded PSET flow, a counterparty builds a PSET template containing one foreign input (an atomic-swap claim script) plus a payout output to our wallet. Our wallet then adds L-BTC inputs to cover fees, blinds the PSET, and signs only its own inputs. The counterparty's finalizer has to verify that the payout output really pays the expected asset and amount before it adds the claim witness — which means it needs the unblinded { asset, value, assetBlindingFactor, valueBlindingFactor } for that one output.

Problem

Once the wallet has blinded the PSET, there is no way to read those secrets back out of lwk_wasm:

  • PsetOutput exposes only scriptPubkey(), amount(), asset(), blinderIndex() (lwk_wasm/src/pset.rs). amount()/asset() are the explicit values, so they are undefined for a blinded output.
  • PsetDetails exposes balance, signatures, fingerprints and issuances, but nothing per-output (lwk_wasm/src/pset_details.rs).
  • TxOutSecrets already exists with assetBlindingFactor() and valueBlindingFactor() (lwk_wasm/src/blockdata/tx_out_secrets.rs), and WalletTxOut.unblinded() returns one — but only for an output already scanned from a confirmed transaction, which is too late here.

The blinder necessarily computes these factors and then discards them.

Proposal

Expose them at the PSET stage, either:

  • PsetOutput.unblinded(): TxOutSecrets | undefined, populated for outputs blinded by this wallet, or
  • have the blinding call return the per-output secrets alongside the blinded PSET.

Either shape would let a caller hand a counterparty proof of what a blinded output pays without leaking the wallet's master blinding key.

Versions

Checked against master 1e7332e and published lwk_wasm / lwk_node 0.18.0.

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions