BIP 352: Silent Payments

[josibake]

Silent payments is a static address protocol for Bitcoin, originally proposed on the mailing list here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-March/020180.html

Since then, the proposal has received several rounds of review and has a WIP implementation here: bitcoin/bitcoin#27827 . The proposal has also been sent to the mailing list for review here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-June/021750.html

Proposing this as an informational BIP to ensure wallets across the ecosystem can standardize and correctly implement the protocol.

[brandonblack]

Glad to see this proposal advancing! I think with some minor changes it can be compatible with MuSig2 Taproot Keypaths (and potentially other off chain key aggregation schemes), which make it a powerful way of transacting privately even between users with advanced keys and scripts on Taproot.

[vostrnad]

Some light review so far, but I'm really liking the proposal. Being able to easily implement just the sending part will no doubt greatly accelerate adoption by wallets.

Apart from the inline comments I also have a few style nits:

• "e.g" is used instead of "e.g." in a few places.
• Mixed usage of curly (’) and straight (') single quotes.
• Some footnotes ("Rationale and References") are missing a period at the end.
• In Creating outputs, "Let a = a₀ + a₁ + … a_i, where each a_i" should have a_n be the last member of the sum, like in the rest of the document. Same goes for the sum in Scanning where the last member should be A_n.

[josibake]

Thanks for the review, @vostrnad !

Apart from the inline comments I also have a few style nits:

These should all be fixed now in 1ae1b4b

[vostrnad]

Second round of review. To complement this I wrote a quick and dirty implementation covering most of both sending and receiving. It was quite easy and seems to work, can't wait for test vectors to see how many bugs it has! 😅

In addition to the inline comments I have one general comment and one style nit:

• There are no specifics on how to deal with situations where EC operations fail to produce a valid point. I'm not sure if this is necessary, just mentioning this because my implementation has a lot of assertions.
• Tweak expressions are not consistent in whether the G part comes first or second. For example, in BIP341 it always comes second.

[josibake]

Thanks for the continued review, @vostrnad !

There are no specifics on how to deal with situations where EC operations fail to produce a valid point. I'm not sure if this is necessary, just mentioning this because my implementation has a lot of assertions.

Do you have a specific scenario in mind? I'm certainly not an expert in this area, but I don't think we should get a failure by doing additions and multiplications (summing priv keys, pub keys, ecdh). If we can have a failure when summing up the private keys, public keys, or during the ECDH step, our only recourse would be to restart the coin selection process and ensure we get different inputs.

[vostrnad]

I don't think we should get a failure by doing additions and multiplications (summing priv keys, pub keys, ecdh)

One reason EC operations can fail is when a pseudorandom scalar value exceeds the curve order, which should only happen with negligible probability but other BIPs still have special cases for when it happens (e.g. BIP32, BIP340 and BIP341). I suppose it could be fine to ignore this, but I'm certainly no expert either.

[josibake]

I don't think we should get a failure by doing additions and multiplications (summing priv keys, pub keys, ecdh)

One reason EC operations can fail is when a pseudorandom scalar value exceeds the curve order, which should only happen with negligible probability but other BIPs still have special cases for when it happens (e.g. BIP32, BIP340 and BIP341). I suppose it could be fine to ignore this, but I'm certainly no expert either.

I'll take a look to see how it's being handled in those BIPs. Ideally, we can reuse the same solution here. The main thing is ensuring both the sender and receiver can deterministically handle these low-probability events.

[kallewoof]

@luke-jr Unless you see anything objectionable, please assign BIP number.

[josibake]

@vostrnad

One reason EC operations can fail is when a pseudorandom scalar value exceeds the curve order, which should only happen with negligible probability but other BIPs still have special cases for when it happens (e.g. BIP32, BIP340 and BIP341). I suppose it could be fine to ignore this, but I'm certainly no expert either.

I did some more reading on this and from what I can tell this applies to choosing a scalar which results in a valid point on the curve, which is not true for every scalar. In our case, we are already using existing valid private keys or, in the case of the silent payment address, are using BIP32 to generate them. Adding these keys together (using the elliptic curve group operation) or multiplying a valid scalar with a point (ECDH) gives us a result that is guaranteed to be a valid point on the curve.

[josibake]

Given that there is at least one implementation of your BIP already, I was wondering whether you have considered advancing it’s status to "Proposed".

Updated to Proposed. Thanks for the review @murchandamus , RFM!

[junderw]

@josibake When thinking about potential APIs for BitcoinJS with SP, the concept of PSBTs doesn't seem to work well with SP at all. It almost precludes the tx creation, signing, and finalizing MUST be done on the same device in one go.

I think the SP BIP should at least mention that PSBT use should be avoided in the case of fully unsigned PSBTs or only has signatures that are SIGHASH_ANYONECANPAY. Since someone could easily modify the input set.

In the long run, SP will require a few upgrades to PSBT one of which is backwards incompatible.

1. Add an output data field containing SP data. I think this might require the scan-private-key, otherwise the finalizer can't double check the validity of the output scriptPubkey.
2. (Backwards incompatible) Update the PSBT version field and add the rule that "When finalizing the last input, finalizers MUST verify the scriptPubkey of EVERY output with silent payment output data before finalizing."

There are a lot of use cases for PSBT which would be dangerous to use with SP and some loose non-required "conventions."

I would be interested to hear your thoughts. I don't have a clear change proposal so I couldn't think of a PR to make, so excuse my reviving a dead PR.

[josibake]

Hey @junderw , we are discussing PSBT proposals on delving bitcoin and @andrewtoth has already started a draft BIP. It would be great to have your input over there!

Regarding updates to this BIP, I think it would be more appropriate to finalize a silent payments PSBT BIP and then link to that BIP here. If we do end up needing a PSBTv3 for supporting silent payments, then we should definitely mention incompatibility with older PSBT versions here and point to the new PSBTv3 proposal.

[jonatack]

@josibake @RubenSomsen Any plans to update this BIP per the discussion in libsecp? For instance, bitcoin-core/secp256k1#1765 (comment).

[jonatack]

@josibake @RubenSomsen Any plans to update this BIP per the discussion in libsecp? For instance, bitcoin-core/secp256k1#1765 (comment).

Looks like #2055 is one step.

[furszy]

@josibake @RubenSomsen Any plans to update this BIP per the discussion in libsecp? For instance, bitcoin-core/secp256k1#1765 (comment).

Looks like #2055 is one step.

@jonatack #2055 is not related to #1458 (comment). The first one you mentioned requires an API workflow modification while the second one (#2055) is just a minimal data type change. The API change is still being benchmarked and discussed and is not ready yet.

[jonatack]

@furszy thanks for the clarification!