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
+31-32Lines changed: 31 additions & 32 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -23,9 +23,9 @@ The current message signing standard only works for P2PKH (1...) addresses. By e
23
23
24
24
A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witness container.
25
25
26
-
=== Common Header ===
26
+
Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds".
27
27
28
-
A common header used for signature proofs and challenges is defined as follows:
28
+
=== SignatureProof container ===
29
29
30
30
{|class="wikitable" style="text-align: center;"
31
31
|-
@@ -43,9 +43,7 @@ A common header used for signature proofs and challenges is defined as follows:
43
43
|Uint8||1||entries||Number of proof entries<ref><strong>Why support multiple proofs?</strong> In particular with proof of funds, it is non-trivial to check a large number of individual proofs (one per UTXO) for duplicates. Software could be written to do so, but it seems more efficient to build this check into the specification itself.</ref>
44
44
|}
45
45
46
-
=== SignatureProof container ===
47
-
48
-
The signature proof begins with a common header, and is followed by [entries] number of signature entries:
46
+
The above is followed by [entries] number of signature entries:
49
47
50
48
{|class="wikitable" style="text-align: center;"
51
49
|-
@@ -82,53 +80,54 @@ A verification call will return a result code according to the table below.
82
80
|-
83
81
|INVALID||One or more of the given proofs were invalid
84
82
|-
83
+
|SPENT||One or more of the claimed UTXO:s has been spent
84
+
|-
85
85
|ERROR||An error was encountered
86
86
|}
87
87
88
-
=== SignMessage serialization ===
88
+
== Signing and Verifying ==
89
89
90
-
The SignMessage challenge begins with the common header, and is followed by [entries] entries:
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
-
{|class="wikitable" style="text-align: center;"
93
-
|-
94
-
!Type
95
-
!Length
96
-
!Name
97
-
!Comment
98
-
|-
99
-
|VarInt||1-8||spklen||ScriptPubKey length
100
-
|-
101
-
|Uint8*||[spklen]||spk||ScriptPubKey
102
-
|}
92
+
=== Purpose: SignMessage ===
103
93
104
-
=== Proving and Verifying ===
94
+
The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated.
105
95
106
-
Let there be an empty set <code>inputs</code> which is populated and tested at each call to one of the actions below.
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
+
# 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
+
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
107
99
108
-
===Common steps===
100
+
===Purpose: ProveFunds===
109
101
110
-
A sighash is generated based on a scriptPubKey and a message. A VALID verification result code is emitted unless otherwise stated.
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.
111
103
112
-
# Emits 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 inputs unless they are all distinct</ref>
113
-
# Emits INVALID if the message is not a UTF-8 string encoded using Normalization Form Compatibility Decomposition (NFKD); note specifically that binary messages are not supported
114
-
# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, ''excluding'' the null terminating character (if any)
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
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
+
# Extract scriptPubKey from transaction output
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>
109
+
#* the string "POF:"
110
+
#* the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD), including the null terminating character (i.e. write strlen(message) + 1 bytes, for a C string)
111
+
#* all transactions being proven for, as binary txid (little endian uint256) followed by index (little endian uint32), each separated by a single `0x00` byte
115
112
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
116
113
117
-
===Proving===
114
+
===Action: Sign===
118
115
119
-
Returns a signature or fails (emits INVALID).
116
+
The "Sign" action takes as input a purpose. It returns a signature or fails.
120
117
118
+
# Obtain the sighash and scriptPubKey from the purpose; FAIL if not VALID
121
119
# Derive the private key privkey for the scriptPubKey; FAIL if not VALID
122
-
# Generate a signature sig with privkey=privkey, sighash=sighash
123
-
# Return a SignatureProof container with the given signature
120
+
# Generate and return a signature sig with privkey=privkey, sighash=sighash
124
121
125
-
===Verifying===
122
+
===Action: Verify===
126
123
127
-
Emits one of INCONCLUSIVE, VALID, or INVALID.
124
+
The "Verify" action takes as input a standard flags value, a script sig, an optional witness, and a purpose.
125
+
It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR.
128
126
127
+
# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID
129
128
# If one or more of the standard flags are unknown, return INCONCLUSIVE
130
129
# Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
131
-
# Emit VALID if verify succeeds, otherwise emit INVALID
130
+
# Return VALID if verify succeeds, otherwise return INVALID
0 commit comments