From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id AF9E2C002F for ; 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 ; 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 ; 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 ; 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 ; Mon, 17 Jan 2022 00:55:13 -0500 Received: by mail-lf1-f45.google.com with SMTP id x22so53371870lfd.10 for ; 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 Date: Sun, 16 Jan 2022 21:55:00 -0800 X-Gmail-Original-Message-ID: Message-ID: To: Dr Maxim Orlovsky , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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. > > > ----------------------------------------------------------------------- > > 
>   BIP: ?
>   Layer: Applications
>   Title: Pay-to-contract tweak fields for PSBT
>   Author: Maxim Orlovsky ,
>           Andrew Poelstra 
>   Discussions-To: 
>   Comments-URI: 
>   Status: Draft
>   Type: Standards Track
>   Created: 2022-01-16
>   License: BSD-2-Clause
>   Requires: BIP-174
>
> > ==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 scriptPubkey, > 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 > PSBT_IN_REDEEM_SCRIPT, PSBT_IN_WITNESS_SCRIPT, > PSBT_IN_TAP_INTERNAL_KEY and PSBT_IN_TAP_LEAF_SCRIPT > 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 > ! > ! > ! Description > ! > ! Description > ! Versions Requiring Inclusion > ! Versions Requiring Exclusion > ! Versions Allowing Inclusion > |- > | P2C Key Tweak > | PSBT_IN_P2C_TWEAK = 0x19 > | > | 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.'''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. > | > | 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 PSBT_IN_PARTIAL_SIG 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.'''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. > > > ==Rationale== > > > > > ==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\] > > [2] Eternity Wall's "sign-to-contract" article. > > [3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed > Timestamping with Bitcoin. > > [4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain > Innovations with Pegged Sidechains (commit5620e43). Appenxix A. > ;. > [5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key > tweaking: collision- resistant elliptic curve-based commitments. > LNPBP-1 Standard. > > [6] Peter Todd. Single-use-seals. LNPBP-8 Standard. > > > -- > 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
High level feedback:

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't need some additional field only in PSBT.

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=A0https://github.com/sapio-lang/sa= pio/blob/master/ctv_emulators/src/lib.rs.

Best,

Jeremy




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
>=C2=A0 =C2=A0 =C2=A0pay-to-contract construction. Selfishly I'd lik= e this to be a
>=C2=A0 =C2=A0 =C2=A0variable-length bytestring with the semantics that = (a) the first
>=C2=A0 =C2=A0 =C2=A033 bytes represent an untweaked pubkey; (b) the HMA= C-SHA256 of
>=C2=A0 =C2=A0 =C2=A0the whole thing, when multiplied by G and added to = the untweaked
>=C2=A0 =C2=A0 =C2=A0pubkey, result in the target key. This matches the = algorithm in
>=C2=A0 =C2=A0 =C2=A0[3] which is deployed in Blockstream's Liquid, = but I'd be happy
>=C2=A0 =C2=A0 =C2=A0with a more efficient scheme which e.g. used SHA256= rather than
>=C2=A0 =C2=A0 =C2=A0HMAC-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>
=C2=A0 BIP: ?
=C2=A0 Layer: Applications
=C2=A0 Title: Pay-to-contract tweak fields for PSBT
=C2=A0 Author: Maxim Orlovsky <orlovsky@lnp-bp.org>,
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Andrew Poelstra <apoelstra@wpsoftware.net><= br> =C2=A0 Discussions-To: <bitcoin-dev@lists.linuxfoundation.org> =C2=A0 Comments-URI: <to be assigned>
=C2=A0 Status: Draft
=C2=A0 Type: Standards Track
=C2=A0 Created: 2022-01-16
=C2=A0 License: BSD-2-Clause
=C2=A0 Requires: BIP-174
</pre>

=3D=3DIntroduction=3D=3D

=3D=3D=3DAbstract=3D=3D=3D

This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSB= Tv2
that allow for pay-to-contract key tweaking data data to be included in a P= SBT
of any version. These will represent an extra-transaction information requi= red
for the signer to produce valid signatures spending previous outputs.

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

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

=3D=3D=3DBackground=3D=3D=3D

Key tweaking is a procedure for creating a cryptographic commitment to some=
message using elliptic curve properties. The procedure uses the discrete lo= g
problem (DLP) to commit to an extra-transaction message. This is done by ad= ding
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 c= urve.
This produces a tweaked public key, containing the commitment. Later, in or= der
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 con= tract
concept by Ilja Gerhardt and Timo Hanke in [1] and later used by Eternity W= all
[2] for the same purpose. Since that time multiple different protocols for = P2C
has been developed, including OpenTimeStamps [3], Elements sidechain P2C tw= eaks
[4] and LNPBP-1 [5], used in for constructing Peter Todd's single-use-s= eals [6]
in client-side-validation protocols like RGB.

=3D=3D=3DMotivation=3D=3D=3D

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 a= bout
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 thi= s
issue by adding relevant fields to the PSBT input information.

The proposal abstracts details of specific P2C protocols and provides unive= rsal
method for spending previous outpus containing P2C tweaks, applied to the p= ublic
key contained within any standard form of the <tt>scriptPubkey</tt= >, including
bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested witnes= s v0
P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs.


=3D=3DDesign=3D=3D

P2C-tweaked public keys are already exposed in the
<tt>PSBT_IN_REDEEM_SCRIPT</tt>, <tt>PSBT_IN_WITNESS_SCRIP= T</tt>,
<tt>PSBT_IN_TAP_INTERNAL_KEY</tt> and <tt>PSBT_IN_TAP_LEA= F_SCRIPT</tt> fields;
the only information signer is needed to recognize which keys it should sig= n
with is from which of the original keys they were generated. This is achiev= ed by
introducing new `PSBT_IN_P2C_TWEAK` field which has the original key as a f= ield
key and the tweak as a field value. The signer will recognize the keys whic= h are
available to it, apply the tweak to them and see in which scripts it was us= ed --
and use this information to apply tweaks for the corresponding private keys= and
produce valid signatures.


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

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 =3D 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 distingui= shed 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 handlin= g
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 remo= ve this field
after <tt>PSBT_IN_PARTIAL_SIG</tt> is constructed.
|
|
| 0, 2
| BIP-P2C
|}


=3D=3DSecurity considerations=3D=3D

The scope of this proposal is deliberately kept narrow; it addresses
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.<ref>'''Why only spending of P2C twe= aked outputs is covered'''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.</= ref>


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

<references/>


=3D=3DCompatibility=3D=3D

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 twe= aked
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 fie= lds
to the PSBT inputs.


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

WIP


=3D=3DAcknowledgements=3D=3D

TBD


=3D=3DTest vectors=3D=3D

TBD


=3D=3DReferences=3D=3D

[1] Ilja Gerhardt, Timo Hanke. Homomorphic Payment Addresses and the
=C2=A0 =C2=A0 Pay-to-Contract Protocol. arXiv:1212.3257 \[cs.CR\]
=C2=A0 =C2=A0 <https://arxiv.org/pdf/1212.3257.pdf>
[2] Eternity Wall's "sign-to-contract" article.
=C2=A0 =C2=A0 <https://blog.eternitywal= l.com/2018/04/13/sign-to-contract/>
[3] Peter Todd. OpenTimestamps: Scalable, Trust-Minimized, Distributed
=C2=A0 =C2=A0 Timestamping with Bitcoin.
=C2=A0 =C2=A0 <https://petertodd.org/2016/o= pentimestamps-announcement>
[4] Adam Back, Matt Corallo, Luke Dashjr, et al. Enabling Blockchain
=C2=A0 =C2=A0 Innovations with Pegged Sidechains (commit5620e43). Appenxix = A.
=C2=A0 =C2=A0 <https://blockstream.com/sidechains.pdf&g= t;;.
[5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key
=C2=A0 =C2=A0 tweaking: collision- resistant elliptic curve-based commitmen= ts.
=C2=A0 =C2=A0 LNPBP-1 Standard.
=C2=A0 =C2=A0 <https://github.com/LNP-B= P/LNPBPs/blob/master/lnpbp-0001.md>
[6] Peter Todd. Single-use-seals. LNPBP-8 Standard.
=C2=A0 =C2=A0 <https://github.com/LNP-B= P/LNPBPs/blob/master/lnpbp-0008.md>

--
Maxim Orlovsky
orlovsky@proto= nmail.com
GitHub: @dr-orlovsky
Twitter: @dr_orlovsky

LNP/BP Standards Association
orlovsky@lnp-bp.or= g
g= ithub.com/LNP-BP





_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000b45d0105d5c0cb23--