diff options
| -rw-r--r-- | bip-0372.mediawiki | 64 | ||||
| -rw-r--r-- | bip-0381.mediawiki | 2 |
2 files changed, 33 insertions, 33 deletions
diff --git a/bip-0372.mediawiki b/bip-0372.mediawiki index ee40dd0..4f10c34 100644 --- a/bip-0372.mediawiki +++ b/bip-0372.mediawiki @@ -17,8 +17,8 @@ ===Abstract=== This document proposes additional fields for BIP 174 PSBTv0 and BIP 370 PSBTv2 -that allow for pay-to-contract key tweaking data to be included in a PSBT -of any version. These will represent an extra-transaction information required +that allow for pay-to-contract (P2C) key tweaking data to be included in a PSBT +of any version. These will represent extra-transaction information required for the signer to produce valid signatures spending previous outputs. ===Copyright=== @@ -27,33 +27,33 @@ This BIP is licensed under the 2-clause BSD license. ===Background=== -Key tweaking is a procedure for creating a cryptographic commitment to some +Key tweaking is a procedure for creating a cryptographic commitment to a 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 +This produces a tweaked public key containing the commitment. Later, in order +to spend an output containing the 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] +[2] for the same purpose. Since that time, multiple different protocols for P2C +have been developed, including OpenTimeStamps [3], Elements sidechain P2C tweaks +[4] and LNPBP-1 [5], used 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 knows 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 +not only knows the corresponding original private key, but also is aware of +a 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 challenge 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 +The proposal abstracts details of specific P2C protocols and provides a universal method for spending previous outputs 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 @@ -67,7 +67,7 @@ P2C-tweaked public keys are already exposed in the <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 +introducing a 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 @@ -92,16 +92,16 @@ The new per-input type is defined as follows: | 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 +| 33 bytes of compact public key serialization specifying to which 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 +public keys''' We follow the logic of BIP32 key derivation, which does not +distinguish them. The type of the key is defined by the input type, +and adding additional PSBT field types 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 +| The 32 byte value which MUST be added to a private key to produce a correct ECDSA and/or Schnorr signature ("key tweak"). Signers SHOULD remove this field after <tt>PSBT_IN_PARTIAL_SIG</tt> is constructed. | @@ -115,17 +115,17 @@ after <tt>PSBT_IN_PARTIAL_SIG</tt> is constructed. 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 +address construction of 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 +P2C tweaks commit to external data, some of which may represent certain values +(like in some sidechains, single-use-seal applications like RGB, etc). Creation +of such outputs may 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 +evolve. Thus, this should be addressed with separate standards (or be 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> +output that contained a previously created P2C commitment, which does not create +a new commitment and does not provide that kind of risk of extra-blockchain +value losses.</ref> ==Rationale== @@ -136,10 +136,10 @@ value loses.</ref> ==Compatibility== The proposal is compatible with the existing consensus rules and does not -require any of their modifications. +require any modification to them. -The proposed P2C PSBT fields provides sufficient information for creating a -valid signatures for spendings of the following output types containing tweaked +The proposed P2C PSBT fields provide sufficient information for creating +valid signatures for spending the following output types containing tweaked public keys: - bare scripts, - P2PK, @@ -149,7 +149,7 @@ public keys: - nested witness v0 P2WPKH-P2SH and P2WSH-P2SH, Post-0 witness versions, including taproot outputs and future witness versions, -may not be supported or covered by this BIP and may require addition of new +may not be supported or covered by this BIP and may require the addition of new fields to the PSBT inputs. @@ -160,8 +160,8 @@ WIP ==Acknowledgements== -Author is grateful to Andrew Poelstra, who provided an initial set of ideas -and information on his previous work on the topic basing on which this standard +The author is grateful to Andrew Poelstra, who provided an initial set of ideas +and information with his previous work on the topic, on which this standard was designed. @@ -181,7 +181,7 @@ TBD 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. + Innovations with Pegged Sidechains (commit5620e43). Appendix A. <https://blockstream.com/sidechains.pdf>;. [5] Maxim Orlovsky, Rene Pickhardt, Federico Tenga, et al. Key tweaking: collision- resistant elliptic curve-based commitments. diff --git a/bip-0381.mediawiki b/bip-0381.mediawiki index 8d12c7a..f2bb8aa 100644 --- a/bip-0381.mediawiki +++ b/bip-0381.mediawiki @@ -111,7 +111,7 @@ Invalid descriptors * <tt>pk()</tt> only accepts key expressions: <tt>pk(pk(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> * <tt>pkh()</tt> only accepts key expressions: <tt>pkh(pk(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd))</tt> -* <tt>sh()</tt> only acceps script expressions: <tt>sh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> +* <tt>sh()</tt> only accepts script expressions: <tt>sh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)</tt> * <tt>sh()</tt> is top level only: <tt>sh(sh(pkh(03a34b99f22c790c4e36b2b3c2c35a36db06226e41c692fc82b8b56ac1c540c5bd)))</tt> ==Backwards Compatibility== |