Add Silent Payments for the Liquid Network by 42Pupusas · Pull Request #37 · ElementsProject/ELIPs

42Pupusas · 2026-06-02T02:00:05Z

This ELIP specifies BIP-352 Silent Payments adapted to the Liquid Network's Confidential Transactions. Each normative rule is tagged as BIP-352-derived, a Liquid adaptation, or an open design choice (stated preferentially). Includes worked test vectors and abstract data structures.

A Standards Track draft specifying BIP-352 Silent Payments adapted to the Liquid Network's Confidential Transactions. Each normative rule is tagged as BIP-352-derived, a Liquid adaptation, or an open design choice (stated preferentially). Includes worked test vectors and abstract data structures.

emjshrx · 2026-06-02T20:34:55Z

+
+==Reference Implementation==
+
+A reference implementation demonstrating address encoding, input aggregation,


A reference implementation in python would be nice to review this ELIP

I have working examples using LWK in Rust, is that acceptable? not too familiar with Python

https://github.com/42Pupusas/elip-sp-reference/tree/main

I attempted to wire in everything together in a Python implementation, but the blinding logic for Confidential Transactions exposed on the Rust crate is not as readily available on python tooling, and my skills in python are not good enough to rewire everything to ensure it will work correctly.

I have tried to clean up the Rust implementation and added more comments throughout mapping to the ELIP documentation. I hope that will sufficient?

Have you tried using wallycore? If that doesnt work maybe we can replace LWK with a more lighter elements crate?

emjshrx · 2026-06-02T20:52:03Z

+Because <code>bk_k</code> and <code>t_k</code> are outputs of a random oracle (a
+tagged hash) evaluated on '''disjoint domains''' over the same secret <code>S</code>,
+they are independent: knowledge of one does not assist in recovering the other or
+<code>S</code>. The domain tag <code>LiquidSilentPayments/Blind</code> MUST differ


Would a third person who wants to detect silent payments, be able to compute blinding keys for each transaction and then check if it unblinds to identify Silent payments?

It should not be possible as this is using the same hardness assumption from BIP-352 that the blinding key is computed from the sender+receiver Diffie Hellman shared secret, which should never be computable by third parties.

Trim BIP-352 re-explanation to focus on Liquid-specific differences: - Shorten abstract and motivation prose - Reduce BIP-352-compliant sections to brief restatements - Remove Rationale section (reasoning is stated inline in each [Liquid]/[Choice] design section)

The flow is essentially identical to BIP-352; fold the three subsections (filter omission, server interface) into one paragraph plus the interface example.

Switch silent-payment outputs from confidential P2WPKH to confidential Taproot (OP_1 <x_only(P_k)>), with P_k used directly per BIP-352 (no script tree, no taptweak). This aligns the output, spend path, and index-server data with BIP-352's x-only conventions verbatim. - Output is now Taproot-only; eligible inputs keep BIP-352's full set (P2TR, P2WPKH, P2SH-P2WPKH, P2PKH), so an SP output is itself eligible as a later input and the even-Y rule applies unchanged. - Spending is an ordinary BIP-340 key-path spend (even-Y normalized). - Collapse the now-pure-BIP-352 sections (input aggregation, eligible inputs, shared secret, output representation) into one consolidated 'Reused from BIP-352 unchanged' section. - Update test vectors (Taproot scriptPubKeys) and reference-implementation note (verified against LWK, reproduces vectors byte-for-byte).

…ls section The previous lq/tlq HRP collided with ordinary Liquid CONFIDENTIAL addresses (blech32 lq/tlq), defeating the distinct-HRP goal. Switch to lqsp/tlqsp, which differ from every existing Liquid HRP (ex/tex unconfidential, lq/tlq confidential) and from Bitcoin's sp/tsp. Update the test-vector address accordingly (verified against LWK). Also fold the Labels section into the consolidated BIP-352 reused section (labels need no Liquid adaptation); the one substantive note — the blinding key is label-independent — moves to the blinding-key section.

Reduce the Reference Implementation paragraph to what the public reference covers: it reproduces the test vectors byte-for-byte and demonstrates non-interactive unblinding of the shared-secret-blinded output. Wallet integration (scanning, signing, transaction building) is left to implementations, rather than enumerated here.

emjshrx · 2026-06-13T21:38:50Z

+non-interactively by the receiver. Wallet integration — scanning, signing, and
+transaction building — is left to implementations.
+
+==Acknowledgements==


JAN3 should be in the acknowledgements if this BIP is awarded the bounty

emjshrx · 2026-06-13T21:41:27Z

+tweaks, which does not exist in common protocols today; until then, silent-payment
+outputs are usable with software signing.
+
+==Reference Implementation==


The point of the reference implementation in the BIP is like a sort of documentation. I will review your rust code but I feel it should be in python, or something thats close to human readable code. You can check https://github.com/bitcoin/bips/blob/master/bip-0352/reference.py

There should also be implementation of the tweak server and decryption by the wallet

Tweak server and Blinding and Unblinding now shown.

Had a cursory look at https://github.com/42Pupusas/elip-sp-reference/blob/main/src/lib.rs and it looks good. Im just concerned if rust is human readable enough for a BIP.

Ok the wallycore for sure was the easier path in Python. I reused most of the BIP-352 reference implementation that uses libsecp256klab and a bech32 impl from Peter Wuille, then added wallycore blinding functions where appropriate to create a parallel Python reference implementation.

I am not a good judge of whether the Python code is more human readable as I have strong biases against Python and for Rust, but that particular bikeshed is not worth exploring, so I do hope the review is easier with the new Python code.

emjshrx · 2026-06-13T22:00:39Z

+# aggregates the private keys of its eligible transaction inputs into a single scalar <code>a</code> and forms <code>A = a·G</code> '''[BIP-352]''';
+# computes a transaction-bound <code>input_hash</code> and an ECDH shared secret <code>S</code> with the receiver's scan key '''[BIP-352]''';
+# derives, for output index <code>k</code>, a spend public key <code>P_k</code> that only the receiver can later re-derive '''[BIP-352]''';
+# places <code>P_k</code> in a Taproot (P2TR) output '''[BIP-352]''', and blinds that output's asset and amount to a blinding key that is itself derived from <code>S</code> '''[Liquid]'''.


Actually, we need to think harder on this. On-chain, there is actually some Taproot usage, so SP payments get masked. But on liquid, if there is no usage at all, we might run into issues.

A taproot output will definitely be SP in liquid I think. We need to analyse usage

A quick 500 block scan shows that Taproot usage is very small, around 3% .

So a TR output won't "definitely" be SP, but the anonymity set is quite small.

Is this enough nudge to drop taproot and use p2pkh instead?

I feel P2PKH is better, but I would like to get a second opinion on this. More specifically, understand why the mainchain decided to use Taproot.

I was digging through the old BIP352 threads last weeks to get more clarity for the taproot output being the default.

I was unable to find much discussion around it, but here is some explicit comments on it I found:

Forward Looking MuSig Interop - Taproot makes MuSig/FROST implementations simpler/possible

Scanning Efficiency Concerns - The TR Tweak makes scanning easier when the payment has several inputs.

Also to consider from the implementation difference is that with TR output , the script is the x-only key, so we only do direct x-coordinate comparison. With P2PKH the scanner has to serialize compressed, HASH160, then compare. The overhead is not immense but should be considered.

All three have their merits I can see, just unsure of the tradeoff with anonymity set size in Liquid.

Also the BIP-352 itself generalizes the choices to just

"^ Why only taproot outputs? Providing too much optionality for the protocol makes it difficult to implement and can be at odds with the goal of providing the best privacy. Limiting to taproot outputs helps simplify the implementation significantly while also putting users in the best eventual anonymity set."

IMO it's more important that SP for elements/liquid be directly derived from BIP-352. This increases security and it inherits all the review from upstream and can help with re-use of tooling etc.

Currently there is much more P2PKH than TR, but that will likely/hopefully change (as it will on Bitcoin with e.g. more usage of L2 systems using TR addresses and LN using TR addresses).

Also, the anonymity of SP addresses within the larger set of TR addresses is a nice-to-have additional feature, and not the intended privacy goal of SP.

emjshrx · 2026-06-13T22:20:21Z

+Throughout this document, every normative rule is tagged to make its origin explicit:
+
+* '''[BIP-352]''' — the rule is taken unchanged from BIP-352. Implementations SHOULD reuse existing, reviewed BIP-352 logic for these parts.
+* '''[Liquid]''' — the rule is an adaptation made necessary by a structural difference between Liquid and Bitcoin (most importantly, Confidential Transactions and Liquid's deployed output types). These are the substantive technical contributions of this document.


Suggested change

* '''[Liquid]''' — the rule is an adaptation made necessary by a structural difference between Liquid and Bitcoin (most importantly, Confidential Transactions and Liquid's deployed output types). These are the substantive technical contributions of this document.

* '''[Liquid]''' — the rule is an adaptation due to Confidential Transactions and Liquid's deployed output types.

Theres still a lot of AI generated verboseness, imo. I feel they can be cleaned up and we dont need to add anything new in this BIP than whats absolutely needed.

For me it feels like ===Output blinding key '''[Liquid]'''=== is the only real specification in this doc and the remaining spec is just to use exisiting BIP 352 logic. Everything can be condensed imo

will push a condensed revision once a path has been settled for TR vs P2PKH

Please do not wait for me to get back to make the changes as I may take a while to reply and another reviewer might want to review this, etc. Try to make the PR as up to date as possible whenever you get time to work on it.

Condensed the ELIP to only the specific changes needed for Liquid, reusing and adoption the notation conventions in BIP-352.

emjshrx · 2026-06-13T22:56:48Z

+bk_k = hashLiquidSilentPayments/Blind( serP(S) || ser32(k) )   (a 32-byte scalar)
+BK_k = bk_k·G


This bit is still not clear to me.

A and S can be computed by a third party. What is k?

Actually what is hashLiquidSilentPayments/Blind( serP(S) || ser32(k) ) ? can we just write the math and not generic fn names

k is the output index counter the sender chooses and keeps for a specific SP address (0 first payment, +1 recurring), not transmitted on-chain.

A third party who knows the receiver's address can compute A and S from public data, but to derive the blinding key for a specific output they'd have to brute-force the gap limit × every address × every transaction.

can we just write the math and not generic fn names

is following the notation style in BIP-352 ok?

so changing to:

tag = "LiquidSilentPayments/Blind" bk_k = int( SHA256(SHA256(tag)||SHA256(tag) || serP(S) || ser32(k) ) ) mod n

Pin the exact ASCII tag string (LiquidSilentPayments/Blind) verbatim, since interop depends on every implementation hashing the identical bytes. A one-character difference silently breaks unblinding across wallets.

Define it the same way BIP-352 defines its own: state the BIP-340 tagged-hash construction once in the conventions section then use the named form hashLiquidSilentPayments/Blind(...). Please note that LiquidSilentPayments/Blind should be in the subscript like BIP-352

A third party who knows the receiver's address can compute A and S from public data, but to derive the blinding key for a specific output they'd have to brute-force the gap limit × every address × every transaction.

This is wrong. I was wrong earlier, a third party cannot compute S and that's the security. Brute-forcing isn't hard

The new Privacy section should now be clearer and explicit about where the privacy and security assumptions come from.

Conventions: state the BIP-340 tagged-hash construction once and pin the exact ASCII tag strings (incl. LiquidSilentPayments/Blind, 26 bytes) in a table; switch the derivation steps to the named hash_<tag>() subscript form, matching BIP-352 and removing the define-after-use tag_* inline forms. Privacy: rewrite the rationale. The previous text wrongly claimed S is derivable from the public A and B_scan; that is the computational Diffie-Hellman problem. Privacy rests on the secrecy of b_scan; the address is not secret and the output index k is not secret. Align tweak terminology to BIP-352 (partial tweak -> tweak). README: add the ELIP index row.

emjshrx · 2026-06-30T10:52:13Z

+spent by an ordinary key-path signature, so existing relay and validation rules apply.
+Wallets that don't implement this are unaffected.
+
+==Reference Implementations==


This should be moved to this repo. Follow the convention in https://github.com/bitcoin/bips/blob/master/bip-0352/reference.py and use MIT license

Okay ignore my comment about MIT license as other ELIPS are BSD license as well

This should be moved to this repo

Do you mean the reference implementations? I noticed all the other ELIPs had external reference implementations so did it that way.

I think they are almost always in https://github.com/ElementsProject/elements and thats why. Having them in a personal repo seems wrong or atleast different from the conventions in the bips repo

Move the Rust and Python reference implementations from the standalone elip-sp-reference repo into elip-silent-payments-liquid/{rust,python}/, following the bitcoin/bips convention of a folder named after the spec (e.g. bip-0352/) holding its supporting code. Update the ELIP's Reference Implementations section to link in-tree instead of to the external repo.

tomt1664 · 2026-07-06T10:49:32Z

A few comments:

“internal byte order” of the outpoint_L encoding should be defined unambiguously.

specify explicitly handling if bk_k falls outside the valid scalar range (is 0 or > n). BIP-352 has this for t_k (if it is out of range, the output is skipped). Should be the same for bk_k: if bk_k = 0 mod n, the output index k is skipped.

In the final version a BIP-32 path should be specifed (and will be different to BIP-352).

…BIP-32 path - Define outpoint_L txid 'internal byte order' unambiguously (raw dSHA256 bytes as serialized in a tx input, reverse of RPC hex display) - Skip output index k when bk_k is 0 or >= n, mirroring BIP-352's t_k handling; update Python (from_bytes_nonzero_checked) and Rust references - Specify BIP-32 derivation path with SLIP-44 coin type 1776 (Liquid): m/352'/1776'/account'/1'/0 (scan), m/352'/1776'/account'/0'/0 (spend)

delta1

Hi @42Pupusas. This ELIP is missing a Copyright section. Some other review comments follow.

delta1 · 2026-07-07T13:03:41Z

+<code>S = input_hash·a·B_scan = b_scan·(input_hash·A)</code>. Computing it needs either the
+sender's input secret <code>a</code> or the receiver's secret scan key <code>b_scan</code>,
+so this inherits the BIP-352 privacy model. CT adds one thing on top: even someone who
+holds <code>b_scan</code> learns only that an output is a silent payment, not its amount or asset.


The claim "even someone who holds b_scan learns only that an output is a silent payment, not its amount or asset" is false.

b_scan is sufficient to derive bk_k and fully unblind amounts. S = b_scan·(input_hash·A) is computable from b_scan alone plus public chain data, and bk_k = hash(serP(S)||k) mod n

Ok I was getting confused I because of the DH secret step, but yes , this is correct, a light wallet/client that hands its b_scan key for non-interactive unblinding, will lose CT confidentiality.

Adding an explicit comment on the tradeoff.

delta1 · 2026-07-07T13:05:58Z

+** If <code>bk_k = 0</code>, increment <code>k</code> and continue
+* Let <code>BK_k = bk_k·G</code>
+* Blind the output's asset and amount to <code>BK_k</code>, as for any confidential Liquid output
+


Ambiguous "increment k and continue" when bk_k = 0.
Unclear whether P_k/scriptPubKey also re-derives with the new k, or only the blinding key recomputes. If misimplemented, sender and receiver derive different blinding keys for that output, making it unblindable.

Maybe clarify that P_k must also be rederived with new k

delta1 · 2026-07-07T13:10:18Z

+        nonce,
+        script_pubkey,
+        witness: TxOutWitness {
+            surjection_proof: None,


build_confidential_sp_txout sets surjection_proof: None in the TxOutWitness. Liquid consensus requires a surjection proof on every confidential output; without one the transaction is rejected by every node. The Python counterpart similarly produces no surjection proof in its returned dict. The tests pass because unblinding reads only the rangeproof, not the surjection proof — but any implementer copying this code would produce unbroadcastable transactions. A comment or a stub surjection proof should be added.

delta1 · 2026-07-07T13:11:10Z

+    eng.input(&lowest_outpoint(outpoints));
+    eng.input(&a_pubkey.serialize());
+    Scalar::from_be_bytes(InputsHash::from_engine(eng).to_byte_array())
+        .expect("input_hash < curve order")


Rust panics instead of reducing mod n for hash ≥ n; Python reduces; implementations disagree.
Scalar::from_be_bytes(...).expect("input_hash < curve order") in input_hash (and identically in blinding_secret) panics on the ~2⁻¹²⁸ chance the hash output ≥ n. The Python reference uses Scalar.from_bytes_wrapping() which reduces mod n, matching BIP-352's spec text ("interpreted as a 256-bit big-endian integer mod n"). The two reference implementations have incompatible behavior on this edge case.

After double checking BIP-352 Creating Outputs

If input_hash is not a valid scalar, i.e., if input_hash = 0 or input_hash is larger or equal to the secp256k1 group order, fail

So in this case I think the Rust behaviour is correct and its the Python ref that needs to fail instead of wrapping.

…scan-key privacy, outpoint example - Harmonize input_hash/t_k out-of-range handling with BIP-352 v1.0.2: fail, don't reduce mod n (Python switched to from_bytes_checked; Rust gains zero checks) - Document that build_confidential_sp_txout omits the consensus-required asset surjection proof and that wallets must add one at transaction assembly - Clarify bk_k skip: the whole output index k is skipped and both P_k and bk_k re-derive from the next index - Correct Privacy section: a b_scan holder can unblind outputs (bk_k derives from S), not merely detect them; local scanning required for confidentiality against a scanning server - Add a worked byte-level example of outpoint_L internal byte order

build_confidential_sp_txout now takes the transaction inputs' (generator, asset tag, abf) and produces a consensus-required surjection proof instead of omitting it — Rust via secp256k1_zkp::SurjectionProof::new, Python via wally.asset_surjectionproof. The Rust test verifies the proof against the input generators.

…itself wallycore's asset_surjectionproof is _wrap_bin-wrapped: it takes the 7 input arguments, sizes the proof via asset_surjectionproof_len internally, and returns the buffer. Passing bytes_out ourselves raised TypeError. Confirmed by running the Python suite with wallycore: 5/5 pass, surjection proof round-trips.

42Pupusas · 2026-07-07T22:57:02Z

Appreciate all the reviews.

Internal byte order now defined explicitly:

the raw double-SHA256 bytes as they appear in a serialized tx input, i.e. the reverse of the hex shown by RPC/explorers

bk_k = 0 or ≥ n: fixed to match BIP-352's t_k handling. Added a MUST that (P_k, bk_k) always share the same index, since re-deriving only the blinding key would leave the output unblindable.
BIP-32 path specified same scheme as BIP-352 with SLIP-44 coin type 1776 (Liquid) m/352'/1776'/account'/1'/0 (scan) and m/352'/1776'/account'/0'/0 (spend), coin type 1' for testnet/regtest. Disjoint from Bitcoin's m/352'/0'/...
input_hash / t_k out of range now fail (per BIP-352 v1.0.2) in both references.
Both references now generate real asset surjection proofs instead of omitting them.
Corrected the Privacy section: a b_scan holder can unblind outputs, not merely detect them, since bk_k derives from S. Wallets wanting confidentiality against a scanning server must scan locally.

Both reference implementations updated to match, test vectors unchanged.

emjshrx reviewed Jun 2, 2026

View reviewed changes

42Pupusas added 5 commits June 2, 2026 15:22

Condense light-client receive section to a single paragraph

ab0c3d6

The flow is essentially identical to BIP-352; fold the three subsections (filter omission, server interface) into one paragraph plus the interface example.

42Pupusas requested a review from emjshrx June 3, 2026 01:54

42Pupusas mentioned this pull request Jun 9, 2026

Add Silent Payment Support Blockstream/lwk#164

Open

emjshrx reviewed Jun 13, 2026

View reviewed changes

42Pupusas added 4 commits June 29, 2026 16:32

Condense spec to BIP-352 style; fix Privacy, refs, and prose

520320e

Link both reference implementations (Rust and Python)

237599c

Tighten Differences-from-BIP-352 section and surrounding prose

28d6c18

42Pupusas force-pushed the elip-silent-payments-liquid branch from 276f423 to 28d6c18 Compare June 29, 2026 22:32

emjshrx reviewed Jun 30, 2026

View reviewed changes

delta1 requested changes Jul 7, 2026

View reviewed changes

42Pupusas added 3 commits July 7, 2026 16:22


		==Reference Implementation==

		A reference implementation demonstrating address encoding, input aggregation,

	* '''[Liquid]''' — the rule is an adaptation made necessary by a structural difference between Liquid and Bitcoin (most importantly, Confidential Transactions and Liquid's deployed output types). These are the substantive technical contributions of this document.
	* '''[Liquid]''' — the rule is an adaptation due to Confidential Transactions and Liquid's deployed output types.

		bk_k = hashLiquidSilentPayments/Blind( serP(S) \|\| ser32(k) ) (a 32-byte scalar)
		BK_k = bk_k·G

Uh oh!

Conversation

42Pupusas commented Jun 2, 2026

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

42Pupusas Jun 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tomt1664 commented Jul 6, 2026

Uh oh!

delta1 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

42Pupusas Jun 18, 2026 •

edited

Loading