[bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c)
Jeremy
jlrubin at mit.edu
Mon Jan 17 05:55:00 UTC 2022
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 <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>
On Sun, Jan 16, 2022 at 1:00 PM Dr Maxim Orlovsky via bitcoin-dev <
bitcoin-dev at 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.
>
>
> -----------------------------------------------------------------------
>
> <pre>
> BIP: ?
> Layer: Applications
> Title: Pay-to-contract tweak fields for PSBT
> Author: Maxim Orlovsky <orlovsky at lnp-bp.org>,
> Andrew Poelstra <apoelstra at wpsoftware.net>
> Discussions-To: <bitcoin-dev at 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>
>
> ==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 <tt>scriptPubkey</tt>,
> 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
> <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>
> 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
> ! <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 = 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
> handling
> 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
> field
> after <tt>PSBT_IN_PARTIAL_SIG</tt> 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.<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 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.</ref>
>
>
> ==Rationale==
>
> <references/>
>
>
> ==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\]
> <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 at protonmail.com
> GitHub: @dr-orlovsky
> Twitter: @dr_orlovsky
>
> LNP/BP Standards Association
> orlovsky at lnp-bp.org
> github.com/LNP-BP
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220116/f4204300/attachment-0001.html>
More information about the bitcoin-dev
mailing list