path: root/a2/8015d36d7afba0a7738d191ef1d63074a9b25f

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 <bitcoindev+bncBDK6LL4DT4ARBLOJYS4AMGQE3NYWE7I@googlegroups.com>)
	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 <bitcoindev@gnusha.org>; 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 <andrewstoth@gmail.com>
To: Bitcoin Development Mailing List <bitcoindev@googlegroups.com>
Message-Id: <cde77c84-b576-4d66-aa80-efaf4e50468fn@googlegroups.com>
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: <bitcoindev.googlegroups.com>
X-Google-Group-Id: 786775582512
List-Post: <https://groups.google.com/group/bitcoindev/post>, <mailto:bitcoindev@googlegroups.com>
List-Help: <https://groups.google.com/support/>, <mailto:bitcoindev+help@googlegroups.com>
List-Archive: <https://groups.google.com/group/bitcoindev
List-Subscribe: <https://groups.google.com/group/bitcoindev/subscribe>, <mailto:bitcoindev+subscribe@googlegroups.com>
List-Unsubscribe: <mailto:googlegroups-manage+786775582512+unsubscribe@googlegroups.com>,
 <https://groups.google.com/group/bitcoindev/subscribe>
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.

<pre>
  BIP: ?
  Layer: Applications
  Title: Sending Silent Payments with PSBTs
  Author: Andrew Toth <andrewstoth@gmail.com>
          Ava Chow <me@achow101.com>
          josibake <josibake@protonmail.com>
  Comments-Summary: No comments yet.
  Comments-URI: TBD
  Status: Draft
  Type: Standards Track
  Created: 2024-05-14
  License: BSD-2-Clause
</pre>

=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.

<tt>PSBT_OUT_SCRIPT</tt> 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
! <tt><keytype></tt>
! <tt><keydata></tt>
! <tt><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Silent Payment Global ECDH Share
| <tt>PSBT_GLOBAL_SP_ECDH_SHARE =3D 0x07</tt>
| <tt><33 byte scan key> <34 byte outpoint>*</tt>
| 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.
| <tt><32 byte share></tt>
| 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
| <tt>PSBT_GLOBAL_SP_DLEQ =3D 0x08</tt>
| <tt><33 byte scan key> <34 byte outpoint>*</tt>
| 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.
| <tt><64-byte proof></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><keydata></tt> Description
! <tt><valuedata></tt>
! <tt><valuedata></tt> Description
! Versions Requiring Inclusion
! Versions Requiring Exclusion
! Versions Allowing Inclusion
|-
| Silent Payment Data
| <tt>PSBT_OUT_SP_V0_INFO =3D 0x08</tt>
| None
| No key data
| <tt><33 byte scan key> <33 byte spend key></tt>
| 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 ''B<sub>scan</sub>'' 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 ''A<sub>n</sub>'' be the sum of the public keys ''A'' of all eligible=
=20
inputs
* Let ''a<sub>n</sub>'' be the sum of the private keys ''a'' of all=20
eligible inputs
* Let ''C =3D  a<sub>n</sub>=C2=B7B<sub>scan</sub>''

Use a key ''B<sub>scan</sub>'' 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 ''a<sub>n</sub>'' and=20
''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=
=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=B7B<sub>scan</sub>'' 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

<references/>

=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.<br /><br />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.<br /><br />Spending support is=
 trivial and can be done with a modification to BIP370 to add a new input f=
ield for the tweak data.<div><br /></div><div>Any feedback appreciated, tha=
nk you.<br /><div><div><br /><div>&lt;pre&gt;<br />=C2=A0 BIP: ?<br />=C2=
=A0 Layer: Applications<br />=C2=A0 Title: Sending Silent Payments with PSB=
Ts<br />=C2=A0 Author: Andrew Toth &lt;andrewstoth@gmail.com&gt;<br />=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Ava Chow &lt;me@achow101.com&gt;<br />=C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 josibake &lt;josibake@protonmail.com&gt;<br=
 />=C2=A0 Comments-Summary: No comments yet.<br />=C2=A0 Comments-URI: TBD<=
br />=C2=A0 Status: Draft<br />=C2=A0 Type: Standards Track<br />=C2=A0 Cre=
ated: 2024-05-14<br />=C2=A0 License: BSD-2-Clause<br />&lt;/pre&gt;<br /><=
br />=3D=3DIntroduction=3D=3D<br /><br />=3D=3D=3DAbstract=3D=3D=3D<br /><b=
r />This document proposes additional fields and updated role responsibilit=
ies for BIP 370 PSBTv2<br />which adds support for sending to silent paymen=
ts as described in BIP352.<br /><br />=3D=3D=3DCopyright=3D=3D=3D<br /><br =
/>This BIP is licensed under the 2-clause BSD license.<br /><br />=3D=3D=3D=
Motivation=3D=3D=3D<br /><br />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 &gt; 1.<br />Additionally, the silent payment outputs computed =
by a signer must be verifiable to other entities.<br />Therefore, new field=
s and role responsibilities must be added to carry, compute, and verify the=
 silent payment data.<br /><br />=3D=3DSpecification=3D=3D<br /><br />This =
document specifies new fields and new field inclusion/exclusion requirement=
s.<br /><br />&lt;tt&gt;PSBT_OUT_SCRIPT&lt;/tt&gt; 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.<br =
/><br />The new global types are defined as follows:<br /><br />{|<br />! N=
ame<br />! &lt;tt&gt;&lt;keytype&gt;&lt;/tt&gt;<br />! &lt;tt&gt;&lt;keydat=
a&gt;&lt;/tt&gt;<br />! &lt;tt&gt;&lt;keydata&gt;&lt;/tt&gt; Description<br=
 />! &lt;tt&gt;&lt;valuedata&gt;&lt;/tt&gt;<br />! &lt;tt&gt;&lt;valuedata&=
gt;&lt;/tt&gt; Description<br />! Versions Requiring Inclusion<br />! Versi=
ons Requiring Exclusion<br />! Versions Allowing Inclusion<br />|-<br />| S=
ilent Payment Global ECDH Share<br />| &lt;tt&gt;PSBT_GLOBAL_SP_ECDH_SHARE =
=3D 0x07&lt;/tt&gt;<br />| &lt;tt&gt;&lt;33 byte scan key&gt; &lt;34 byte o=
utpoint&gt;*&lt;/tt&gt;<br />| 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=
.<br />| &lt;tt&gt;&lt;32 byte share&gt;&lt;/tt&gt;<br />| 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.<br />|<br />| 0<br />| 2<br />|-<br />| Silent Payment Global DLEQ P=
roof<br />| &lt;tt&gt;PSBT_GLOBAL_SP_DLEQ =3D 0x08&lt;/tt&gt;<br />| &lt;tt=
&gt;&lt;33 byte scan key&gt; &lt;34 byte outpoint&gt;*&lt;/tt&gt;<br />| 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.<br />| &lt;tt&gt;&lt;64-byte proof&g=
t;&lt;/tt&gt;<br />| A DLEQ proof computed for the matching ECDH share.<br =
/>|<br />| 0<br />| 2<br />|}<br /><br />One new per-output type is defined=
 as follows:<br /><br />{|<br />! Name<br />! &lt;tt&gt;&lt;keytype&gt;&lt;=
/tt&gt;<br />! &lt;tt&gt;&lt;keydata&gt;&lt;/tt&gt;<br />! &lt;tt&gt;&lt;ke=
ydata&gt;&lt;/tt&gt; Description<br />! &lt;tt&gt;&lt;valuedata&gt;&lt;/tt&=
gt;<br />! &lt;tt&gt;&lt;valuedata&gt;&lt;/tt&gt; Description<br />! Versio=
ns Requiring Inclusion<br />! Versions Requiring Exclusion<br />! Versions =
Allowing Inclusion<br />|-<br />| Silent Payment Data<br />| &lt;tt&gt;PSBT=
_OUT_SP_V0_INFO =3D 0x08&lt;/tt&gt;<br />| None<br />| No key data<br />| &=
lt;tt&gt;&lt;33 byte scan key&gt; &lt;33 byte spend key&gt;&lt;/tt&gt;<br /=
>| The scan and spend public keys from the silent payments address.<br />|<=
br />| 0<br />| 2<br />|}<br /><br />=3D=3D=3DUnique Identification=3D=3D=
=3D<br /><br />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.<br /><br />=3D=3DRol=
es=3D=3D<br /><br />This document modifies some existing roles.<br /><br />=
=3D=3D=3DConstructor=3D=3D=3D<br /><br />All rules must be followed from PS=
BTv2 for this role, with the following exception:<br />When an output is ad=
ded, it must have either PSBT_OUT_SCRIPT or PSBT_OUT_SP_V0_INFO, or both, s=
et.<br /><br />Additionally to PSBTv2, the Constructor must also follow add=
itional rules:<br /><br />Inputs must not spend an output with Segwit versi=
on &gt; 1 may only be added if no silent payment outputs are added.<br />Ou=
tputs with PSBT_OUT_SP_V0_INFO set may only be added if there are no inputs=
 spending an output with Segwit version &gt; 1.<br /><br />=3D=3D=3DSigner=
=3D=3D=3D<br /><br />All rules must be followed from PSBTv2 for this role, =
in addition to the following:<br /><br />If there are any silent payment ou=
tputs present and any input is spending from a Segwit version &gt; 1, the S=
igner must fail.<br /><br />For all outputs with PSBT_OUT_SP_V0_INFO set, t=
he Signer should:<br />=C2=A0- Compute and set an ECDH share and DLEQ proof=
 using all inputs it has the private key for.<br />=C2=A0- Verify the DLEQ =
proofs for all inputs it does not have the private keys for.<br />=C2=A0- I=
f all eligible inputs have an ECDH share, compute and set the PSBT_OUT_SCRI=
PT.<br /><br />If the Signer sets any missing PSBT_OUT_SCRIPTs, it must set=
 the Inputs Modifiable flag to False.<br /><br />If any output does not hav=
e PSBT_OUT_SCRIPT set, the Signer must not yet add a signature.<br /><br />=
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.<br /><br />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.<br />If a sighash type is not provided and there are silent payment outp=
uts present, the signer must sign using SIGHASH_ALL.<br /><br />=3D=3D=3D=
=3DComputing the DLEQ Proof=3D=3D=3D=3D<br /><br />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.<br /><br />Gen=
erate a global ECDH share for each scan key ''B&lt;sub&gt;scan&lt;/sub&gt;'=
' and all eligible inputs the Signer has private keys for as follows:<br />=
<br />Using the notation from [https://github.com/bitcoin/bips/blob/master/=
bip-0352.mediawiki#specification BIP352]<br /><br />* Let ''A&lt;sub&gt;n&l=
t;/sub&gt;'' be the sum of the public keys ''A'' of all eligible inputs<br =
/>* Let ''a&lt;sub&gt;n&lt;/sub&gt;'' be the sum of the private keys ''a'' =
of all eligible inputs<br />* Let ''C =3D =C2=A0a&lt;sub&gt;n&lt;/sub&gt;=
=C2=B7B&lt;sub&gt;scan&lt;/sub&gt;''<br /><br />Use a key ''B&lt;sub&gt;sca=
n&lt;/sub&gt;'' followed by a list of the outpoints of all eligible inputs.=
<br /><br />Set the value for the key of PSBT_GLOBAL_SP_ECDH_SHARE to ''C''=
.<br /><br />Compute the DLEQ proof for ''C'' using ''a&lt;sub&gt;n&lt;/sub=
&gt;'' and ''B&lt;sub&gt;scan&lt;/sub&gt;''.<br />Set the value for the key=
 of PSBT_GLOBAL_SP_DLEQ to the proof.<br /><br />=3D=3D=3D=3DVerifying the =
DLEQ Proof=3D=3D=3D=3D<br /><br />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.<br /><br />=3D=3D=3D=3DCompu=
ting the Output Scripts=3D=3D=3D=3D<br /><br />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&lt;sub&gt;scan&lt;/sub&gt;'' with the sum of all PSBT_GLOBAL_SP_ECDH_S=
HAREs for that scan key.<br />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.<br />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.<br /><br />=3D=3D=3D=3DChange Detect=
ion=3D=3D=3D=3D<br /><br />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.<br /><br />=3D=3D=3DTransaction Extractor=3D=3D=3D<=
br /><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.<br /><br />=
=3D=3DBackwards Compatibility=3D=3D<br /><br />Silent payment capable PSBTs=
 are backwards compatible with PSBTv2 once all outputs have PSBT_OUT_SCRIPT=
 set. Otherwise they are not backwards compatible.<br /><br />=3D=3DTest Ve=
ctors=3D=3D<br /><br />Todo<br /><br />=3D=3DRationale=3D=3D<br /><br />&lt=
;references/&gt;<br /><br />=3D=3DReference implementation=3D=3D<br /><br /=
>Todo<br /></div></div></div></div>

<p></p>

-- <br />
You received this message because you are subscribed to the Google Groups &=
quot;Bitcoin Development Mailing List&quot; group.<br />
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to <a href=3D"mailto:bitcoindev+unsubscribe@googlegroups.com">bitcoind=
ev+unsubscribe@googlegroups.com</a>.<br />
To view this discussion on the web visit <a href=3D"https://groups.google.c=
om/d/msgid/bitcoindev/cde77c84-b576-4d66-aa80-efaf4e50468fn%40googlegroups.=
com?utm_medium=3Demail&utm_source=3Dfooter">https://groups.google.com/d/msg=
id/bitcoindev/cde77c84-b576-4d66-aa80-efaf4e50468fn%40googlegroups.com</a>.=
<br />

------=_Part_32965_354279448.1729172403097--

------=_Part_32964_605053494.1729172403097--