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
+9-9Lines changed: 9 additions & 9 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -21,7 +21,7 @@ The current message signing standard only works for P2PKH (1...) addresses. By e
21
21
22
22
== Specification ==
23
23
24
-
A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witnessProgram container.
24
+
A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witness container.
25
25
26
26
Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds".
27
27
@@ -56,9 +56,9 @@ The above is followed by [entries] number of signature entries:
56
56
|-
57
57
|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data
58
58
|-
59
-
|VarInt||1-8||witlen||Number of bytes in witness program data
59
+
|VarInt||1-8||witlen||Number of bytes in witness data
60
60
|-
61
-
|Uint8*||[witlen]||wit||Witness program
61
+
|Uint8*||[witlen]||wit||Witness
62
62
|}
63
63
64
64
In some cases, the scriptsig or wit may be empty. If both are empty, the proof is incomplete.
@@ -74,7 +74,7 @@ A verification call will return a result code according to the table below.
74
74
|-
75
75
|INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof.
76
76
|-
77
-
|INCONCLUSIVE||One or several of the given proofs used unknown opcodes or witness versions, perhaps due to the verifying node being outdated.
77
+
|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.
78
78
|-
79
79
|VALID||All proofs were deemed valid.
80
80
|-
@@ -87,13 +87,13 @@ A verification call will return a result code according to the table below.
87
87
88
88
== Signing and Verifying ==
89
89
90
-
Let there be an empty set inputs which is populated and tested at each call to one of the actions below.
90
+
Let there be an empty set `inputs` which is populated and tested at each call to one of the actions below.
91
91
92
92
=== Purpose: SignMessage ===
93
93
94
94
The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated.
95
95
96
-
# Return INVALID if scriptPubKey already exists in inputs set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 inputs unless they are all distinct</ref>
96
+
# Return INVALID if scriptPubKey already exists in `inputs` set, otherwise insert it<ref><strong>Why track duplicates?</strong> Because a 3-entry proof is not proving 3 inputs unless they are all distinct</ref>
97
97
# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD)
98
98
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
99
99
@@ -102,7 +102,7 @@ The "SignMessage" purpose generates a sighash based on a scriptPubKey and a mess
102
102
The "ProveFunds" purpose generates a sighash and a scriptPubKey from a transaction, an output index, and a message. For multiple simultaneous proofs, it also requires access to the ordered list of proofs. It emits a VALID verification result code unless otherwise stated.
103
103
104
104
# Let txid be the transaction ID of the transaction, and vout be the output index corresponding to the index of the output being spent
105
-
# Return INVALID if the txid:vout pair already exists in inputs set, otherwise insert it
105
+
# Return INVALID if the txid:vout pair already exists in `inputs` set, otherwise insert it
106
106
# Return SPENT if the txid/vout is not a valid UTXO according to a Bitcoin node<ref><strong>Synced up or not?</strong> A normal verifier would use a synced up node. An auditor checking records from a client that were submitted in the past want to use a node that is synced up to the block corresponding to the proof, or the proof will fail, even if it may have been valid at the time of creation.</ref>
107
107
# Extract scriptPubKey from transaction output
108
108
# Define the message pre-image as the concatenation of the following components:<ref><strong>Why not just the UTXO data?</strong> We want the verifier to be able to challenge the prover with a custom message to sign, or anyone can reuse the POF proof for a set of UTXO:s once they have seen it, and the funds have not yet been spent</ref>
@@ -121,12 +121,12 @@ The "Sign" action takes as input a purpose. It returns a signature or fails.
121
121
122
122
=== Action: Verify ===
123
123
124
-
The "Verify" action takes as input a standard flags value, a script sig, an optional witness program, and a purpose.
124
+
The "Verify" action takes as input a standard flags value, a script sig, an optional witness, and a purpose.
125
125
It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR.
126
126
127
127
# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID
128
128
# If one or more of the standard flags are unknown, return INCONCLUSIVE
129
-
# Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness program, and sighash=sighash
129
+
# Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
130
130
# Return VALID if verify succeeds, otherwise return INVALID
0 commit comments