Bip Draft: Sending Silent Payments in PSBTs

[andrewtoth]

This BIP adds support for sending silent payments using PSBTs.

If there are multiple entities handling the PSBT that do not have access to some input private keys, a DLEQ proof by the signer may be added for other entities to verify the corresponding ECDH shares used to derive the output scripts were generated correctly. This will be specified in a following BIP. For the common case of a single entity that has access to all private keys, the DLEQ proof generation is unnecessary.

Spending support is trivial and can be done with a modification to BIP370 to add a new input field for the tweak data.

[jonatack]

Mailing list post on Oct 17 at https://groups.google.com/g/bitcoindev/c/5G5wzqUXyk4.

[jonatack]

Suggest defining "Discrete Log Equality Proofs (DLEQ)" above this / on first use, and discuss overlap with #1689 (if any) or linkage to be made between the two.

[murchandamus]

I did a light review and left a few questions mostly. Your idea makes sense, the content is coming along nicely, and I have found no issues regarding the formatting.

Perhaps some of the answers to my questions could be recorded as footnotes in the Rationale, where they seem likely to be of interest to future readers.

[murchandamus]

If there is a single signer, why would others need to be able to verify? If there are multiple signers, wouldn’t all signers need to collaborate by putting forth shares rather than "computing silent payment outputs"?

[andrewtoth]

If there is a single signer, why would others need to be able to verify?

In the case of a hardware wallet connected to a software wallet, the hardware wallet is the single signer but the software wallet must verify that the output is computed properly before broadcasting.

If there are multiple signers, wouldn’t all signers need to collaborate by putting forth shares rather than "computing silent payment outputs"?

Yes, all signers need to collaborate and put forth shares, but they must also compute the output script before signing. This computed output script must be added to the PSBT before signing to be compatible with BIP 370 signing process. After it is added, the other signers can compute the output script to verify themselves before signing.

[murchandamus]

I was surprised that we provide a single share and a single DLEQ proof per participant rather than one per input. In case there are multiple participants, this leaks to all other participants which inputs were provided in bulk by one party. I was wondering if there might be better privacy properties if participants provide a separate share for each input, that way all subsequent participants do not know how previous inputs group if the PSBT is passed in a circle rather than shared with all participants after each step. Maybe I’m overthinking this, though.

[andrewtoth]

This is provided as a performance optimization so that there is only one proof for multiple inputs.
It is not required to combine all your inputs. You could selectively add different shares and proofs for each inputs you don't want to link. I suppose I could make that option more explicit in the text.

[andrewtoth]

See my comment here.

[nothingmuch]

As specified, computing the sum of ECDH_SHARE values requires some additional validation to ensure the computed script outputs are spendable.

This makes some intermediate states of a PSBT that are currently allowed either unsafe (potentially creating unspendable outputs) or with validation introduces potential for failure, because a signer is technically allowed to add ECDH shares for two non-disjoint input sets with a non-empty symmetric difference.

Instead of introducing this additional validation I think it would be simpler to specify one ECDH share per input, as a per input field, this is actually more compact without DLEQ proofs, as Murch notes, better for privacy, and IMO seems easier to implement, but at the very least I think this needs clarification on how to compute the sum safely.

[nothingmuch]

This seems to imply any subset of the inputs can be specified, presumably for grouping by owner.

The main advantage over allowing only one outpoint per ECDH share seems to be a reduction in proving complexity for signers who choose to provide DLEQ proofs, since the 36 byte outpoint outweighs a a * B_scan if it were provided in a per input field with an output index or even B_scan as the keydata.

Some disadvantages:

1. Mostly theoretical privacy concern: the DLEQ proof is publicly verifiable, and so much stronger heuristic for common ownership than the traditional common input ownership heuristic. Other parties or observers of the PSBT might store or leak such values, which hurts Signers' deniability.
2. If the outpoint lists are not disjoint, then the correct sum might not be computable even if all inputs are accounted for by some share. If every ECDH_SHARE corresponded to only a single outpoint, as long as each signer contributes a value for each input, in any order, the sum can always be computed. If users modify a PSBT over multiple devices with partly overlapping access to private keys, single input shares ensure all intermediate states can lead to a fully signed state, regardless of the order in which the user proceeded.

[andrewtoth]

The main advantage over allowing only one outpoint per ECDH share seems to be a reduction in proving complexity for signers who choose to provide DLEQ proofs

The main advantage is reduction in both ECDH share generation and proving complexity.
All outpoint private keys can be summed, and then only a single ECC mult for the shares, and 2 ECC mults for the proof.

Consider the common case of a single sig wallet using a hardware signing device receiving many small inputs over time. The wallet now contains 100 utxos and wants to spend to a single silent payment address.
By using single share and proof for each outpoint, that is 100 * ECDH share + 100 * DLEQ proof (2 ECC mults) + 100 * signatures = 400 ECC mults.
By summing all inputs, the result is now 1 * ECDH share + 1 * DLEQ proof (2 ECC mults) + 100 signatures = 103 ECC mults.
On a simple hardware signing device, this makes the signing time 4x, making it potentially a few minutes to over 10.

re: disadvantages

1. It is only an option to combine the inputs. You can still provide a share and proof per input or whatever combination of inputs you'd like. I will make this more clear in the text. I believe the single sig with hardware wallet is the most common case though, so we should optimize for that case.
2. This is indeed a potential pitfall. It could also be addressed by providing a share and proof per input as a fallback. I will add some text to address this situation.

[andrewtoth]

Here's a blog post of time it takes to sign transactions on various hardware devices. I think it makes sense to think about optimizing for this.

[andrewtoth]

I think the 2 main use cases will be for a wallet that has access to all inputs, or only one or a few that they would not like to link. So, perhaps having subsets of different inputs is not the best design for this spec.

How about optional fields per input or optional global fields? If the global fields are present, they represent the sum of all inputs. Otherwise, a field per input must be set. I think this is simpler than using the key to specify subsets.

[nothingmuch]

For a given set of outpoints, there are multiple relevant B_scan generators all of which share share the same a witness in their respective proofs. This could be one batch proof per SP output set, instead of per individual B_scan. Although only a single 64 byte proof per input set is required, the prover and verifier complexity is the same as n proofs, where n is the number of SP outputs.

[andrewtoth]

Yes, this is a great insight, thank you!

Would it not also reduce the complexity, since it would only be one proof to verify after summing the B_scan generators instead of verifying each proof individually?

[nothingmuch]

If you mean given $P = aG$, and scan keys $(B_i)_{i=1}^n$, it's possible to prove knowlege of $a$ in $Q = a (n^{-1} \sum B_i)$ where $n^{-1} \sum B_i$ is a public input, but I'm not sure this is sound / proving the same thing.

This reference (section 3.2.3.3) seems to suggest it isn't, see footnote 16 on page 73, there's additional delinearization terms which are similar to key cancellation mitigation (and afaict are amenable to Fiat-Shamir just the same). This is an improvement over my implied suggestion as batched multiplication be used, but it does not reduce it to a single multiplication. Admittedly I don't yet see how to actually attack soundness as a malicious prover, especially when the prover does not control the choice of the the B_scan keys.

The batch proof I'm familiar with involves having an R point per generator, so same structure as proposed in the DLEQ BIP, just generalized from 2 to n+1 verification equations. When the proof is encoded as the challenge and the response, the encoding the n+1 R points is implicit, so the size would still be 64 bytes and both prover and verifier work is concretely reduced (~half the verification equations, and a shared challenge hash), but not asymptotically as the total work is still linear for both prover and verifier.

[nothingmuch]

Using the mentioned protocol, "RME-based common exponent Schnorr protocol" (Henry14 3.2.3.3), the verifier performs 2+k ECC mults per proof, where k is the number of silent payment outputs, but the k mults can be shared for a batch of proofs, which large transactions can be a significant improvement in verifier complexity.

Compared to this protocol the strawman protocol I described in the previous comment is broken in two ways, not just one:

• two verification equations are needed, instead of only one (section 4.2 describes a lattice basis attack on soundness since the prover's responses are undetermined)
• de-linearization (or in the multiplicative terms of Henry14, RME) is needed for soundness as well (see section 3.1.4.3)

In a non-interactive setting, the t_i terms of the random linear combination is generated by hashing.

If $t_i = H(B_1, B_2, \dots, B_k)$ ($B_i$ is supposed to be {B_{scan}}_i but that apparently isn't in github's latex regex =P) the $k$ proofs would share the same delinearized sum $\sum_{i=1}^k t_i B_i$, which appears as a term in the 2nd verification equation. This reduces $k^2$ ECC mults to $k$ (but asymptotically is the same because of other side of the equation still has a $\sum_{i=1}^{k} t_i S_i$ term where $S_i = aB_i$ is a public input).

Unfortunately the full set of SP_V0_INFO fields to be finalized before DLEQ proofs can be computed in that case, but if I understand Lemma 3.5 I think the $t_i$ values used for this can be derived as $t_i = H(B_i)$ without destroying the proof of soundness. If this is correct then this reduction in verifier computation could be applied to batch-verify whatever $k$ batch-DLEQs, but number of roundtrips is not reduced because new proofs would be needed for the new outputs, and verifiers would need to be given explicit subsets of the outputs for each batch proof indicating what it covers, instead of being able to construct the proof statements implicitly from the set of all SP_V0_INFO fields, so it's not clear that this is a meaningful improvement over hashing all of the $B_i$s to delinearize.

[nothingmuch]

IIUC, if it were not for this, blinding the SP_V0_INFO field would be technically be possible.

Since that would necessarily add another round of communication between the various entities, as only only updaters with access to the blinding keys could set the output.

A global flag to indicate whether the additional round is required might make sense?

This flag might have 3 values, indicating if blinding is not used (allowing signers to update outputs), optional (precluding that), or required in which case all outputs must have SP_V0_INFO, with dummy values used for non-SP outputs. "required" or "mandatory" blinding is a bit misleading, it's providing deniability as to which outputs use SP, not requiring SP and blinding actually be used.

[andrewtoth]

I don't think it's this requirement, but the one a few lines up:
* If all eligible inputs have an ECDH share, compute and set the PSBT_OUT_SCRIPT.

We would need to only compute the output scripts for the non-blinded outputs.
Yes, if we want to hide which participants add an SP vs a regular taproot address entirely, we would need all outputs to have a dummy SP_V0_INFO and have everyone compute shares and proofs for them, even if they don't end up being used.

[nothingmuch]

Assuming my suggestion to make shares be one per input is rejected, this needs to verify that the sets of outpoints in all ECDH_SHARE fields for a given scan key form a valid partition of the BIP 352 input set (no duplicates, no missing outpoints) before computing the sum of the values, or this sum might differ from b_scan·A where A is also is computed as in BIP 352 scanning.