path: root/3f/4a78aea25221ce1f333e41139f031582776e15

Return-Path: <orlovsky@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id ABF91C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <orlovsky@protonmail.com>
Reply-To: Dr Maxim Orlovsky <orlovsky@protonmail.com>
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 <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: 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.


-----------------------------------------------------------------------

<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 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 <tt>scriptPubkey</tt>, 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
<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> 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
! <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 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.</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 fi=
eld
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 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.</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
    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