1
0
mirror of https://github.com/bitcoin/bips.git synced 2025-05-12 12:03:29 +00:00

fix witness program -> witness

This commit is contained in:
Karl-Johan Alm 2018-09-12 16:21:59 +09:00
parent b925137d5f
commit 2f152773e6
No known key found for this signature in database
GPG Key ID: 57AF762DB3353322

View File

@ -21,7 +21,7 @@ The current message signing standard only works for P2PKH (1...) addresses. By e
== Specification == == Specification ==
A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witnessProgram container. A new structure <code>SignatureProof</code> is added, which is a simple serializable scriptSig & witness container.
Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds". Two actions "Sign" and "Verify" are defined along with two *purposes* "SignMessage" and "ProveFunds".
@ -56,9 +56,9 @@ The above is followed by [entries] number of signature entries:
|- |-
|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data |Uint8*||[scriptsiglen]||scriptsig||ScriptSig data
|- |-
|VarInt||1-8||witlen||Number of bytes in witness program data |VarInt||1-8||witlen||Number of bytes in witness data
|- |-
|Uint8*||[witlen]||wit||Witness program |Uint8*||[witlen]||wit||Witness
|} |}
In some cases, the scriptsig or wit may be empty. If both are empty, the proof is incomplete. 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.
|- |-
|INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof. |INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof.
|- |-
|INCONCLUSIVE||One or several of the given proofs used unknown opcodes or witness versions, perhaps due to the verifying node being outdated. |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.
|- |-
|VALID||All proofs were deemed valid. |VALID||All proofs were deemed valid.
|- |-
@ -87,13 +87,13 @@ A verification call will return a result code according to the table below.
== Signing and Verifying == == Signing and Verifying ==
Let there be an empty set inputs which is populated and tested at each call to one of the actions below. Let there be an empty set `inputs` which is populated and tested at each call to one of the actions below.
=== Purpose: SignMessage === === Purpose: SignMessage ===
The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated. The "SignMessage" purpose generates a sighash based on a scriptPubKey and a message. It emits a VALID verification result code unless otherwise stated.
# 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> # 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>
# Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD) # Define the message pre-image as the sequence "Bitcoin Message:" concatenated with the message, encoded in UTF-8 using Normalization Form Compatibility Decomposition (NFKD)
# Let sighash = sha256(sha256(scriptPubKey || pre-image)) # Let sighash = sha256(sha256(scriptPubKey || pre-image))
@ -102,7 +102,7 @@ The "SignMessage" purpose generates a sighash based on a scriptPubKey and a mess
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. 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.
# Let txid be the transaction ID of the transaction, and vout be the output index corresponding to the index of the output being spent # Let txid be the transaction ID of the transaction, and vout be the output index corresponding to the index of the output being spent
# Return INVALID if the txid:vout pair already exists in inputs set, otherwise insert it # Return INVALID if the txid:vout pair already exists in `inputs` set, otherwise insert it
# 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> # 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>
# Extract scriptPubKey from transaction output # Extract scriptPubKey from transaction output
# 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> # 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.
=== Action: Verify === === Action: Verify ===
The "Verify" action takes as input a standard flags value, a script sig, an optional witness program, and a purpose. The "Verify" action takes as input a standard flags value, a script sig, an optional witness, and a purpose.
It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR. It emits one of INCONCLUSIVE, VALID, INVALID, or ERROR.
# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID # Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID
# If one or more of the standard flags are unknown, return INCONCLUSIVE # If one or more of the standard flags are unknown, return INCONCLUSIVE
# Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness program, and sighash=sighash # Verify Script with flags=standard flags, scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
# Return VALID if verify succeeds, otherwise return INVALID # Return VALID if verify succeeds, otherwise return INVALID
=== Multiple Proofs === === Multiple Proofs ===