You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: bip-0322.mediawiki
+66-31Lines changed: 66 additions & 31 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -34,7 +34,7 @@ Two actions "Sign" and "Verify" are defined along with one ''purpose'', "SignMes
34
34
!Name
35
35
!Comment
36
36
|-
37
-
|Uint32||4||flags||standard flags (1-to-1 with standard flags in Bitcoin Core)
37
+
|Uint32||4||version||BIP322 version format; must be equal to 1; if > 1, verifier must abort the verification process
38
38
|-
39
39
|Uint8||1||entries||number of proof entries<ref><strong>Why support multiple proofs?</strong> It is non-trivial to check a large number of individual proofs for duplicates. Software could be written to do so, but it seems more efficient to build this check into the specification itself.</ref>
40
40
|}
@@ -70,7 +70,7 @@ A verification call will return a result code according to the table below.
70
70
|-
71
71
|INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof.
72
72
|-
73
-
|INCONCLUSIVE||One or several of the given proofs used unknown opcodes or the scriptPubKey had an unknown witness version, perhaps due to the verifying node being outdated.
73
+
|INCONCLUSIVE||One or several of the given proofs was consensus-valid but policy-invalid.
74
74
|-
75
75
|VALID||All proofs were deemed valid.
76
76
|-
@@ -81,7 +81,7 @@ A verification call will return a result code according to the table below.
81
81
82
82
== Signing and Verifying ==
83
83
84
-
If the challenge consists of a single address and the address is in the P2PK(H) (legacy) format, sign using the legacy format (further information below). Otherwise continue as stated below.
84
+
If the challenge consists of a single address and the address is in the P2PKH (legacy) format, sign using the legacy format (further information below). Otherwise continue as stated below.
85
85
86
86
Let there be an empty set <code>inputs</code> which is populated and tested at each call to one of the actions below.
87
87
@@ -90,7 +90,7 @@ Let there be an empty set <code>inputs</code> which is populated and tested at e
90
90
The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated.
91
91
92
92
# Return INVALID if scriptPubKey already exists in <code>inputs</code> set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 entries unless they are all distinct</ref>
93
-
# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD)
93
+
# Define the message pre-image as the sequence "Bitcoin Signed Message:\n" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD)
94
94
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
95
95
96
96
A private key may be used directly to sign a message. In this case, its P2WPKH bech32 address shall be derived, and used as the input.
@@ -111,9 +111,10 @@ The "Verify" action takes as input a standard flags value, a script sig, an opti
111
111
It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR.
112
112
113
113
# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID
114
-
# If one or more of the standard flags are unknown, return INCONCLUSIVE
115
-
# Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
116
-
# Return VALID if verify succeeds, otherwise return INVALID
114
+
# Verify Script with flags=consensus flags (currently P2SH, DERSIG, NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
115
+
# Return INVALID if verification fails
116
+
# Verify Script with flags=standard flags (above plus STRICTENC, MINIMALDATA, etc.), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
117
+
# Return VALID if verification succeeds, otherwise return INCONCLUSIVE
117
118
118
119
=== Multiple Proofs ===
119
120
@@ -130,29 +131,30 @@ Note that the order of the entries in the proof must match the order of the entr
130
131
131
132
== Legacy format ==
132
133
133
-
The legacy format is restricted to the legacy P2PK(H) address format, and restricted to one single challenge (address).
134
+
The legacy format is restricted to the legacy P2PKH address format, and restricted to one single challenge (address).
134
135
135
-
Any other input (e.g. multiple addresses, or non-P2PK(H) address format(s)) must be signed using the new format described above.
136
+
Any other input (e.g. multiple addresses, or non-P2PKH address format(s)) must be signed using the new format described above.
136
137
137
138
=== Signing ===
138
139
139
-
Given the P2PK(H) address <code>a</code> and the message <code>m</code>:
140
-
# let <code>p</code> be the pubkey-hash contained in <code>a</code>
141
-
# let <code>x</code> be the private key associated with <code>p</code>
140
+
Given the P2PKH address <code>a</code> and the message <code>m</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>:
141
+
142
+
# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code>
143
+
# let <code>x</code> be the private key associated with <code>P</code> so that <code>pkh(xG) = p</code>
142
144
# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code>
143
145
# create a compact signature <code>sig</code> (aka "recoverable ECDSA signature") using <code>x</code> on <code>digest</code>
144
146
145
147
The resulting proof is <code>sig</code>, serialized using the base64 encoding.
146
148
147
149
=== Verifying ===
148
150
149
-
Given the P2PK(H) address <code>a</code>, the message <code>m</code>, and the compact signature <code>sig</code>:
151
+
Given the P2PKH address <code>a</code>, the message <code>m</code>, the compact signature <code>sig</code>, and the pubkey-hash function <code>pkh(P) = ripemd160(sha256(P))</code>:
150
152
151
-
# let <code>p</code> be the pubkey-hash contained in <code>a</code>
153
+
# let <code>p</code> be the pubkey-hash <code>pkh(P)</code> for the pubkey <code>P</code>, contained in <code>a</code>
152
154
# let <code>digest</code> be <code>SHA56d("Bitcoin Signed Message:\n"||m)</code>
153
155
# attempt pubkey recovery for <code>digest</code> using the signature <code>sig</code> and store the resulting pubkey into <code>Q</code>
154
156
## fail verification if pubkey recovery above fails
155
-
# let <code>q</code> be the pubkey-hash of <code>Q</code>
157
+
# let <code>q</code> be the pubkey-hash <code>pkh(Q)</code> for the pubkey <code>Q</code>
156
158
# if <code>p == q</code>, the proof is valid, otherwise it is invalid
157
159
158
160
== Compatibility ==
@@ -179,17 +181,50 @@ Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many oth
179
181
180
182
This document is licensed under the Creative Commons CC0 1.0 Universal license.
181
183
184
+
== Consensus and standard flags ==
185
+
186
+
Each flag is associated with some type of enforced rule (most often a soft fork). There are two sets of flags: consensus flags (which result in a block being rejected, if violated), and policy flags (which result in a transaction being accepted only if it is contained within an actual block, and rejected otherwise, if violated). The policy flags are a super-set of the consensus flags.
187
+
188
+
BIP322 specifies that a proof that validates for both rulesets is valid, a proof that validates for consensus rules, but not for policy rules, is "inconclusive", and a proof that does not validate for consensus rules is "invalid" (regardless of policy rule validation).
189
+
190
+
The ruleset sometimes changes. This BIP does not intend to be complete, nor does it indicate enforcement of rules, it simply lists the rules as they stand at the point of writing.
0 commit comments