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?

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.

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?

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

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

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


		==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

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!

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!

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!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

42Pupusas Jun 18, 2026 •

edited

Loading