Skip to content

Commit 2f15277

Browse files
committed
fix witness program -> witness
1 parent b925137 commit 2f15277

File tree

1 file changed

+9
-9
lines changed

1 file changed

+9
-9
lines changed

bip-0322.mediawiki

Lines changed: 9 additions & 9 deletions
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ The current message signing standard only works for P2PKH (1...) addresses. By e
2121

2222
== Specification ==
2323

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.
2525

2626
Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds".
2727

@@ -56,9 +56,9 @@ The above is followed by [entries] number of signature entries:
5656
|-
5757
|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data
5858
|-
59-
|VarInt||1-8||witlen||Number of bytes in witness program data
59+
|VarInt||1-8||witlen||Number of bytes in witness data
6060
|-
61-
|Uint8*||[witlen]||wit||Witness program
61+
|Uint8*||[witlen]||wit||Witness
6262
|}
6363

6464
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.
7474
|-
7575
|INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof.
7676
|-
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.
7878
|-
7979
|VALID||All proofs were deemed valid.
8080
|-
@@ -87,13 +87,13 @@ A verification call will return a result code according to the table below.
8787

8888
== Signing and Verifying ==
8989

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.
9191

9292
=== Purpose: SignMessage ===
9393

9494
The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated.
9595

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>
9797
# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD)
9898
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
9999
@@ -102,7 +102,7 @@ The "SignMessage" purpose generates a sighash based on a scriptPubKey and a mess
102102
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.
103103

104104
# 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
106106
# 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>
107107
# Extract scriptPubKey from transaction output
108108
# 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.
121121
122122
=== Action: Verify ===
123123

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.
125125
It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR.
126126

127127
# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID
128128
# 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
130130
# Return VALID if verify succeeds, otherwise return INVALID
131131
132132
=== Multiple Proofs ===

0 commit comments

Comments
 (0)