Add ELIP: Silent Payments for Elements

[soloking1412]

Adds a draft ELIP describing how BIP-352 silent payments work on Elements based chains, where transaction outputs are confidential.

Key derivation is unchanged from BIP-352. What Elements adds is blinding: a confidential output is blinded to a public key chosen by the sender, so unless the receiver can derive the corresponding secret key it cannot unblind the output, and an output it cannot unblind is an output it cannot spend. The document defines that key as a tagged hash of the same ECDH shared secret used to derive the output key, so a payment needs no data beyond the transaction itself.

It also specifies the parts of BIP-352 that are ambiguous on a chain with peg-ins, issuances and explicit fee outputs:

• Address encoding — the BIP-352 encoding with Elements human readable parts (lqsp, tlqsp, elsp), so a Bitcoin silent payment address cannot be paid on Liquid and vice versa.
• Input eligibility — peg-in inputs never contribute their public key, since the output they spend is on the Bitcoin chain; their outpoints still count towards the smallest one.
• Outpoint serialization — the vout is hashed with the peg-in and issuance flags cleared. Elements sets these flags when serializing and strips them when parsing, so without this rule two implementations would compute different values.
• Receiving — the "Tweak Server" model of the BIP-352 index server specification, with the server endpoints and the client scanning algorithm. On Elements the scan key unblinds as well as detects, so the models in which the scan key is shared with a service would hand that service every amount and asset of the wallet; this document recommends against them.

Reference implementation

Blockstream/lwk#170, in the silent_payments module of the lwk_wollet crate.

It is checked against the official BIP-352 send and receive test vectors in both directions, against the test vectors in this document, and against transactions built, blinded and signed the way a wallet builds them, which is what covers the blinding part that BIP-352 does not.

Notes for editors

The file uses the alias name and ELIP: ? as ELIP-1 requires; happy to update the number and the Comments-URI once one is assigned.

[delta1]

Hi @soloking1412, thanks this looks generally good. However, #37 predates this by almost 2 months.

Presumably you've done this work for the bounty?

[soloking1412]

Hi @soloking1412, thanks this looks generally good. However, #37 predates this by almost 2 months.

Presumably you've done this work for the bounty?

Yes — this was for the bounty, and I put it together without being aware of #37. That's on me for not checking the open PRs first. @42Pupusas clearly got here first, and their spec is solid work.

The two specs converge on the same core design (per-output blinding key derived from the shared secret, lqsp/tlqsp HRP, coin type 1776). The one substantive divergence is the blinding tag — Silent-Payment-Blinding-Key/1.0 here vs LiquidSilentPayments/Blind in #37 — which needs to be settled one way for cross-wallet interop.

Where my contribution adds something not in #37 is the reference implementation: it's integrated directly into LWK (Blockstream/lwk#170) — wired into the wallet's descriptors, blinding, and tx builder rather than standalone — and it passes the official BIP-352 send/receive vectors plus end-to-end tests over real blinded Liquid transactions.

I'll leave it to the maintainers and @42Pupusas to decide how they'd like to proceed on the spec — whether to consolidate, take one over the other, or align on the open points. Whatever spec is chosen, I'm happy to align the LWK implementation to it.

Beyond the spec itself, I'd be glad to keep contributing to the rest of this effort — the LWK send/receive implementation and the tweak-server scanning client are the pieces still to land, and I'm happy to pick those up or collaborate with @42Pupusas on them so this ships end-to-end, regardless of whose spec is chosen.

[delta1]

Yes it would be great for the two efforts to be aligned, if @42Pupusas is willing then perhaps the bounty could be split between you two? Since I do see some value in your spec here that's not included there.

These efforts should be aligned.