From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4587CC0012 for ; Fri, 1 Apr 2022 08:32:50 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 00F0683E17 for ; Fri, 1 Apr 2022 08:32:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hGB81MaAk5n for ; Fri, 1 Apr 2022 08:32:47 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.osuosl.org (Postfix) with ESMTPS id 7E89E83385 for ; Fri, 1 Apr 2022 08:32:47 +0000 (UTC) Date: Fri, 01 Apr 2022 08:32:36 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1648801964; bh=aTl2sh/OGzhpopvsHyjGiAnhORf6Nnog2YzCT8g1xdk=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; b=AFOfg7wPupe/KR/dU88E8C+5GX4k8GlfyU74cAMABl5kZtPFc6BxCb1ibU3pxo1gK uI7YjkcsYAXm4Qm8EG+mCNRtfQUwrWCMj1C++vAM/WjEui/VG2jNR5Bux6qu3+8kRz alhFBpij2z9xxPkeBUlTdSAcn7YkG0E60Yh9XbDOwEi/Bw1SMdWyaCacqsnfKoNB+g ZFejc/B9U+Xq4EvN8NHr14XlZpakn7QWrQKkMG23l2tu9ioacq5IxLJxCG3h5R8gfv Kp8+bxD3oH7KpZ1iplpvHR4GhvyWtNMwHWHckLy5iUg3yG1KyrJ/w0aHRq5SNnmdmv FkXaxmwgzJpHw== To: bitcoin-dev@lists.linuxfoundation.org From: Dr Maxim Orlovsky Reply-To: Dr Maxim Orlovsky Message-ID: <98aa80558c23d2a476bdf7b0cd7dc7de7f2d7412.camel@protonmail.com> In-Reply-To: <89d7d76698de12dd7fdb8185130f4ace3bee9ef8.camel@protonmail.com> References: <89d7d76698de12dd7fdb8185130f4ace3bee9ef8.camel@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 01 Apr 2022 08:53:54 +0000 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: Fri, 01 Apr 2022 08:32:50 -0000 Hi Jeremy, Thank you for your reply. P2C tweaks are unrelated to BIP32 derivations and can't be mixed with BIP32 derivation paths. Specifically, P2C commitments c= an't be relying on extended key chain code, which should be not known to the verifyer. Thus, P2C is incompatible with BIP32 CDK. Kind regards, Maxim Orlovsky On Sun, 2022-01-16 at 17:41 +0000, Dr Maxim Orlovsky 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 suggestin= g > 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 i= nput > 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
>
> > =3D=3DIntroduction=3D=3D > > =3D=3D=3DAbstract=3D=3D=3D > > This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 P= SBTv2 > 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 req= uired > 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 so= me > 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 priva= te > 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 fo= r 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-sea= ls > [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 > about > P2C tweak applied to the public key. In order to produce a valid signatur= e, > the > same tweak value must be added (modulo group order) to the original priva= te > key > by a signer device. This represents a channelge for external signers, whi= ch > may > not have any information about such commitment. This proposal addresses t= his > 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, incl= uding > bare scripts and P2PK, P2PKH, P2SH, witness v0 P2WPKH, P2WSH, nested witn= ess > v0 > P2WPKH-P2SH, P2WSH-P2SH and witness v1 P2TR outputs. > > > =3D=3DDesign=3D=3D > > 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 fi= elds; > the only information signer is needed to recognize which keys it should s= ign > with is from which of the original keys they were generated. This is achi= eved > 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 wh= ich > 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 ke= ys > and > produce valid signatures. > > > =3D=3DSpecification=3D=3D > > 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 =3D 0x19 > > > > 33 bytes of compact public key serialization specifying to which of key= s the > P2C tweak may be applied (i.e. this MUST be a value of a public key befor= e the > tweak is applied). BIP-340 keys are serialized by appending `02` > byte.'''Why compressed public keys are not distinguished from BIP-34= 0 > 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 inpu= t > type, > and adding additional PSBT field type will just create the need for handl= ing > 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 corre= ct > ECDSA and/or Schnorr signature ("key tweak"). Signers SHOULD remove this = field > after PSBT_IN_PARTIAL_SIG 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 > addresses construction of a new P2C commitments or transactions containin= g > 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 forma= ts > 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. > > > =3D=3DRationale=3D=3D > > > > > =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 > 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 output= s may > not be supported or covered by this BIP and may require addition of new f= ields > 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 > 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 > > > >