path: root/60/345d0f99a8757509a258fee10ce5c932e12f9c

Return-Path: <orlovsky@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 4587CC0012
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <orlovsky@protonmail.com>
Reply-To: Dr Maxim Orlovsky <orlovsky@protonmail.com>
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 <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: 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.
>
>
> -----------------------------------------------------------------------
>
> <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>
>
> =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 <tt>scriptPubkey</tt>, 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
> <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> 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
> ! <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 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.<ref>'''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.</ref>
> > <tt><tweak></tt>
> > 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 <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
> addresses construction of a new P2C commitments or transactions containin=
g
> 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 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.</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
> 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\]
>     <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
>
>
>
>