From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id ABF91C002F for ; Sun, 16 Jan 2022 17:41:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 865FC80C81 for ; Sun, 16 Jan 2022 17:41:33 +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_H3=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 aVhzXIeD8tyx for ; Sun, 16 Jan 2022 17:41:32 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4322.protonmail.ch (mail-4322.protonmail.ch [185.70.43.22]) by smtp1.osuosl.org (Postfix) with ESMTPS id 3CE1280C31 for ; Sun, 16 Jan 2022 17:41:32 +0000 (UTC) Date: Sun, 16 Jan 2022 17:41:22 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1642354888; bh=wdqgh3GitZciwp6dnNfEJocjoNWotHA/aqnuJfhfTSo=; h=Date:To:From:Reply-To:Subject:Message-ID:From:To:Cc; b=mzAn3LZYq0eQsE/pZqNN8lqvpW/BYl94ZYXiWj8pRnG7x4EutgvoZgyyERLJVQmT/ iaHRgEFV3pa9BPjAOgu8ty33RRUwW43aU41yw57zdF711bttrBh5C4x90xSIOa9gde DDEjWpPZfXB0RzsaAphF6EtiUKMMcQ0RwhwKe7ZwnrvwcYs2GDu+5EIQ8aPGJDaOCj exr11aXV1X50fjKbyX2wI5RnOJcJDpkovJyGQ0LW4+AZVjsL3t4zEulHTqi45dNNoa 2z4VJNDC2j8+G6wuWZObEtu/3pf2dLYyGrKjjKnDOTZ9DxkldgxJcRTJ/r9txxcZMa hTpFlDxKWlSUA== To: bitcoin-dev@lists.linuxfoundation.org From: Dr Maxim Orlovsky Reply-To: Dr Maxim Orlovsky Message-ID: <89d7d76698de12dd7fdb8185130f4ace3bee9ef8.camel@protonmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 16 Jan 2022 20:59:37 +0000 Subject: [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: Sun, 16 Jan 2022 17:41:33 -0000 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://git= hub.com/bitcoin/bips/pull/1239. Specifically, it adds a PSBT input field fo= r inputs spending UTXOs with previously created pay-to-contract (P2C) publi= c 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 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-seals= [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 scriptPubkey, includ= ing 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 PSBT_IN_REDEEM_SCRIPT, PSBT_IN_WITNESS_SCRIPT, PSBT_IN_TAP_INTERNAL_KEY and PSBT_IN_TAP_LEAF_SCRIPT fiel= ds; 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 ! ! ! 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 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 handlin= g 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 fi= eld 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 a= ddresses construction of a new P2C commitments or transactions containing t= hem in their outputs.'''Why only spending of P2C tweaked outputs is co= vered'''P2C tweaks commit to external data, some of which may represent cer= tain value (like in some sidechains, single-use-seal applications like RGB = etc). Creation of such outputs much allow hardware devices to understand th= e structure of such extra-transaction data, which may be in different forma= ts and constantly involve. Thus, this should be addresses with a separate s= tandards (or be a vendor-based). The current proposal only touches the ques= tion of spending an output which contained previously created P2C commitmen= t, 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 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 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