BIP375: Sending Silent Payments in PSBTs #1687

pull andrewtoth wants to merge 12 commits into bitcoin:master from andrewtoth:silent-payments-psbt changing 3 files +337 −3
  1. andrewtoth commented at 12:39 pm on October 17, 2024: contributor

    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 is specified in BIP374. 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.

  2. murchandamus added the label New BIP on Oct 17, 2024
  3. jonatack commented at 8:26 pm on October 18, 2024: member
  4. andrewtoth force-pushed on Oct 19, 2024
  5. andrewtoth force-pushed on Oct 19, 2024
  6. andrewtoth force-pushed on Oct 21, 2024
  7. in bip-PSBT-SP.mediawiki:63 in e2adb50e77 outdated
    58+| An ECDH share for a scan key, followed by a list of outpoints. The ECDH shared is computed with ''a * B_scan'', where ''a'' is the sum of all private keys of the inputs matching the list of outpoints, and ''B_scan'' is the scan key of a recipient.
    59+|
    60+| 0
    61+| 2
    62+|-
    63+| Silent Payment Global DLEQ Proof
    


    jonatack commented at 10:25 pm on October 24, 2024:
    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.

    andrewtoth commented at 8:47 pm on December 31, 2024:
    I link to BIP374 and added it as a dependency as well.
  8. in bip-PSBT-SP.mediawiki:58 in e2adb50e77 outdated
    53+| Silent Payment Global ECDH Share
    54+| <tt>PSBT_GLOBAL_SP_ECDH_SHARE = 0x07</tt>
    55+| <tt><33 byte scan key> <36 byte outpoint>*</tt>
    56+| The scan key and a list of outpoints corresponding to the prevouts of the inputs that this ECDH share is for. The outpoints are composed of a 32 byte txid followed by a 32-bit little endian uint.
    57+| <tt><32 byte share></tt>
    58+| An ECDH share for a scan key, followed by a list of outpoints. The ECDH shared is computed with ''a * B_scan'', where ''a'' is the sum of all private keys of the inputs matching the list of outpoints, and ''B_scan'' is the scan key of a recipient.
    


    theStack commented at 6:07 pm on October 28, 2024:
    as already noted in the DLEQ gist, this should have a size of 33 bytes instead, as it represents a point on the curve (https://gist.github.com/andrewtoth/df97c3260cc8d12f09d3855ee61322ea?permalink_comment_id=5250407#gistcomment-5250407), and representing it as x-only very likely only increases complexity for the DLEQ proof.

    andrewtoth commented at 1:23 am on December 24, 2024:
    Done.
  9. in bip-PSBT-SP.mediawiki:21 in e2adb50e77 outdated
    16+==Introduction==
    17+
    18+===Abstract===
    19+
    20+This document proposes additional fields and updated role responsibilities for BIP 370 PSBTv2
    21+which adds support for sending to silent payments as described in BIP352.
    


    murchandamus commented at 7:49 pm on November 12, 2024:
    Consistency nit: “BIP 370”, but “BIP352”

    andrewtoth commented at 1:22 am on December 24, 2024:
    Done.
  10. in bip-PSBT-SP.mediawiki:30 in e2adb50e77 outdated
    25+This BIP is licensed under the 2-clause BSD license.
    26+
    27+===Motivation===
    28+
    29+Partially Signed Bitcoin Transaction Version 2 as described in BIP 370 is not compatible with sending to silent payments as described in BIP352. In particular, the output script of a silent payment cannot be computed until after all transaction inputs have been added.
    30+Also, any inputs that the Signer has the private keys for must be signed with SIGHASH_ALL and all inputs must not have any scriptPubKeys with Segwit version > 1.
    


    murchandamus commented at 7:55 pm on November 12, 2024:
    What creates the requirement to sign with SIGHASH_ALL? A quick check suggests that BIP 352 only recommends it, but doesn’t require it, and BIP 370 doesn’t seem to impose such a requirement. I might have missed something of course.

    nothingmuch commented at 6:53 pm on November 15, 2024:
    I had the same question. The rationale in BIP 352 seems to imply that just forbidding ANYONECANPAY, i.e. that all signatures must fully commit to the input set, which seems sufficient even the PSBT setting?

    andrewtoth commented at 7:20 pm on November 17, 2024:

    Signing with SIGHASH_NONE doesn’t make sense because you will have to generate the ECDH shares for all payments, but they could then be removed or new ones added. So you will have to go back to the signer again. I suppose technically this could be allowed but I don’t see a use for it, and it could be used by a griefer to force the party to keep going back to the signer. If you want to have a signer sign all non-eligible inputs with SIGHASH_NONE, give the signer the inputs before adding any silent payment outputs. It would then fall back to BIP 370. Signing with SIGHASH_SINGLE would allow another participant to add a payment to the same scan key, but a lower lexicographic order, invalidating the k value in the output script. Signing with SIGHASH_ANYONECANPAY is unsafe as per BIP 352.

    I suppose I could add this as a footnote. But also, I don’t think this sentence should be in the motivation section.


    andrewtoth commented at 1:22 am on December 24, 2024:
    Removed the sentence, but also added a footnote in the Signer section to clarify why.
  11. in bip-PSBT-SP.mediawiki:31 in e2adb50e77 outdated
    26+
    27+===Motivation===
    28+
    29+Partially Signed Bitcoin Transaction Version 2 as described in BIP 370 is not compatible with sending to silent payments as described in BIP352. In particular, the output script of a silent payment cannot be computed until after all transaction inputs have been added.
    30+Also, any inputs that the Signer has the private keys for must be signed with SIGHASH_ALL and all inputs must not have any scriptPubKeys with Segwit version > 1.
    31+Additionally, the silent payment outputs computed by a signer must be verifiable to other entities.
    


    murchandamus commented at 7:56 pm on November 12, 2024:
    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 commented at 7:32 pm on November 17, 2024:

    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.

  12. in bip-PSBT-SP.mediawiki:38 in e2adb50e77 outdated
    33+
    34+==Specification==
    35+
    36+This document specifies new fields and new field inclusion/exclusion requirements.
    37+
    38+<tt>PSBT_OUT_SCRIPT</tt> is modified to be optional for outputs in silent payments capable PSBTs. If this field is not included in the output, then the field PSBT_OUT_SP_V0_INFO must be included.
    


    murchandamus commented at 8:01 pm on November 12, 2024:

    Does it make sense to require the presence of either PSBT_OUT_SCRIPT or PSBT_OUT_SP_V0_INFO? What if there is another future extension of BIP 370 that provides a third option?

    Would it perhaps be sufficient to declare an output that has both the fields PSBT_OUT_SCRIPT and PSBT_OUT_SP_V0_INFO to make the PSBT invalid (i.e. at most one of these two can be present)?

    Perhaps the interplay of these two fields could be elaborated.


    andrewtoth commented at 7:40 pm on November 17, 2024:

    I don’t think making these fields exclusive will work. The PSBT_OUT_SCRIPT must be added to sign the PSBT. The PSBT_OUT_SP_V0_INFO must be present to verify that the PSBT_OUT_SCRIPT is actually correct after it is added.

    What if there is another future extension of BIP 370 that provides a third option?

    That would indeed soften this requirement. This BIP would have to be modified to support that extension, making it

    If either PSBT_OUT_SCRIPT or PSBT_OUT_NEW_EXTENSION are not included in the output, then the field PSBT_OUT_SP_V0_INFO must be included.

    I don’t really have an idea on how this could be made more graceful for that scenario.

    Perhaps the interplay of these two fields could be elaborated.

    I will add some more context in a footnote, thanks.


    andrewtoth commented at 1:21 am on December 24, 2024:
    Clarified this section and added a footnote.
  13. in bip-PSBT-SP.mediawiki:100 in e2adb50e77 outdated
     95+| 2
     96+|}
     97+
     98+===Unique Identification===
     99+
    100+Silent payment capable PSBTs can be uniquely identified the same way as PSBTv2s, except when including silent payment outputs. For silent payment capable PSBTs, all silent payment outputs must use the PSBT_OUT_SP_V0_INFO instead of PSBT_OUT_SCRIPT as the output script when creating the unsigned transaction used for unique identification.
    


    murchandamus commented at 8:09 pm on November 12, 2024:
    I found this sentence confusing. Does this also hold if both PSBT_OUT_SP_V0_INFO and PSBT_OUT_SCRIPT are specified on an output?

    andrewtoth commented at 7:42 pm on November 17, 2024:
    No, it does not hold once PSBT_OUT_SCRIPT is added to an output. Only outputs without that field would need to fall back to PSBT_OUT_SP_V0_INFO. I will clarify this in the text.

    andrewtoth commented at 1:21 am on December 24, 2024:
    I was incorrect. This does also hold if both are specified. I updated this section and added a footnote for the reasoning.
  14. in bip-PSBT-SP.mediawiki:109 in e2adb50e77 outdated
    104+This document modifies some existing roles.
    105+
    106+===Constructor===
    107+
    108+All rules must be followed from PSBTv2 for this role, with the following exception:
    109+When an output is added, it must have either PSBT_OUT_SCRIPT or PSBT_OUT_SP_V0_INFO, or both, set.
    


    murchandamus commented at 8:10 pm on November 12, 2024:
    I only understood here that both of these fields can be set at the same time. Perhaps that could be explained above where PSBT_OUT_SP_V0_INFO is first introduced.

    andrewtoth commented at 1:21 am on December 24, 2024:
    Added more context above.
  15. in bip-PSBT-SP.mediawiki:114 in e2adb50e77 outdated
    109+When an output is added, it must have either PSBT_OUT_SCRIPT or PSBT_OUT_SP_V0_INFO, or both, set.
    110+
    111+Additionally to PSBTv2, the Constructor must also follow additional rules:
    112+
    113+Inputs spending an output with script using Segwit version > 1 may only be added if there are no outputs with PSBT_OUT_SP_V0_INFO set.
    114+Outputs with PSBT_OUT_SP_V0_INFO set may only be added if there are no inputs spending an output script using Segwit version > 1.
    


    murchandamus commented at 8:18 pm on November 12, 2024:
    This might be a bit out of scope for your PR, but I was just wondering: Silent Payment transactions disallow inputs spending native segwit outputs with version > 1, but should it perhaps also exclude native segwit outputs with version 1 that are not P2TR inputs? Most of version 1 is yet unencumbered, are Silent Payments robust in regard to Pay to Anchor?

    andrewtoth commented at 7:49 pm on November 17, 2024:

    I believe BIP 352 specifies that only the script template OP_1 <32 bytes> is used, and not that it is segwit v1. So, P2A does not follow that template, and will be ignored. But, segwit versions higher than v1 specifically are prohibited for forward compatibility reasons.

    This is what I understood from @josibake’s explanation.

  16. in bip-PSBT-SP.mediawiki:133 in e2adb50e77 outdated
    128+
    129+If any output does not have PSBT_OUT_SCRIPT set, the Signer must not yet add a signature.
    130+
    131+The Signer should additionally compute the silent payment addresses, optionally showing this data to the user instead of the computed segwit v1 addresses.
    132+
    133+If a sighash type is provided and there are silent payment outputs present, the signer must fail if the sighash type is not SIGHASH_ALL.
    


    murchandamus commented at 8:20 pm on November 12, 2024:
    As mentioned above, this seems to be stricter than BIP 352 itself. Is this intentional?

    andrewtoth commented at 7:54 pm on November 17, 2024:
    This is intentional. SIGHASH_SINGLE is unsafe for k values. SIGHASH_NONE does not make sense since you will have to compute ECDH shares for the outputs, but you presumably don’t care about the outputs if you are signing with that flag.

    andrewtoth commented at 1:20 am on December 24, 2024:
    Added a footnote to clarify this.
  17. in bip-PSBT-SP.mediawiki:148 in e2adb50e77 outdated
    143+
    144+* Let ''A<sub>n</sub>'' be the sum of the public keys ''A'' of all eligible inputs
    145+* Let ''a<sub>n</sub>'' be the sum of the private keys ''a'' of all eligible inputs
    146+* Let ''C =  a<sub>n</sub>·B<sub>scan</sub>''
    147+
    148+Use a key ''B<sub>scan</sub>'' followed by a list of the outpoints of all eligible inputs.
    


    murchandamus commented at 8:27 pm on November 12, 2024:
    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 commented at 7:56 pm on November 17, 2024:
    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 commented at 1:31 am on December 24, 2024:
    See my comment here.
  18. in bip-PSBT-SP.mediawiki:167 in e2adb50e77 outdated
    162+If there are multiple silent payment codes with the same scan key, sort the codes lexicographically in ascending order to determine the ordering of the ''k'' value.
    163+If there are multiple silent payment codes with both the same scan and spend keys, sort the subgroup by output index in ascending order.
    164+
    165+====Change Detection====
    166+
    167+Updaters may add two PSBT_OUT_BIP32_DERIVATION key-value-pairs with the corresponding derivation path of both the scan and spend keys. The Signer can then use these fields to verify that the silent payment code is change.
    


    murchandamus commented at 8:34 pm on November 12, 2024:
    Should the “Updater” role perhaps appear before the “Signer”? Adding change would probably happen at the same time participants add inputs, so surely before signing?

    andrewtoth commented at 1:20 am on December 24, 2024:
    Done.
  19. in bip-PSBT-SP.mediawiki:13 in e2adb50e77 outdated
     8+  Comments-Summary: No comments yet.
     9+  Comments-URI: TBD
    10+  Status: Draft
    11+  Type: Standards Track
    12+  Created: 2024-05-14
    13+  License: BSD-2-Clause
    


    murchandamus commented at 8:40 pm on November 12, 2024:
    0  License: BSD-2-Clause
    1  Post-History: https://groups.google.com/g/bitcoindev/c/5G5wzqUXyk4
    2  Requires: 352, 370
    

    andrewtoth commented at 1:20 am on December 24, 2024:
    Done.
  20. murchandamus commented at 8:43 pm on November 12, 2024: contributor

    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.

  21. in bip-PSBT-SP.mediawiki:125 in e2adb50e77 outdated
    120+If any input is spending an output with script using Segwit version > 1, the Signer must fail.
    121+
    122+For all outputs with PSBT_OUT_SP_V0_INFO set, the Signer should:
    123+ - Compute and set an ECDH share and DLEQ proof using all inputs it has the private key for.
    124+ - Verify the DLEQ proofs for all inputs it does not have the private keys for.
    125+ - If all eligible inputs have an ECDH share, compute and set the PSBT_OUT_SCRIPT.
    


    nothingmuch commented at 7:03 pm on November 15, 2024:
    0* Compute and set an ECDH share and DLEQ proof using all inputs it has the private key for.
    1* Verify the DLEQ proofs for all inputs it does not have the private keys for.
    2* If all eligible inputs have an ECDH share, compute and set the PSBT_OUT_SCRIPT.
    
  22. in bip-PSBT-SP.mediawiki:55 in e2adb50e77 outdated
    50+! Versions Requiring Exclusion
    51+! Versions Allowing Inclusion
    52+|-
    53+| Silent Payment Global ECDH Share
    54+| <tt>PSBT_GLOBAL_SP_ECDH_SHARE = 0x07</tt>
    55+| <tt><33 byte scan key> <36 byte outpoint>*</tt>
    


    nothingmuch commented at 7:47 pm on November 15, 2024:

    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 commented at 8:25 pm on November 17, 2024:

    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 commented at 7:22 pm on December 9, 2024:
    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 commented at 1:30 am on December 24, 2024:

    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 commented at 5:24 pm on December 28, 2024:

    that seems very reasonable to me.

    even there might be some scenarios in subsets still make sense that seems like a corner case, if it’s really important enough an extension to this BIP could always be specified later

  23. in bip-PSBT-SP.mediawiki:68 in e2adb50e77 outdated
    63+| Silent Payment Global DLEQ Proof
    64+| <tt>PSBT_GLOBAL_SP_DLEQ = 0x08</tt>
    65+| <tt><33 byte scan key> <36 byte outpoint>*</tt>
    66+| The scan key and a list of outpoints corresponding to the prevouts of the inputs that this proof covers. The outpoints are composed of a 32 byte txid followed by a 32-bit little endian uint.
    67+| <tt><64-byte proof></tt>
    68+| A DLEQ proof computed for the matching ECDH share.
    


    nothingmuch commented at 7:57 pm on November 15, 2024:
    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 commented at 8:36 pm on November 17, 2024:

    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 commented at 11:46 pm on November 17, 2024:

    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 commented at 9:42 pm on November 18, 2024:

    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.


    andrewtoth commented at 8:47 pm on December 31, 2024:
    I’m not sure the added complexity is worth it to add this.
  24. in bip-PSBT-SP.mediawiki:129 in e2adb50e77 outdated
    124+ - Verify the DLEQ proofs for all inputs it does not have the private keys for.
    125+ - If all eligible inputs have an ECDH share, compute and set the PSBT_OUT_SCRIPT.
    126+
    127+If the Signer sets any missing PSBT_OUT_SCRIPTs, it must set the Inputs Modifiable flag to False.
    128+
    129+If any output does not have PSBT_OUT_SCRIPT set, the Signer must not yet add a signature.
    


    nothingmuch commented at 8:34 pm on November 15, 2024:

    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 commented at 11:50 pm on December 9, 2024:

    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.

  25. in bip-PSBT-SP.mediawiki:161 in e2adb50e77 outdated
    156+
    157+For each output with PSBT_OUT_SP_V0_INFO set, the Signer should verify the ECDH shares for all eligible inputs it does not have the private key for using the proofs provided by other Signers.
    158+
    159+====Computing the Output Scripts====
    160+
    161+Compute the PSBT_OUT_SCRIPT using the procedure in [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#user-content-Creating_outputs BIP352] but substituting ''a·B<sub>scan</sub>'' with the sum of all PSBT_GLOBAL_SP_ECDH_SHAREs for that scan key.
    


    nothingmuch commented at 8:44 pm on November 15, 2024:
    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.
  26. nothingmuch changes_requested
  27. nothingmuch commented at 8:58 pm on November 15, 2024: contributor

    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.

  28. murchandamus added the label PR Author action required on Nov 15, 2024
  29. murchandamus removed the label PR Author action required on Dec 26, 2024
  30. in bip-PSBT-SP.mediawiki:88 in c9589c588b outdated
    83+! Versions Requiring Inclusion
    84+! Versions Requiring Exclusion
    85+! Versions Allowing Inclusion
    86+|-
    87+| Silent Payment Data
    88+| <tt>PSBT_OUT_SP_V0_INFO = 0x08</tt>
    


    guggero commented at 4:18 pm on December 28, 2024:
    Just a drive-by comment that this value is now taken by PSBT_OUT_MUSIG2_PARTICIPANT_PUBKEYS which was added by #1540.
  31. in bip-PSBT-SP.mediawiki:58 in c9589c588b outdated
    53+| Silent Payment Global ECDH Share
    54+| <tt>PSBT_GLOBAL_SP_ECDH_SHARE = 0x07</tt>
    55+| <tt><33 byte scan key> <36 byte outpoint>*</tt>
    56+| The scan key and a list of outpoints corresponding to the prevouts of the inputs that this ECDH share is for. The outpoints are composed of a 32 byte txid followed by a 32-bit little endian uint.
    57+| <tt><33 byte share></tt>
    58+| An ECDH share for a scan key, followed by a list of outpoints. The ECDH shared is computed with ''a * B_scan'', where ''a'' is the sum of all private keys of the inputs matching the list of outpoints, and ''B_scan'' is the scan key of a recipient.
    


    guggero commented at 2:20 pm on December 29, 2024:
    I have an implementation question about this. If all the shares are a * B_scan, then how can the last signer (or the transaction extractor) calculate the output key? BIP-0352 mentions input_hash = hash_BIP0352/Inputs(outpointL || A), but how would I extract A from the shares? Is it as simple as subtracting B_scan from the share?

    guggero commented at 2:50 pm on December 29, 2024:
    Ah, I guess a PSBT is supposed to contain all BIP-32 derivation information for all inputs. So A can be derived from the sum of all public keys. Is that correct? Then perhaps that could be mentioned here.

    andrewtoth commented at 2:59 pm on December 29, 2024:

    how would I extract A from the shares?

    A in the context of the input_hash is a*G, or the sum of all public keys. This might be easier to understand from the receiver side https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#scanning.


    andrewtoth commented at 3:02 pm on December 29, 2024:

    a PSBT is supposed to contain all BIP-32 derivation information for all inputs

    I’m not sure I follow why we need BIP-32 derivation information? The public keys can be extracted from the prevout scripts of the inputs. https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#inputs-for-shared-secret-derivation


    andrewtoth commented at 3:06 pm on December 29, 2024:

    I think I understand, for output generation:

    Let ecdh_shared_secret = input_hash·a·Bscan

    replace a·Bscan with the ECDH share.

    This is detailed here.


    guggero commented at 4:32 pm on December 29, 2024:

    Yes, I understand that I need to replace a·B_scan with the ECDH share. But how do I calculate the input_hash? For that I need the bare A. And when creating the output keys, there is no witness available yet from which I can extract the public keys (for example with a p2wkh input where we only have the public key hash in the prevout script).

    So I think in a scenario where there are multiple signers, then the last signer that wants to create the output keys will need to have the BIP-32 derivation info available for non-Taproot inputs. Nothing can be signed at that point (e.g. no witness available), since the output keys aren’t known yet.


    andrewtoth commented at 5:29 pm on December 29, 2024:
    Ah I understand now. Other signers will not have the public keys without the witness or scriptSig. I’m still not clear why BIP-32 derivation is needed. There is the BIP-174 input field PSBT_IN_HASH160 that can store the preimage that has the public key. I think the spec should be updated to have the updater add this field for any non-Taproot inputs. Does that make sense?

    guggero commented at 10:28 am on December 31, 2024:
    True, the PSBT_IN_HASH160 should probably work as well. I just haven’t seen this field being set “in the wild” up to now, so not sure if all wallets will set it correctly (at least lnd doesn’t, which perhaps means it’s not fully BIP-0174 compliant?). So I thought the public key in the BIP-32 derivation fields is probably more likely to be set in most wallets. But perhaps this BIP doesn’t have to go into details around that and can just mention something along the lines of: “Signers creating the output keys will not be able to extract public keys from the witness as at that point the inputs aren’t signed yet. The meta information present in the PSBT should include the public key of each input though, so creating the sum of all input public keys (A) should happen based on that information”.

    andrewtoth commented at 3:09 pm on December 31, 2024:

    But perhaps this BIP doesn’t have to go into details around that

    Hmm I’m not sure that’s a good idea to leave that unspecified. Different implementations could then depend on different metadata fields that may or may not be set and be incompatible. The purpose of a standard is to avoid that problem.

    If it’s easier we can use the BIP-32 derivation field since I see PSBT_IN_HASH160 is not implemented in https://github.com/bitcoinjs/bip174 either. The difference is that the value of that field should be set to a fingerprint and derivation path which some signers might not want to share. We can specify in this document to set this field for non-taproot sp eligible inputs, and a zero fingerprint and empty path array for the value.

  32. guggero commented at 2:30 pm on December 29, 2024: contributor
    One question about calculating the output keys, other than that this looks good.
  33. andrewtoth commented at 8:45 pm on December 31, 2024: contributor

    @murchandamus @jonatack @nothingmuch @guggero @theStack thank you all for your reviews.

    • Updated the spec to have either per-input or global ECDH shares and DLEQ proofs, instead of using subsets.
    • Specified using BIP374 to compute and verify DLEQ proofs.
    • Suggest adding BIP32 derivation paths for pubkey hashed inputs, so the public key is available before the witness or scriptSig is added.
    • Updated output key due to conflict with #1540.
    • Added silent payment label output type for computing change.
  34. guggero approved
  35. guggero commented at 8:36 am on January 8, 2025: contributor
    ACK 3bfecc3d5d37b1dc77bbd6a139d61adeb1da1664.
  36. in bip-PSBT-SP.mediawiki:2 in 3bfecc3d5d outdated
    0@@ -0,0 +1,262 @@
    1+<pre>
    2+  BIP: ?
    


    jonatack commented at 6:05 pm on January 8, 2025:
    Please update here with 375, add an equivalent README entry, and update the Created field to today’s date.
  37. jonatack commented at 6:07 pm on January 8, 2025: member
    Assigned 375.
  38. jonatack renamed this:
    Bip Draft: Sending Silent Payments in PSBTs
    BIP375: Sending Silent Payments in PSBTs
    on Jan 8, 2025
  39. bitcoin deleted a comment on Jan 8, 2025
  40. Bip Draft: Sending Silent Payments in PSBTs d02eed4337
  41. Update bip-PSBT-SP.mediawiki
    Co-authored-by: Yuval Kogman <nothingmuch@woobling.org>
    eb115afa7f
  42. Update size of ECDH share and unify spacing 8e90f02dc5
  43. Add post history and BIP dependencies f746ae700f
  44. Clarify motivation 0d5e14ce19
  45. Move updater to before signer c12ea5ac58
  46. Clarify output script and sp info mutual exclusion and unique id d29e2f81af
  47. Add newline 9952599f32
  48. Add ref for why sighash_all is required 651ffdded8
  49. Split up shares and proofs into global or per input fields 4a7a7cf746
  50. Update to BIP375 144c4a3a15
  51. andrewtoth force-pushed on Jan 13, 2025
  52. Update fields in bip174 eb10cdb4ce
  53. andrewtoth force-pushed on Jan 13, 2025
  54. in bip-0375.mediawiki:30 in eb10cdb4ce
    25+
    26+This BIP is licensed under the 2-clause BSD license.
    27+
    28+===Motivation===
    29+
    30+Partially Signed Bitcoin Transaction Version 2 as described in BIP370 is not compatible with sending to silent payments as described in BIP352. 
    


    jonatack commented at 8:21 pm on January 13, 2025:
    0Partially Signed Bitcoin Transaction Version 2 as described in BIP370 is not compatible with sending to silent payments as described in BIP352.
    

    Sjors commented at 10:04 am on January 20, 2025:

    This sentence is ambiguous. It makes the reader (or at least me) expect that this BIP introduces version 3. There’s two things happening IIUC:

    1. The BIP introduces new PSBT fields for Silent Payments
    2. Silent Payments by their nature require PSBT version >= 2
  55. in bip-0375.mediawiki:32 in eb10cdb4ce
    27+
    28+===Motivation===
    29+
    30+Partially Signed Bitcoin Transaction Version 2 as described in BIP370 is not compatible with sending to silent payments as described in BIP352. 
    31+In particular, the output script of a silent payment cannot be computed until after all transaction inputs have been added.
    32+Additionally, the silent payment outputs computed by a signer must be verifiable by other entities, otherwise funds could be sent to an incorrect output script.
    


    jonatack commented at 8:23 pm on January 13, 2025:

    nit

    0Additionally, the silent payment outputs computed by a signer must be verifiable by other entities; otherwise, funds could be sent to an incorrect output script.
    
  56. in bip-0375.mediawiki:4 in eb10cdb4ce
    0@@ -0,0 +1,261 @@
    1+<pre>
    2+  BIP: 375
    3+  Layer: Applications
    4+  Title: Sending Silent Payments with PSBTs
    


    jonatack commented at 8:38 pm on January 13, 2025:

    Question: would this title be better?

    0  Title: Sending Silent Payments with PSBT Version 2
    

    Sjors commented at 10:02 am on January 20, 2025:
    I wouldn’t rename the title, but instead in the introduction clarify that the minimum PSBT version is 2.
  57. in bip-0375.mediawiki:261 in eb10cdb4ce
    256+
    257+<references/>
    258+
    259+==Reference implementation==
    260+
    261+Todo
    


    jonatack commented at 8:44 pm on January 13, 2025:
    Note that the reference implementation must be completed before this BIP can progress to Final status.
  58. jonatack commented at 8:50 pm on January 13, 2025: member

    ACK eb10cdb4cebd05c02fc1f6da93a59ddd4091c793

    BIP looks sufficiently complete for draft status, notwithstanding future updates.

  59. jonatack merged this on Jan 13, 2025
  60. jonatack closed this on Jan 13, 2025

  61. in bip-0375.mediawiki:200 in eb10cdb4ce
    195+
    196+For each output with PSBT_OUT_SP_V0_INFO set, the Signer may generate a proof for other entities to generate the output scripts and verify that the output scripts were generated correctly.
    197+
    198+If the Signer has the private keys for all eligible inputs, the Signer should generate a global ECDH share for each scan key ''B<sub>scan</sub>'' as follows:
    199+
    200+Using the notation from [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#specification BIP352]
    


    jonatack commented at 9:00 pm on January 13, 2025:

    nano-nit, the other “Using the natation from BIP352” sentence ends with a colon

    0Using the notation from [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#specification BIP352]:
    
  62. andrewtoth deleted the branch on Jan 13, 2025

github-metadata-mirror

This is a metadata mirror of the GitHub repository bitcoin/bips. This site is not affiliated with GitHub. Content is generated from a GitHub metadata backup.
generated: 2025-01-21 07:10 UTC

This site is hosted by @0xB10C
More mirrored repositories can be found on mirror.b10c.me