From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Thu, 17 Oct 2024 07:52:38 -0700 Received: from mail-yb1-f188.google.com ([209.85.219.188]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1t1Rrh-0005dB-JL for bitcoindev@gnusha.org; Thu, 17 Oct 2024 07:52:38 -0700 Received: by mail-yb1-f188.google.com with SMTP id 3f1490d57ef6-e29205f6063sf1376071276.1 for ; Thu, 17 Oct 2024 07:52:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1729176751; x=1729781551; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:sender:from:to:cc:subject:date :message-id:reply-to; bh=K1kECCCXiAhcg+6hLMnODUmyKiWhhHuZc6BuM4MTzEY=; b=bk73iq/GKTYme+4jX3XbtIlJH0uF9pv4HT/pHAqI/EG7w1bxvUhrstIGOXsEegntRH UfsWqrqxLn/aL6UCvKdNfAW8ai/S3r0wO3KRzDO9+mwWiH/f9RJD9XGkJCxthNW3erGF 6KuICdWRCnR/okw5zxgx9wTgs06d2MbxyrKJcLqgEafVJ3MbLLqxIupD6MtiLwaH7YYb vH175xgzYq2lsOHJCLyM7ZIxqbFqeNED3z815PPW0BguDCCT5nG8gxHL4xcBtD5usKfz syJXkqvHWvEBxmlQWEGEMmKmybs/8+H4oFrt1FNfIDtLA3mf2kiOmf3VX3bw0BS31Ohq mOSQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1729176751; x=1729781551; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:from:to:cc:subject:date:message-id :reply-to; bh=K1kECCCXiAhcg+6hLMnODUmyKiWhhHuZc6BuM4MTzEY=; b=BwebJOgmZCTV2FjW8qgEj23JKpRBdNpxxFlY2txO8hO6NjPZkyLC0NIeZx62EQ9Xf8 VQahs0bNjOWzfW3X4v9fOzM8B+9+f2iTbZviEikOn4dlcnn4N0JFbdSvRXAikVUWlVAu 6ZBUhzqhK21xDrWghEGOM/T3G4HQNgWSuE6THv8GyVtqx94u4U5zQaqlHdh7lv3n6uwa zASmREw+OARtfMk2MeWbwxWrzPQxVuUFMir4hyglowzctv0/h2zp4QQkBq8N1jADFYnj jVG5waBWZf6PJccG45hVWX3I24wsEuNoaSOgySR6zs81iIByGfamogImymIzKKWmJda8 WenA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1729176751; x=1729781551; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-sender:mime-version :subject:message-id:to:from:date:x-beenthere:x-gm-message-state :sender:from:to:cc:subject:date:message-id:reply-to; bh=K1kECCCXiAhcg+6hLMnODUmyKiWhhHuZc6BuM4MTzEY=; b=iD5Y3q2i143GZRfTRcw6z3FBz8B0kA0Ry7NV9Bf30ZzATmMzSBFmyHbRVpBAda8obE RyWSLkGvYKJvwBv/7imnyEVrZ222fiCKsSnlJ3cl87sWHiku12fwP+jBOBd4shUnCrQf N2viY1jNCd8gl80JMlcmoocY3dTDE1+cTnNchEqeXyDXANUkZE/D8GRQtxDxtPqwROyT lniJrXf68m0rT1ju7dhBYfs1RUpNomfdZOSVfFrftDV+EF3Svjp+huXj1aJKYQ6WA7k4 i822TSwaCJ+Zyyr+RgWpTP1g0Bk6SSVVGInvHyx04rKb9voBqu9j2qjDnJdtr1pqjOuN iopg== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=1; AJvYcCVXxCiXtMAvhYbEkOm4w+vbYVE8Py26BYKY+nNd6uAMd9n/UVUGsDRzyUhxMsYz6dZM/QjHuNWiM+dm@gnusha.org X-Gm-Message-State: AOJu0YzghsRuwrKFM9NKG2RWmZGzY+2TdduffHUg+DhBDQGbNLm6LkUF rJHMAyTKp0UpX/DwSYxdHO3g217lmZtCWtLySH1EWqGVwRCu2Aul X-Google-Smtp-Source: AGHT+IGT/kCuvm+3qa4rV5UtyCoQ64qSQnQMaungYfCKH/E0oBGEEZXTPkPy3HhOWidwhM4GyGP6xg== X-Received: by 2002:a05:6902:2188:b0:e28:ea88:bacd with SMTP id 3f1490d57ef6-e2931b5ddc0mr15875025276.34.1729176751287; Thu, 17 Oct 2024 07:52:31 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6902:18c2:b0:e20:265d:ca25 with SMTP id 3f1490d57ef6-e2b9cc53f07ls651287276.0.-pod-prod-08-us; Thu, 17 Oct 2024 07:52:29 -0700 (PDT) X-Received: by 2002:a05:690c:9b0e:b0:6db:cf6c:a7c4 with SMTP id 00721157ae682-6e3d41f9b66mr72594707b3.45.1729176748963; Thu, 17 Oct 2024 07:52:28 -0700 (PDT) Received: by 2002:a81:fa0f:0:b0:6e3:65a1:402f with SMTP id 00721157ae682-6e3d72b08ffms7b3; Thu, 17 Oct 2024 06:40:04 -0700 (PDT) X-Received: by 2002:a05:690c:660a:b0:6e2:1467:17c0 with SMTP id 00721157ae682-6e3d408242dmr69882147b3.8.1729172403592; Thu, 17 Oct 2024 06:40:03 -0700 (PDT) Date: Thu, 17 Oct 2024 06:40:03 -0700 (PDT) From: Andrew Toth To: Bitcoin Development Mailing List Message-Id: Subject: [bitcoindev] BIP: Sending Silent Payments in PSBTs MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_32964_605053494.1729172403097" X-Original-Sender: andrewstoth@gmail.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.5 (/) ------=_Part_32964_605053494.1729172403097 Content-Type: multipart/alternative; boundary="----=_Part_32965_354279448.1729172403097" ------=_Part_32965_354279448.1729172403097 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This BIP adds support for sending silent payments using PSBTs. If there are multiple entities handling the PSBT that do not have access to= =20 some input private keys, a DLEQ proof by the signer may be added for other= =20 entities to verify the corresponding ECDH shares used to derive the output= =20 scripts were generated correctly. This will be specified in a following=20 BIP. For the common case of a single entity that has access to all private= =20 keys, the DLEQ proof generation is unnecessary. Spending support is trivial and can be done with a modification to BIP370= =20 to add a new input field for the tweak data. Any feedback appreciated, thank you. 
  BIP: ?
  Layer: Applications
  Title: Sending Silent Payments with PSBTs
  Author: Andrew Toth 
          Ava Chow 
          josibake 
  Comments-Summary: No comments yet.
  Comments-URI: TBD
  Status: Draft
  Type: Standards Track
  Created: 2024-05-14
  License: BSD-2-Clause
=3D=3DIntroduction=3D=3D =3D=3D=3DAbstract=3D=3D=3D This document proposes additional fields and updated role responsibilities= =20 for BIP 370 PSBTv2 which adds support for sending to silent payments as described in BIP352. =3D=3D=3DCopyright=3D=3D=3D This BIP is licensed under the 2-clause BSD license. =3D=3D=3DMotivation=3D=3D=3D Partially Signed Bitcoin Transaction Version 2 as described in BIP 370 is= =20 not compatible with sending to silent payments as described in BIP352. In= =20 particular, the output script of a silent payment cannot be computed until= =20 after all transaction inputs have been added. Also, any inputs that the Signer has the private keys for must be signed=20 with SIGHASH_ALL and all inputs must not have any scriptPubKeys with Segwit= =20 version > 1. Additionally, the silent payment outputs computed by a signer must be=20 verifiable to other entities. Therefore, new fields and role responsibilities must be added to carry,=20 compute, and verify the silent payment data. =3D=3DSpecification=3D=3D This document specifies new fields and new field inclusion/exclusion=20 requirements. PSBT_OUT_SCRIPT is modified to be optional for outputs in silent= =20 payments capable PSBTs. If this field is not included in the output, then= =20 the field PSBT_OUT_SP_V0_INFO must be included. The new global types are defined as follows: {| ! Name ! ! ! Description ! ! Description ! Versions Requiring Inclusion ! Versions Requiring Exclusion ! Versions Allowing Inclusion |- | Silent Payment Global ECDH Share | PSBT_GLOBAL_SP_ECDH_SHARE =3D 0x07 | <33 byte scan key> <34 byte outpoint>* | The scan key and a list of outpoints corresponding to the prevouts of the= =20 inputs that this ECDH share is for. The outpoints are composed of a 32 byte= =20 txid followed by a 32-bit little endian uint. | <32 byte share> | An ECDH share for a scan key, followed by a list of outpoints. The ECDH= =20 shared is computed with ''a * B_scan'', where ''a'' is the sum of all=20 private keys of the inputs matching the list of outpoints, and ''B_scan''= =20 is the scan key of a recipient. | | 0 | 2 |- | Silent Payment Global DLEQ Proof | PSBT_GLOBAL_SP_DLEQ =3D 0x08 | <33 byte scan key> <34 byte outpoint>* | The scan key and a list of outpoints corresponding to the prevouts of the= =20 inputs that this proof covers. The outpoints are composed of a 32 byte txid= =20 followed by a 32-bit little endian uint. | <64-byte proof> | A DLEQ proof computed for the matching ECDH share. | | 0 | 2 |} One new per-output type is defined as follows: {| ! Name ! ! ! Description ! ! Description ! Versions Requiring Inclusion ! Versions Requiring Exclusion ! Versions Allowing Inclusion |- | Silent Payment Data | PSBT_OUT_SP_V0_INFO =3D 0x08 | None | No key data | <33 byte scan key> <33 byte spend key> | The scan and spend public keys from the silent payments address. | | 0 | 2 |} =3D=3D=3DUnique Identification=3D=3D=3D Silent payment capable PSBTs can be uniquely identified the same way as=20 PSBTv2s, except when including silent payment outputs. For silent payment= =20 capable PSBTs, all silent payment outputs must use the PSBT_OUT_SP_V0_INFO= =20 instead of PSBT_OUT_SCRIPT as the output script when creating the unsigned= =20 transaction used for unique identification. =3D=3DRoles=3D=3D This document modifies some existing roles. =3D=3D=3DConstructor=3D=3D=3D All rules must be followed from PSBTv2 for this role, with the following=20 exception: When an output is added, it must have either PSBT_OUT_SCRIPT or=20 PSBT_OUT_SP_V0_INFO, or both, set. Additionally to PSBTv2, the Constructor must also follow additional rules: Inputs must not spend an output with Segwit version > 1 may only be added= =20 if no silent payment outputs are added. Outputs with PSBT_OUT_SP_V0_INFO set may only be added if there are no=20 inputs spending an output with Segwit version > 1. =3D=3D=3DSigner=3D=3D=3D All rules must be followed from PSBTv2 for this role, in addition to the=20 following: If there are any silent payment outputs present and any input is spending= =20 from a Segwit version > 1, the Signer must fail. For all outputs with PSBT_OUT_SP_V0_INFO set, the Signer should: - Compute and set an ECDH share and DLEQ proof using all inputs it has the= =20 private key for. - Verify the DLEQ proofs for all inputs it does not have the private keys= =20 for. - If all eligible inputs have an ECDH share, compute and set the=20 PSBT_OUT_SCRIPT. If the Signer sets any missing PSBT_OUT_SCRIPTs, it must set the Inputs=20 Modifiable flag to False. If any output does not have PSBT_OUT_SCRIPT set, the Signer must not yet=20 add a signature. The Signer should additionally compute the silent payment addresses,=20 optionally showing this data to the user instead of the computed segwit v1= =20 addresses. If a sighash type is provided and there are silent payment outputs present,= =20 the signer must fail if the sighash type is not SIGHASH_ALL. If a sighash type is not provided and there are silent payment outputs=20 present, the signer must sign using SIGHASH_ALL. =3D=3D=3D=3DComputing the DLEQ Proof=3D=3D=3D=3D For each output, the Signer may generate a proof for other entities to=20 generate the output scripts and verify that the output scripts were=20 generated correctly. Generate a global ECDH share for each scan key ''Bscan'' and all= =20 eligible inputs the Signer has private keys for as follows: Using the notation from=20 [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#specificati= on=20 BIP352] * Let ''An'' be the sum of the public keys ''A'' of all eligible= =20 inputs * Let ''an'' be the sum of the private keys ''a'' of all=20 eligible inputs * Let ''C =3D an=C2=B7Bscan'' Use a key ''Bscan'' followed by a list of the outpoints of all= =20 eligible inputs. Set the value for the key of PSBT_GLOBAL_SP_ECDH_SHARE to ''C''. Compute the DLEQ proof for ''C'' using ''an'' and=20 ''Bscan''. Set the value for the key of PSBT_GLOBAL_SP_DLEQ to the proof. =3D=3D=3D=3DVerifying the DLEQ Proof=3D=3D=3D=3D For each output, the Signer should verify the ECDH shares for all eligible= =20 inputs it does not have the private key for using the proofs provided by=20 other Signers. =3D=3D=3D=3DComputing the Output Scripts=3D=3D=3D=3D Compute the PSBT_OUT_SCRIPT using the procedure in=20 [https://github.com/bitcoin/bips/blob/master/bip-0352.mediawiki#user-conten= t-Creating_outputs=20 BIP352] but substituting ''a=C2=B7Bscan'' with the sum of all=20 PSBT_GLOBAL_SP_ECDH_SHAREs for that scan key. If there are multiple silent payment codes with the same scan key, sort the= =20 codes lexicographically in descending order to determine the ordering of=20 the ''k'' value. If there are multiple silent payment codes with both the same scan and=20 spend keys, sort the subgroup by output index in descending order. =3D=3D=3D=3DChange Detection=3D=3D=3D=3D Updaters may add two PSBT_OUT_BIP32_DERIVATION key-value-pairs with the=20 corresponding derivation path of both the scan and spend keys. The Signer= =20 can then use these fields to verify that the silent payment code is change. =3D=3D=3DTransaction Extractor=3D=3D=3D For silent payment capable PSBTs, the transaction extractor should compute= =20 all output scripts for silent payment codes and verify they are correct=20 using the ECDH shares and DLEQ proofs, otherwise fail. =3D=3DBackwards Compatibility=3D=3D Silent payment capable PSBTs are backwards compatible with PSBTv2 once all= =20 outputs have PSBT_OUT_SCRIPT set. Otherwise they are not backwards=20 compatible. =3D=3DTest Vectors=3D=3D Todo =3D=3DRationale=3D=3D =3D=3DReference implementation=3D=3D Todo --=20 You received this message because you are subscribed to the Google Groups "= Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/= bitcoindev/cde77c84-b576-4d66-aa80-efaf4e50468fn%40googlegroups.com. ------=_Part_32965_354279448.1729172403097 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable This BIP adds support for sending silent payments using PSBTs.

I= f 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 key= s, the DLEQ proof generation is unnecessary.

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

Any feedback appreciated, tha= nk you.

<pre>
=C2=A0 BIP: ?
=C2= =A0 Layer: Applications
=C2=A0 Title: Sending Silent Payments with PSB= Ts
=C2=A0 Author: Andrew Toth <andrewstoth@gmail.com>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ava Chow <me@achow101.com>
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 josibake <josibake@protonmail.com>=C2=A0 Comments-Summary: No comments yet.
=C2=A0 Comments-URI: TBD<= br />=C2=A0 Status: Draft
=C2=A0 Type: Standards Track
=C2=A0 Cre= ated: 2024-05-14
=C2=A0 License: BSD-2-Clause
</pre>
<= br />=3D=3DIntroduction=3D=3D

=3D=3D=3DAbstract=3D=3D=3D
This document proposes additional fields and updated role responsibilit= ies for BIP 370 PSBTv2
which adds support for sending to silent paymen= ts as described in BIP352.

=3D=3D=3DCopyright=3D=3D=3D

This BIP is licensed under the 2-clause BSD license.

=3D=3D=3D= Motivation=3D=3D=3D

Partially Signed Bitcoin Transaction Version= 2 as described in BIP 370 is not compatible with sending to silent payment= s as described in BIP352. In particular, the output script of a silent paym= ent cannot be computed until after all transaction inputs have been added.<= br />Also, any inputs that the Signer has the private keys for must be sign= ed with SIGHASH_ALL and all inputs must not have any scriptPubKeys with Seg= wit version > 1.
Additionally, the silent payment outputs computed = by a signer must be verifiable to other entities.
Therefore, new field= s and role responsibilities must be added to carry, compute, and verify the= silent payment data.

=3D=3DSpecification=3D=3D

This = document specifies new fields and new field inclusion/exclusion requirement= s.

<tt>PSBT_OUT_SCRIPT</tt> is modified to be option= al for outputs in silent payments capable PSBTs. If this field is not inclu= ded in the output, then the field PSBT_OUT_SP_V0_INFO must be included.

The new global types are defined as follows:

{|
! N= ame
! <tt><keytype></tt>
! <tt><keydat= a></tt>
! <tt><keydata></tt> Description! <tt><valuedata></tt>
! <tt><valuedata&= gt;</tt> Description
! Versions Requiring Inclusion
! Versi= ons Requiring Exclusion
! Versions Allowing Inclusion
|-
| S= ilent Payment Global ECDH Share
| <tt>PSBT_GLOBAL_SP_ECDH_SHARE = =3D 0x07</tt>
| <tt><33 byte scan key> <34 byte o= utpoint>*</tt>
| The scan key and a list of outpoints corresp= onding to the prevouts of the inputs that this ECDH share is for. The outpo= ints are composed of a 32 byte txid followed by a 32-bit little endian uint= .
| <tt><32 byte share></tt>
| An ECDH share fo= r 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 inpu= ts matching the list of outpoints, and ''B_scan'' is the scan key of a reci= pient.
|
| 0
| 2
|-
| Silent Payment Global DLEQ P= roof
| <tt>PSBT_GLOBAL_SP_DLEQ =3D 0x08</tt>
| <tt= ><33 byte scan key> <34 byte outpoint>*</tt>
| Th= e scan key and a list of outpoints corresponding to the prevouts of the inp= uts that this proof covers. The outpoints are composed of a 32 byte txid fo= llowed by a 32-bit little endian uint.
| <tt><64-byte proof&g= t;</tt>
| A DLEQ proof computed for the matching ECDH share.
|
| 0
| 2
|}

One new per-output type is defined= as follows:

{|
! Name
! <tt><keytype><= /tt>
! <tt><keydata></tt>
! <tt><ke= ydata></tt> Description
! <tt><valuedata></tt&= gt;
! <tt><valuedata></tt> Description
! Versio= ns Requiring Inclusion
! Versions Requiring Exclusion
! Versions = Allowing Inclusion
|-
| Silent Payment Data
| <tt>PSBT= _OUT_SP_V0_INFO =3D 0x08</tt>
| None
| No key data
| &= lt;tt><33 byte scan key> <33 byte spend key></tt>
| The scan and spend public keys from the silent payments address.
|<= br />| 0
| 2
|}

=3D=3D=3DUnique Identification=3D=3D= =3D

Silent payment capable PSBTs can be uniquely identified the = same way as PSBTv2s, except when including silent payment outputs. For sile= nt 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 th= e unsigned transaction used for unique identification.

=3D=3DRol= es=3D=3D

This document modifies some existing roles.

= =3D=3D=3DConstructor=3D=3D=3D

All rules must be followed from PS= BTv2 for this role, with the following exception:
When an output is ad= ded, it must have either PSBT_OUT_SCRIPT or PSBT_OUT_SP_V0_INFO, or both, s= et.

Additionally to PSBTv2, the Constructor must also follow add= itional rules:

Inputs must not spend an output with Segwit versi= on > 1 may only be added if no silent payment outputs are added.
Ou= tputs with PSBT_OUT_SP_V0_INFO set may only be added if there are no inputs= spending an output with Segwit version > 1.

=3D=3D=3DSigner= =3D=3D=3D

All rules must be followed from PSBTv2 for this role, = in addition to the following:

If there are any silent payment ou= tputs present and any input is spending from a Segwit version > 1, the S= igner must fail.

For all outputs with PSBT_OUT_SP_V0_INFO set, t= he Signer should:
=C2=A0- Compute and set an ECDH share and DLEQ proof= using all inputs it has the private key for.
=C2=A0- Verify the DLEQ = proofs for all inputs it does not have the private keys for.
=C2=A0- I= f all eligible inputs have an ECDH share, compute and set the PSBT_OUT_SCRI= PT.

If the Signer sets any missing PSBT_OUT_SCRIPTs, it must set= the Inputs Modifiable flag to False.

If any output does not hav= e PSBT_OUT_SCRIPT set, the Signer must not yet add a signature.

= The Signer should additionally compute the silent payment addresses, option= ally showing this data to the user instead of the computed segwit v1 addres= ses.

If a sighash type is provided and there are silent payment = outputs present, the signer must fail if the sighash type is not SIGHASH_AL= L.
If a sighash type is not provided and there are silent payment outp= uts present, the signer must sign using SIGHASH_ALL.

=3D=3D=3D= =3DComputing the DLEQ Proof=3D=3D=3D=3D

For each output, the Sig= ner may generate a proof for other entities to generate the output scripts = and verify that the output scripts were generated correctly.

Gen= erate a global ECDH share for each scan key ''B<sub>scan</sub>'= ' and all eligible inputs the Signer has private keys for as follows:
=
Using the notation from [https://github.com/bitcoin/bips/blob/master/= bip-0352.mediawiki#specification BIP352]

* Let ''A<sub>n&l= t;/sub>'' be the sum of the public keys ''A'' of all eligible inputs
* Let ''a<sub>n</sub>'' be the sum of the private keys ''a'' = of all eligible inputs
* Let ''C =3D =C2=A0a<sub>n</sub>= =C2=B7B<sub>scan</sub>''

Use a key ''B<sub>sca= n</sub>'' followed by a list of the outpoints of all eligible inputs.=

Set the value for the key of PSBT_GLOBAL_SP_ECDH_SHARE to ''C''= .

Compute the DLEQ proof for ''C'' using ''a<sub>n</sub= >'' and ''B<sub>scan</sub>''.
Set the value for the key= of PSBT_GLOBAL_SP_DLEQ to the proof.

=3D=3D=3D=3DVerifying the = DLEQ Proof=3D=3D=3D=3D

For each output, the Signer should verify= the ECDH shares for all eligible inputs it does not have the private key f= or using the proofs provided by other Signers.

=3D=3D=3D=3DCompu= ting the Output Scripts=3D=3D=3D=3D

Compute the PSBT_OUT_SCRIPT = using the procedure in [https://github.com/bitcoin/bips/blob/master/bip-035= 2.mediawiki#user-content-Creating_outputs BIP352] but substituting ''a=C2= =B7B<sub>scan</sub>'' with the sum of all PSBT_GLOBAL_SP_ECDH_S= HAREs for that scan key.
If there are multiple silent payment codes wi= th the same scan key, sort the codes lexicographically in descending order = to determine the ordering of the ''k'' value.
If there are multiple si= lent payment codes with both the same scan and spend keys, sort the subgrou= p by output index in descending order.

=3D=3D=3D=3DChange Detect= ion=3D=3D=3D=3D

Updaters may add two PSBT_OUT_BIP32_DERIVATION k= ey-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.

=3D=3D=3DTransaction Extractor=3D=3D=3D<= br />
For silent payment capable PSBTs, the transaction extractor shou= ld compute all output scripts for silent payment codes and verify they are = correct using the ECDH shares and DLEQ proofs, otherwise fail.

= =3D=3DBackwards Compatibility=3D=3D

Silent payment capable PSBTs= are backwards compatible with PSBTv2 once all outputs have PSBT_OUT_SCRIPT= set. Otherwise they are not backwards compatible.

=3D=3DTest Ve= ctors=3D=3D

Todo

=3D=3DRationale=3D=3D

<= ;references/>

=3D=3DReference implementation=3D=3D

Todo

--
You received this message because you are subscribed to the Google Groups &= quot;Bitcoin Development Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to bitcoind= ev+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg= id/bitcoindev/cde77c84-b576-4d66-aa80-efaf4e50468fn%40googlegroups.com.=
------=_Part_32965_354279448.1729172403097-- ------=_Part_32964_605053494.1729172403097--