path: root/97/2b99766a9abf28b92de2f18b8631cadcf55b18

Return-Path: <jlrubin@mit.edu>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AF9E2C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Jan 2022 05:55:17 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 89B396064D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Jan 2022 05:55:17 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level: 
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id vUNo7uiBBvtI
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Jan 2022 05:55:15 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 5572360625
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 17 Jan 2022 05:55:15 +0000 (UTC)
Received: from mail-lf1-f45.google.com (mail-lf1-f45.google.com
 [209.85.167.45]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 20H5tCXP027156
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Mon, 17 Jan 2022 00:55:13 -0500
Received: by mail-lf1-f45.google.com with SMTP id x22so53371870lfd.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sun, 16 Jan 2022 21:55:13 -0800 (PST)
X-Gm-Message-State: AOAM532boIDI0La0zfHclw4iHFhbXWdtbA2w8etrdjrmM/XncwQFroQd
 GjE8dmKZNyrC8UJ3gYdmxdl/pxb2DLLdddJhNVc=
X-Google-Smtp-Source: ABdhPJy/+9vn6ShzUapJjg/Yz7hz4YoWqWHXCUUT0FiIEN9/AYsnQWyITQ/XxEMQniBMHi8pKyZUXk/o+7zNHgZsnEg=
X-Received: by 2002:a05:6512:3b0b:: with SMTP id
 f11mr9595819lfv.670.1642398911584; 
 Sun, 16 Jan 2022 21:55:11 -0800 (PST)
MIME-Version: 1.0
References: <89d7d76698de12dd7fdb8185130f4ace3bee9ef8.camel@protonmail.com>
In-Reply-To: <89d7d76698de12dd7fdb8185130f4ace3bee9ef8.camel@protonmail.com>
From: Jeremy <jlrubin@mit.edu>
Date: Sun, 16 Jan 2022 21:55:00 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhd=CnGubyA3pqXkGz2fBJhRNBFCAegjXoqBhW4KY3r-g@mail.gmail.com>
Message-ID: <CAD5xwhhd=CnGubyA3pqXkGz2fBJhRNBFCAegjXoqBhW4KY3r-g@mail.gmail.com>
To: Dr Maxim Orlovsky <orlovsky@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000b45d0105d5c0cb23"
Subject: Re: [bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for
	PSBT (bip-psbt-p2c)
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 17 Jan 2022 05:55:17 -0000

--000000000000b45d0105d5c0cb23
Content-Type: text/plain; charset="UTF-8"

High level feedback:

It would be nice if this field was not distinct from BIP32 derivation
descriptors so that you could have a single representation for the Extended
Key that doesn't need some additional field only in PSBT.

If I understood correctly, and this is just an arbitrary hash being
provably added (but has not direct cryptographic function), this can also
be done with no changes to BIP32 as I did in
https://github.com/sapio-lang/sapio/blob/master/ctv_emulators/src/lib.rs.

Best,

Jeremy


--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Sun, Jan 16, 2022 at 1:00 PM Dr Maxim Orlovsky via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Dear Bictoin dev community,
>
>
> In Mar 2019 Andrew Poelstra sent to bitcoin dev mail list a proposal
> for extending existing PSBT standard [6], which among other was suggesting
> adding a field for P2C tweaks:
>
> > (c) a map from public keys to 32-byte "tweaks" that are used in the
> >     pay-to-contract construction. Selfishly I'd like this to be a
> >     variable-length bytestring with the semantics that (a) the first
> >     33 bytes represent an untweaked pubkey; (b) the HMAC-SHA256 of
> >     the whole thing, when multiplied by G and added to the untweaked
> >     pubkey, result in the target key. This matches the algorithm in
> >     [3] which is deployed in Blockstream's Liquid, but I'd be happy
> >     with a more efficient scheme which e.g. used SHA256 rather than
> >     HMAC-SHA256.
>
> This BIP proposal is an attempt to structure that idea into a more
> universal and standard form, following a discussion happened in
> https://github.com/bitcoin/bips/pull/1239. Specifically, it adds a PSBT
> input field for inputs spending UTXOs with previously created
> pay-to-contract (P2C) public key tweaks.
>
>
> -----------------------------------------------------------------------
>
> <pre>
>   BIP: ?
>   Layer: Applications
>   Title: Pay-to-contract tweak fields for PSBT
>   Author: Maxim Orlovsky <orlovsky@lnp-bp.org>,
>           Andrew Poelstra <apoelstra@wpsoftware.net>
>   Discussions-To: <bitcoin-dev@lists.linuxfoundation.org>
>   Comments-URI: <to be assigned>
>   Status: Draft
>   Type: Standards Track
>   Created: 2022-01-16
>   License: BSD-2-Clause
>   Requires: BIP-174
> </pre>
>
> ==Introduction==
>
> ===Abstract===
>
> This document proposes additional fields for BIP 174 PSBTv0 and BIP 370
> PSBTv2
> that allow for pay-to-contract key tweaking data data to be included in a
> PSBT
> of any version. These will represent an extra-transaction information
> required
> for the signer to produce valid signatures spending previous outputs.
>
> ===Copyright===
>
> This BIP is licensed under the 2-clause BSD license.
>
> ===Background===
>
> Key tweaking is a procedure for creating a cryptographic commitment to some
> message using elliptic curve properties. The procedure uses the discrete
> log
> problem (DLP) to commit to an extra-transaction message. This is done by
> adding
> to a public key (for which the output owner knows the corresponding
> private key)
> a hash of the message multiplied on the generator point G of the elliptic
> curve.
> This produces a tweaked public key, containing the commitment. Later, in
> order
> to spend an output containing P2C commitment, the same commitment should be
> added to the corresponding private key.
>
> This type of commitment was originally proposed as a part of the pay to
> contract
> concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity
> Wall
> [2] for the same purpose. Since that time multiple different protocols for
> P2C
> has been developed, including OpenTimeStamps [3], Elements sidechain P2C
> tweaks
> [4] and LNPBP-1 [5], used in for constructing Peter Todd's
> single-use-seals [6]
> in client-side-validation protocols like RGB.
>
> ===Motivation===
>
> P2C outputs can be detected onchain and spent only if the output owner
> not just knowns the corresponding original private key, but also is aware
> about
> P2C tweak applied to the public key. In order to produce a valid
> signature, the
> same tweak value must be added (modulo group order) to the original
> private key
> by a signer device. This represents a channelge for external signers,
> which may
> not have any information about such commitment. This proposal addresses
> this
> issue by adding relevant fields to the PSBT input information.
>
> The proposal abstracts details of specific P2C protocols and provides
> universal
> method for spending previous outpus containing P2C tweaks, applied to the
> public
> key contained within any standard form of the <tt>scriptPubkey</tt>,
> including
> bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested
> witness v0
> P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs.
>
>
> ==Design==
>
> P2C-tweaked public keys are already exposed in the
> <tt>PSBT_IN_REDEEM_SCRIPT</tt>, <tt>PSBT_IN_WITNESS_SCRIPT</tt>,
> <tt>PSBT_IN_TAP_INTERNAL_KEY</tt> and <tt>PSBT_IN_TAP_LEAF_SCRIPT</tt>
> fields;
> the only information signer is needed to recognize which keys it should
> sign
> with is from which of the original keys they were generated. This is
> achieved by
> introducing new `PSBT_IN_P2C_TWEAK` field which has the original key as a
> field
> key and the tweak as a field value. The signer will recognize the keys
> which are
> available to it, apply the tweak to them and see in which scripts it was
> used --
> and use this information to apply tweaks for the corresponding private
> keys and
> produce valid signatures.
>
>
> ==Specification==
>
> The new per-input 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
> |-
> | P2C Key Tweak
> | <tt>PSBT_IN_P2C_TWEAK = 0x19</tt>
> | <tt><pubkey></tt>
> | 33 bytes of compact public key serialization specifying to which of keys
> the
> P2C tweak may be applied (i.e. this MUST be a value of a public key before
> the
> tweak is applied). BIP-340 keys are serialized by appending `02`
> byte.<ref>'''Why compressed public keys are not distinguished from BIP-340
> public keys'''We follow the logic of BIP32 key derivation which does not
> performs that distinguishment. The type of the key is defined by the input
> type,
> and adding additional PSBT field type will just create the need for
> handling
> errors when the input type does not match the provided key type.</ref>
> | <tt><tweak></tt>
> | The 32 byte value which MUST be added to a private key to produce correct
> ECDSA and/or Schnorr signature ("key tweak"). Signers SHOULD remove this
> field
> after <tt>PSBT_IN_PARTIAL_SIG</tt> is constructed.
> |
> |
> | 0, 2
> | BIP-P2C
> |}
>
>
> ==Security considerations==
>
> The scope of this proposal is deliberately kept narrow; it addresses
> only spending of transaction outputs containing P2C tweaks - and does not
> addresses construction of a new P2C commitments or transactions containing
> them in their outputs.<ref>'''Why only spending of P2C tweaked outputs is
> covered'''P2C tweaks commit to external data, some of which may represent
> certain value (like in some sidechains, single-use-seal applications like
> RGB etc). Creation of such outputs much allow hardware devices to
> understand the structure of such extra-transaction data, which may be in
> different formats and constantly involve. Thus, this should be addresses
> with a separate standards (or be a vendor-based). The current proposal only
> touches the question of spending an output which contained previously
> created P2C commitment, which does not creates a new commitment and does
> not provides that kind of risk of extra-blockchain value loses.</ref>
>
>
> ==Rationale==
>
> <references/>
>
>
> ==Compatibility==
>
> The proposal is compatible with the existing consensus rules and does not
> require any of their modifications.
>
> The proposed P2C PSBT fields provides sufficient information for creating a
> valid signatures for spendings of the following output types containing
> tweaked
> public keys:
> - bare scripts,
> - P2PK,
> - P2PKH,
> - P2SH,
> - witness v0 P2WPKH and P2WSH,
> - nested witness v0 P2WPKH-P2SH and P2WSH-P2SH,
> - witness v1 P2TR outputs.
>
> Possible future witness versions, including witness v1 non-taproot outputs
> may
> not be supported or covered by this BIP and may require addition of new
> fields
> to the PSBT inputs.
>
>
> ==Reference implementation==
>
> WIP
>
>
> ==Acknowledgements==
>
> TBD
>
>
> ==Test vectors==
>
> TBD
>
>
> ==References==
>
> [1] Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the
>     Pay-to-Contract Protocol. arXiv:1212.3257 \[cs.CR\]
>     <https://arxiv.org/pdf/1212.3257.pdf>
> [2] Eternity Wall's "sign-to-contract" article.
>     <https://blog.eternitywall.com/2018/04/13/sign-to-contract/>
> [3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed
>     Timestamping with Bitcoin.
>     <https://petertodd.org/2016/opentimestamps-announcement>
> [4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain
>     Innovations with Pegged Sidechains (commit5620e43). Appenxix A.
>     <https://blockstream.com/sidechains.pdf>;.
> [5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key
>     tweaking: collision- resistant elliptic curve-based commitments.
>     LNPBP-1 Standard.
>     <https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0001.md>
> [6] Peter Todd. Single-use-seals. LNPBP-8 Standard.
>     <https://github.com/LNP-BP/LNPBPs/blob/master/lnpbp-0008.md>
>
> --
> Maxim Orlovsky
> orlovsky@protonmail.com
> GitHub: @dr-orlovsky
> Twitter: @dr_orlovsky
>
> LNP/BP Standards Association
> orlovsky@lnp-bp.org
> github.com/LNP-BP
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000b45d0105d5c0cb23
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">High level feedback:</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#000000=
">It would be nice if this field was not distinct from BIP32 derivation des=
criptors so that you could have a single representation for the Extended Ke=
y that doesn&#39;t need some additional field only in PSBT.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">If I unde=
rstood correctly, and this is just an arbitrary hash being provably added (=
but has not direct cryptographic function), this can also be done with no c=
hanges to BIP32 as I did in=C2=A0<a href=3D"https://github.com/sapio-lang/s=
apio/blob/master/ctv_emulators/src/lib.rs">https://github.com/sapio-lang/sa=
pio/blob/master/ctv_emulators/src/lib.rs</a>.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
#000000"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:#000000">Best,</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:#000000">Jeremy</d=
iv><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-s=
erif;font-size:small;color:#000000"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:#0000=
00"><br></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smartmai=
l=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter.com=
/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twitter.=
com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><br><div=
 class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Jan 16=
, 2022 at 1:00 PM Dr Maxim Orlovsky via bitcoin-dev &lt;<a href=3D"mailto:b=
itcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:=
0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left=
-color:rgb(204,204,204);padding-left:1ex">Dear Bictoin dev community,<br>
<br>
<br>
In Mar 2019 Andrew Poelstra sent to bitcoin dev mail list a proposal<br>
for extending existing PSBT standard [6], which among other was suggesting =
adding a field for P2C tweaks:<br>
<br>
&gt; (c) a map from public keys to 32-byte &quot;tweaks&quot; that are used=
 in the<br>
&gt;=C2=A0 =C2=A0 =C2=A0pay-to-contract construction. Selfishly I&#39;d lik=
e this to be a<br>
&gt;=C2=A0 =C2=A0 =C2=A0variable-length bytestring with the semantics that =
(a) the first<br>
&gt;=C2=A0 =C2=A0 =C2=A033 bytes represent an untweaked pubkey; (b) the HMA=
C-SHA256 of<br>
&gt;=C2=A0 =C2=A0 =C2=A0the whole thing, when multiplied by G and added to =
the untweaked<br>
&gt;=C2=A0 =C2=A0 =C2=A0pubkey, result in the target key. This matches the =
algorithm in<br>
&gt;=C2=A0 =C2=A0 =C2=A0[3] which is deployed in Blockstream&#39;s Liquid, =
but I&#39;d be happy<br>
&gt;=C2=A0 =C2=A0 =C2=A0with a more efficient scheme which e.g. used SHA256=
 rather than<br>
&gt;=C2=A0 =C2=A0 =C2=A0HMAC-SHA256.<br>
<br>
This BIP proposal is an attempt to structure that idea into a more<br>
universal and standard form, following a discussion happened in <a href=3D"=
https://github.com/bitcoin/bips/pull/1239" rel=3D"noreferrer" target=3D"_bl=
ank">https://github.com/bitcoin/bips/pull/1239</a>. Specifically, it adds a=
 PSBT input field for inputs spending UTXOs with previously created pay-to-=
contract (P2C) public key tweaks.<br>
<br>
<br>
-----------------------------------------------------------------------<br>
<br>
&lt;pre&gt;<br>
=C2=A0 BIP: ?<br>
=C2=A0 Layer: Applications<br>
=C2=A0 Title: Pay-to-contract tweak fields for PSBT<br>
=C2=A0 Author: Maxim Orlovsky &lt;<a href=3D"mailto:orlovsky@lnp-bp.org" ta=
rget=3D"_blank">orlovsky@lnp-bp.org</a>&gt;,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andrew Poelstra &lt;<a href=3D"mailto:ap=
oelstra@wpsoftware.net" target=3D"_blank">apoelstra@wpsoftware.net</a>&gt;<=
br>
=C2=A0 Discussions-To: &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundat=
ion.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;<br=
>
=C2=A0 Comments-URI: &lt;to be assigned&gt;<br>
=C2=A0 Status: Draft<br>
=C2=A0 Type: Standards Track<br>
=C2=A0 Created: 2022-01-16<br>
=C2=A0 License: BSD-2-Clause<br>
=C2=A0 Requires: BIP-174<br>
&lt;/pre&gt;<br>
<br>
=3D=3DIntroduction=3D=3D<br>
<br>
=3D=3D=3DAbstract=3D=3D=3D<br>
<br>
This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSB=
Tv2<br>
that allow for pay-to-contract key tweaking data data to be included in a P=
SBT<br>
of any version. These will represent an extra-transaction information requi=
red<br>
for the signer to produce valid signatures spending previous outputs.<br>
<br>
=3D=3D=3DCopyright=3D=3D=3D<br>
<br>
This BIP is licensed under the 2-clause BSD license.<br>
<br>
=3D=3D=3DBackground=3D=3D=3D<br>
<br>
Key tweaking is a procedure for creating a cryptographic commitment to some=
<br>
message using elliptic curve properties. The procedure uses the discrete lo=
g<br>
problem (DLP) to commit to an extra-transaction message. This is done by ad=
ding<br>
to a public key (for which the output owner knows the corresponding private=
 key)<br>
a hash of the message multiplied on the generator point G of the elliptic c=
urve.<br>
This produces a tweaked public key, containing the commitment. Later, in or=
der<br>
to spend an output containing P2C commitment, the same commitment should be=
<br>
added to the corresponding private key.<br>
<br>
This type of commitment was originally proposed as a part of the pay to con=
tract<br>
concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity W=
all<br>
[2] for the same purpose. Since that time multiple different protocols for =
P2C<br>
has been developed, including OpenTimeStamps [3], Elements sidechain P2C tw=
eaks<br>
[4] and LNPBP-1 [5], used in for constructing Peter Todd&#39;s single-use-s=
eals [6]<br>
in client-side-validation protocols like RGB.<br>
<br>
=3D=3D=3DMotivation=3D=3D=3D<br>
<br>
P2C outputs can be detected onchain and spent only if the output owner<br>
not just knowns the corresponding original private key, but also is aware a=
bout<br>
P2C tweak applied to the public key. In order to produce a valid signature,=
 the<br>
same tweak value must be added (modulo group order) to the original private=
 key<br>
by a signer device. This represents a channelge for external signers, which=
 may<br>
not have any information about such commitment. This proposal addresses thi=
s<br>
issue by adding relevant fields to the PSBT input information.<br>
<br>
The proposal abstracts details of specific P2C protocols and provides unive=
rsal<br>
method for spending previous outpus containing P2C tweaks, applied to the p=
ublic<br>
key contained within any standard form of the &lt;tt&gt;scriptPubkey&lt;/tt=
&gt;, including<br>
bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested witnes=
s v0<br>
P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs.<br>
<br>
<br>
=3D=3DDesign=3D=3D<br>
<br>
P2C-tweaked public keys are already exposed in the<br>
&lt;tt&gt;PSBT_IN_REDEEM_SCRIPT&lt;/tt&gt;, &lt;tt&gt;PSBT_IN_WITNESS_SCRIP=
T&lt;/tt&gt;,<br>
&lt;tt&gt;PSBT_IN_TAP_INTERNAL_KEY&lt;/tt&gt; and &lt;tt&gt;PSBT_IN_TAP_LEA=
F_SCRIPT&lt;/tt&gt; fields;<br>
the only information signer is needed to recognize which keys it should sig=
n<br>
with is from which of the original keys they were generated. This is achiev=
ed by<br>
introducing new `PSBT_IN_P2C_TWEAK` field which has the original key as a f=
ield<br>
key and the tweak as a field value. The signer will recognize the keys whic=
h are<br>
available to it, apply the tweak to them and see in which scripts it was us=
ed --<br>
and use this information to apply tweaks for the corresponding private keys=
 and<br>
produce valid signatures.<br>
<br>
<br>
=3D=3DSpecification=3D=3D<br>
<br>
The new per-input 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;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>
! Versions Requiring Exclusion<br>
! Versions Allowing Inclusion<br>
|-<br>
| P2C Key Tweak<br>
| &lt;tt&gt;PSBT_IN_P2C_TWEAK =3D 0x19&lt;/tt&gt;<br>
| &lt;tt&gt;&lt;pubkey&gt;&lt;/tt&gt;<br>
| 33 bytes of compact public key serialization specifying to which of keys =
the<br>
P2C tweak may be applied (i.e. this MUST be a value of a public key before =
the<br>
tweak is applied). BIP-340 keys are serialized by appending `02`<br>
byte.&lt;ref&gt;&#39;&#39;&#39;Why compressed public keys are not distingui=
shed from BIP-340<br>
public keys&#39;&#39;&#39;We follow the logic of BIP32 key derivation which=
 does not<br>
performs that distinguishment. The type of the key is defined by the input =
type,<br>
and adding additional PSBT field type will just create the need for handlin=
g<br>
errors when the input type does not match the provided key type.&lt;/ref&gt=
;<br>
| &lt;tt&gt;&lt;tweak&gt;&lt;/tt&gt;<br>
| The 32 byte value which MUST be added to a private key to produce correct=
<br>
ECDSA and/or Schnorr signature (&quot;key tweak&quot;). Signers SHOULD remo=
ve this field<br>
after &lt;tt&gt;PSBT_IN_PARTIAL_SIG&lt;/tt&gt; is constructed.<br>
|<br>
|<br>
| 0, 2<br>
| BIP-P2C<br>
|}<br>
<br>
<br>
=3D=3DSecurity considerations=3D=3D<br>
<br>
The scope of this proposal is deliberately kept narrow; it addresses<br>
only spending of transaction outputs containing P2C tweaks - and does not a=
ddresses construction of a new P2C commitments or transactions containing t=
hem in their outputs.&lt;ref&gt;&#39;&#39;&#39;Why only spending of P2C twe=
aked outputs is covered&#39;&#39;&#39;P2C tweaks commit to external data, s=
ome of which may represent certain value (like in some sidechains, single-u=
se-seal applications like RGB etc). Creation of such outputs much allow har=
dware devices to understand the structure of such extra-transaction data, w=
hich may be in different formats and constantly involve. Thus, this should =
be addresses with a separate standards (or be a vendor-based). The current =
proposal only touches the question of spending an output which contained pr=
eviously created P2C commitment, which does not creates a new commitment an=
d does not provides that kind of risk of extra-blockchain value loses.&lt;/=
ref&gt;<br>
<br>
<br>
=3D=3DRationale=3D=3D<br>
<br>
&lt;references/&gt;<br>
<br>
<br>
=3D=3DCompatibility=3D=3D<br>
<br>
The proposal is compatible with the existing consensus rules and does not<b=
r>
require any of their modifications.<br>
<br>
The proposed P2C PSBT fields provides sufficient information for creating a=
<br>
valid signatures for spendings of the following output types containing twe=
aked<br>
public keys:<br>
- bare scripts,<br>
- P2PK,<br>
- P2PKH,<br>
- P2SH,<br>
- witness v0 P2WPKH and P2WSH,<br>
- nested witness v0 P2WPKH-P2SH and P2WSH-P2SH,<br>
- witness v1 P2TR outputs.<br>
<br>
Possible future witness versions, including witness v1 non-taproot outputs =
may<br>
not be supported or covered by this BIP and may require addition of new fie=
lds<br>
to the PSBT inputs.<br>
<br>
<br>
=3D=3DReference implementation=3D=3D<br>
<br>
WIP<br>
<br>
<br>
=3D=3DAcknowledgements=3D=3D<br>
<br>
TBD<br>
<br>
<br>
=3D=3DTest vectors=3D=3D<br>
<br>
TBD<br>
<br>
<br>
=3D=3DReferences=3D=3D<br>
<br>
[1] Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the<br>
=C2=A0 =C2=A0 Pay-to-Contract Protocol. arXiv:1212.3257 \[cs.CR\]<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://arxiv.org/pdf/1212.3257.pdf" rel=3D"no=
referrer" target=3D"_blank">https://arxiv.org/pdf/1212.3257.pdf</a>&gt;<br>
[2] Eternity Wall&#39;s &quot;sign-to-contract&quot; article.<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://blog.eternitywall.com/2018/04/13/sign-=
to-contract/" rel=3D"noreferrer" target=3D"_blank">https://blog.eternitywal=
l.com/2018/04/13/sign-to-contract/</a>&gt;<br>
[3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed<br>
=C2=A0 =C2=A0 Timestamping with Bitcoin.<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://petertodd.org/2016/opentimestamps-anno=
uncement" rel=3D"noreferrer" target=3D"_blank">https://petertodd.org/2016/o=
pentimestamps-announcement</a>&gt;<br>
[4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain<br>
=C2=A0 =C2=A0 Innovations with Pegged Sidechains (commit5620e43). Appenxix =
A.<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://blockstream.com/sidechains.pdf" rel=3D=
"noreferrer" target=3D"_blank">https://blockstream.com/sidechains.pdf</a>&g=
t;;.<br>
[5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key<br>
=C2=A0 =C2=A0 tweaking: collision- resistant elliptic curve-based commitmen=
ts.<br>
=C2=A0 =C2=A0 LNPBP-1 Standard.<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://github.com/LNP-BP/LNPBPs/blob/master/l=
npbp-0001.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/LNP-B=
P/LNPBPs/blob/master/lnpbp-0001.md</a>&gt;<br>
[6] Peter Todd. Single-use-seals. LNPBP-8 Standard.<br>
=C2=A0 =C2=A0 &lt;<a href=3D"https://github.com/LNP-BP/LNPBPs/blob/master/l=
npbp-0008.md" rel=3D"noreferrer" target=3D"_blank">https://github.com/LNP-B=
P/LNPBPs/blob/master/lnpbp-0008.md</a>&gt;<br>
<br>
--<br>
Maxim Orlovsky<br>
<a href=3D"mailto:orlovsky@protonmail.com" target=3D"_blank">orlovsky@proto=
nmail.com</a><br>
GitHub: @dr-orlovsky<br>
Twitter: @dr_orlovsky<br>
<br>
LNP/BP Standards Association<br>
<a href=3D"mailto:orlovsky@lnp-bp.org" target=3D"_blank">orlovsky@lnp-bp.or=
g</a><br>
<a href=3D"http://github.com/LNP-BP" rel=3D"noreferrer" target=3D"_blank">g=
ithub.com/LNP-BP</a><br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000b45d0105d5c0cb23--