Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

BIP372, BIP381: editorial fixups #1740

Merged
merged 2 commits into from
Jan 6, 2025
Merged

BIP372, BIP381: editorial fixups #1740

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
450cdbb
BIP372, BIP381: trivial spelling fixups
HubertIGL Dec 17, 2024
e36714e
BIP372: editorial grammar fixups
jonatack Jan 6, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
64 changes: 32 additions & 32 deletions bip-0372.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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===
Expand All @@ -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
Expand All @@ -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
Expand All @@ -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.
|
Expand All @@ -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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a bit clunky before and after. I suspect "much allow" was supposed to be "must allow", which would be more readable as "would require".

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for taking a look.
@dr-orlovsky what is your intended meaning here?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, it was "must allow" typo. "May allow" is more correct. "Would require" has an opposite meaning

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Happy to be wrong, thanks for chiming in!

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==
Expand All @@ -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,
Expand All @@ -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.


Expand All @@ -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.


Expand All @@ -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.
Expand Down
2 changes: 1 addition & 1 deletion bip-0381.mediawiki
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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==
Expand Down
Loading