RFC: a `WitnessTx` abstraction to unblock RGB on Liquid (207-line non-breaking patch, working PoC)

[bitwalt]

The ask

RGB consensus already names Liquid: Layer1::Liquid, ChainNet::LiquidMainnet/LiquidTestnet, and the chain_net field on Genesis. The crypto layer (mpc, dbc::tapret, dbc::opret) is already chain-agnostic — a P2TR scriptPubKey is byte-identical on Bitcoin and Elements.

The one thing that still blocks RGB-on-Liquid is that the witness-verification path is typed against bitcoin::Transaction, which cannot deserialize an Elements transaction. We propose abstracting that one type behind a small WitnessTx trait. The patch is written and validated; we'd like maintainer input on its shape before opening a PR.

Full RFC: https://github.com/kaleidoswap/rgb-on-liquid-spike/blob/main/RFC.md

The gap

The Bitcoin-tx coupling in the verification path is exactly three spots — dbc/proof.rs (Proof::verify), dbc/anchor.rs (Anchor::verify), and seals/txout/witness.rs (Witness<D>.tx). Everything those paths need from the transaction is small: the input outpoints (seal-closure check) and the output scriptPubKeys (tapret/opret recovery). No witness data, no fees, no signatures.

Proposed change

A three-method trait, implemented for bitcoin::Transaction so existing callers are unaffected:

pub trait WitnessTx {
    fn witness_txid(&self) -> [u8; 32];
    fn input_outpoints(&self) -> Vec<([u8; 32], u32)>;
    fn output_script_pubkeys(&self) -> Vec<Vec<u8>>;
}

dbc::Proof::verify and Anchor::verify become generic over W: WitnessTx; the concrete TapretProof/OpretProof impls iterate output_script_pubkeys() and dispatch to the existing ScriptBuf-level paths, which were already chain-agnostic.

Evidence

Applied to a vendored rgb-consensus 0.11.1-rc.10 and run end-to-end on Bitcoin + Liquid regtest:

Result
Patch size	207 LOC, 7 files (+1 new)
Upstream test suite on the patched crate	45/45 pass, none modified
Breaking changes for bitcoin::Transaction callers	none
rgb-ops, rgb-schemas, rgb-invoicing, rgb-aluvm	compile + run unchanged
Liquid-side adapter (impl WitnessTx for elements::Transaction)	~30 LOC

With the patch in place we exercised: a real RGB20 (NIA) transfer on Liquid (unmodified rgb-ops + rgb-schemas), the same transfer with fully confidential (blinded) outputs, a cross-chain Bitcoin↔Liquid RGB atomic swap over a full HTLC (CSV refund branch, negative tests against consensus), and an HTLC claim transaction that simultaneously closes the seal and carries the tapret anchor. All reproducible: https://github.com/kaleidoswap/rgb-on-liquid-spike (file-by-file patch in vendor/rgb-consensus-patched/PATCH.md).

Compatibility

The only public-surface change is dbc::Proof::verify gaining a generic parameter — a minor-version concern, no semantic change. One integration note worth documenting: TapretFirst requires the commitment to be the first P2TR output, so a Liquid wallet that auto-sorts outputs will silently break verification.

Open questions for maintainers

1. WitnessTx location — inside rgb-consensus (our preference) or a sibling crate?
2. Trait shape — are the three methods the right minimum, or should version/locktime be exposed for future proof types?
3. Witness<D> struct — make its tx field generic (Witness<D, T = bitcoin::Transaction>), or add a generic sibling?

What we will do

KaleidoSwap will write the PR against whichever shape you prefer, maintain a WitnessTx impl for elements::Transaction in a sibling repo so integrators have a drop-in path, and ship regression tests plus the working demos with the PR.

[zoedberg]

Thanks for opening this! The direction looks good. I like that this is intentionally consensus-layer only for now; rgb-ops can remain Bitcoin-only while this is still a PoC.

On your questions:

1. WitnessTx location: keep the trait in rgb-consensus, not in a separate crate; verification lives here and an extra crate boundary buys nothing
2. version / locktime: not needed. RGB never commits to the tx version or locktime; the only reason they're "checked" today is the incidental full-tx equality in ConvolveCommitProof::verify and EmbedCommitVerify::verify which should also be generalized as part of this task (the patch should verify at the scriptPubKey level via WitnessTx::output_script_pubkeys())
3. Witness<D> struct: use Witness<D, T = bitcoin::Transaction>, no sibling struct. This preserves source compatibility for current callers

Some things to note:

• the elements::Transaction impl should live in rgb-consensus, not in a sibling repo. All consensus code should stay in rgb-consensus. The WitnessTx trait should be pub(crate) (or sealed if we want it documented), not a public extension point. elements::Transaction impl (and the elements dependency) should be feature-gated by an optional liquid feature so the default build and audit surface don't grow for Bitcoin-only users
• witness_txid() needs to be the canonical non-witness txid. For Elements, elements::Transaction::txid(), which excludes rangeproofs/surjection proofs, not a segwit-style wtxid. It's the identity resolvers look up by and the id downstream seals reference, so it has to match what a Liquid node reports, and it has to be over non-malleable fields or seal identity becomes malleable. The method name reads dangerously close to BIP141's wtxid so I'd rename it txid() or document it explicitly
• tx-bearing types (WitnessStatus, ResolveWitness, Resolver::tx_by_id) and txid types (SealTxid, WitnessOrdProvider, Witness.txid) are both hardwired to bitcoin objects. WitnessTx unblocks verification; full Liquid validation also needs SealTxid and resolver generalization
• we are about to publish significant changes to the consensus repository. Please be aware that rebasing might be difficult, we suggest waiting

[bitwalt]

Agreed on all points — we'll keep WitnessTx in rgb-consensus (pub(crate), elements impl behind an optional liquid feature), drop version/locktime and generalize the ConvolveCommitProof/EmbedCommitVerify equality to scriptPubKey level, use Witness<D, T = bitcoin::Transaction>, and rename to txid() returning the canonical non-witness id. Also agreed the resolver/SealTxid generalization is a needed second step — happy to implement both.

We'll wait for the consensus changes to land and re-target the patch then. If there's a branch or milestone to track, point us at it. PoC stays available as reference: https://github.com/kaleidoswap/rgb-on-liquid-spike