BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c)

BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c)
2022-01-17  5:55 ` Jeremy
  2022-04-01  8:32 ` Dr Maxim Orlovsky
  
From: Dr Maxim Orlovsky @ 2022-01-16 17:41 UTC (permalink / raw)
  To: bitcoin-dev

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@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>

==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@protonmail•com
GitHub: @dr-orlovsky
Twitter: @dr_orlovsky

LNP/BP Standards Association
orlovsky@lnp-bp•org
github.com/LNP-BP







 permalink raw reply	[|nested]
2022-01-16 17:41 [bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) Dr Maxim Orlovsky

  2022-04-01  8:32 ` Dr Maxim Orlovsky
  
From: Jeremy @ 2022-01-17  5:55 UTC (permalink / raw)
  To: Dr Maxim Orlovsky, Bitcoin Protocol Discussion

[-- Attachment #1: Type: text/plain, Size: 10120 bytes --]

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@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@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>
>
> ==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@protonmail•com
> GitHub: @dr-orlovsky
> Twitter: @dr_orlovsky
>
> LNP/BP Standards Association
> orlovsky@lnp-bp•org
> github.com/LNP-BP
>
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 14303 bytes --]

 permalink raw reply	[|nested]
2022-01-16 17:41 [bitcoin-dev] BIP proposal: Pay-to-contract tweak fields for PSBT (bip-psbt-p2c) Dr Maxim Orlovsky
  2022-01-17  5:55 ` Jeremy

  
From: Dr Maxim Orlovsky @ 2022-04-01  8:32 UTC (permalink / raw)
  To: bitcoin-dev

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 can'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 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@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>
>
> ==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@protonmail•com
> GitHub: @dr-orlovsky
> Twitter: @dr_orlovsky
>
> LNP/BP Standards Association
> orlovsky@lnp-bp•org
> github.com/LNP-BP
>
>
>
>




 permalink raw reply	[|nested]