SilentPayment for use in Bisq2

BIP-352 describes Silent Payments. The Sender of a transaction can generate new addresses on behalf of the receiver, based of a static (silentpayment) address, without having the disadvantages of xpubs, especially the gap-problem. Many senders can use the same silent payment address without any coordination among them and the receiver is able to identify all addresses generated by the senders. Since only the sender can identify all his addresses, this ia also a privacy tool, which could be well-used in Bisq to make payment to BurningMen more private.

working principle of silent payments

The receipient must generate a private key b and calculate the public key B=b \cdot G. This public key B is communicated beforehand to the sender as silent payment address. If an input of the sending transaction has a key spend, then the sender knows the private key a and the public key of the key spend A=a \cdot G. With

(1) \hspace{4pt} a \cdot B = a \cdot b\cdot G= b \cdot A (ECDH Elliptic-curve Diffie-Hellman) Alice can construct an output with point P, such that P := B + hash( a \cdot B) \cdot G = B + hash(b \cdot A) \cdot G Only if you know secret key a or b, then you can detect that P is a silent payment, so only Alice and Bob will know (even not others which have access to the silent payment address B ) Only Bob will be able to spend that output because the secret key of B, which is b, is needed:

\begin{aligned} P &= B + hash(b \cdot A) \cdot G \\ &= b \cdot G+hash(b \cdot A) \cdot G \\ &= (b + hash(b \cdot A))\cdot G\\ &= p \cdot G \end{aligned}

so the secret key p is p=b + hash(b \cdot A). Bob knows b, because that’s his private key and he learns A by scanning the blockchain and extracting from each transaction the pubkeys and testing if he can generate a matching P.

silent payment and MuSig2 / FROST

silent payments need the private key of the input of a transaction. in case the input is a script its not needed. But in case of a MuSig2-type input, the output key is dependent on that input in a similar way as MuSig2 signatures are constructed. According to Josie, from high level:

1. Each participant would do a partial ECDH with their secret signing key and Bob’s public key
2. These partial ECDH shares can be aggregated a_1 \cdot B + a_2 \cdot B = (a_1+a_2)\cdot B = a \cdot B and then used to create the output(s)
3. While this BIP-352 does not cover Musig2 explicitly, reading through BIP375 should give a more detailed description of what I’m describing.

proof of payment

The DLEQ described in BIP374 (and used in BIP375) can also be used as a proof of payment: Each participant would provide a DLEQ for their input and their partial ECDH share The proofs can be verified and the shares aggregated, which allows the verify to produce the expected output for Bob.

state of implementation

here is Josie’s answer from Mar, 2025: “The wallets that can receive today are very experimental, in my opinion, and not ready for mainnet. If you are able to require a special version of Bitcoin Core wallet, I think that is the best option: silent payments works best when the user is running their own Bitcoin Core node.

I am currently working on the libsecp256k1 module (https://github.com/bitcoin-core/secp256k1/pull/1519) and will also be rebasing and fixing up the send and receive PRs for Bitcoin Core. I expect this will take me until mid April, but can let you know if they are finished sooner.”

The integration of BIP352 into bitcoin core is tracked here.