Merge pull request bitcoin#903 from kallewoof/2003-bip322-simplified

bip-322: simplify proposal to single proof case

Author: luke-jr

bip-0322.mediawiki

@@ -34,24 +34,8 @@ The current message signing standard only works for P2PKH (1...) addresses. By e
 
 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 one ''purpose'', "SignMessage", with the ability to expand in the future to add a potential "ProveFunds" purpose.
-
 === SignatureProof container ===
 
-{|class="wikitable" style="text-align: center;"
-|-
-!Type
-!Length
-!Name
-!Comment
-|-
-|Uint32||4||version||BIP322 version format; must be equal to 1; if > 1, verifier must abort the verification process
-|-
-|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>
-|}
-
-The above is followed by [entries] number of signature entries:
-
 {|class="wikitable" style="text-align: center;"
 |-
 !Type
@@ -79,74 +63,51 @@ A verification call will return a result code according to the table below.
 !Code
 !Description
 |-
-|INCOMPLETE||One or several of the given challenges had an empty proof. The prover may need some other entity to complete the proof.
+|INCOMPLETE||Empty proof.
 |-
-|INCONCLUSIVE||One or several of the given proofs was consensus-valid but policy-invalid.
+|INCONCLUSIVE||The given proof was consensus-valid but policy-invalid.
 |-
-|VALID||All proofs were deemed valid.
+|VALID||The proof was valid.
 |-
-|INVALID||One or more of the given proofs were invalid
+|INVALID||The proof was invalid
 |-
 |ERROR||An error was encountered
 |}
 
 == Signing and Verifying ==
 
-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.
+If the challenge consists of an address is in the P2PKH (legacy) format, sign using the legacy format (further information below). Otherwise continue as stated below.
 
-Let there be an empty set <code>inputs</code> which is populated and tested at each call to one of the actions below.
+For both cases, generate a sighash based on the given scriptPubKey and message as follows:
 
-=== 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.
-
-# 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>
 # 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)
 # Let sighash = sha256(sha256(scriptPubKey || pre-image))
 
 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.
 
-=== Action: Sign ===
+=== Signing ===
 
-The "Sign" action takes as input a purpose. It returns a signature or fails.
+The signature is generated as follows:
 
-# Obtain the sighash and scriptPubKey from the purpose; FAIL if not VALID
 # Derive the private key privkey for the scriptPubKey; FAIL if not VALID
 # Generate and return a signature sig with privkey=privkey, sighash=sighash
 
-The resulting signature proof should be encoded using base64 encoding.
-
-=== Action: Verify ===
+=== Verifying ===
 
-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.
+Verify a proof, given a standard flags value, a script sig, an optional witness, and a derived sighash as described above.
 
 While omitted below, ERROR is returned if an unforeseen error occurs at any point in the process. A concrete example of this is if a legacy proof is given as input to a non-legacy address; the deserialization of the proof will fail in this case, and this should result in an ERROR result.
 
-# Obtain the sighash and scriptPubKey from the purpose; pass on result code if not VALID
 # Verify Script with flags=consensus flags (currently P2SH, DERSIG, NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
 # Return INVALID if verification fails
 # Verify Script with flags=standard flags (above plus STRICTENC, MINIMALDATA, etc.), scriptSig=script sig, scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
 # Return VALID if verification succeeds, otherwise return INCONCLUSIVE
 
-=== Multiple Proofs ===
-
-When more than one proof is created or verified, repeat the operation for each proof, retaining the inputs set. As noted, if the same input appears more than once, the operation must fail accordingly.
-
-Note that the order of the entries in the proof must match the order of the entries given by the verifier.
-
-* If any of the proofs are empty during a verification process, skip the verification and set the INCOMPLETE flag
-* If a verification call returns ERROR or INVALID, return ERROR or INVALID immediately, ignoring as yet unverified entries
-* After all verifications complete,
-** return INCONCLUSIVE if any verification call returned INCONCLUSIVE
-** return INCOMPLETE if the INCOMPLETE flag is set
-** return VALID
-
 == Legacy format ==
 
-The legacy format is restricted to the legacy P2PKH address format, and restricted to one single challenge (address).
+The legacy format is restricted to the legacy P2PKH address format.
 
-Any other input (e.g. multiple addresses, or non-P2PKH address format(s)) must be signed using the new format described above.
+Any other input (i.e. non-P2PKH address format) must be signed using the new format described above.
 
 === Signing ===
 
@@ -174,10 +135,6 @@ Given the P2PKH address <code>a</code>, the message <code>m</code>, the compact
 
 This specification is backwards compatible with the legacy signmessage/verifymessage specification through the special case as described above.
 
-== Rationale ==
-
-<references/>
-
 == Reference implementation ==
 
 # Pull request to Bitcoin Core: https://github.com/bitcoin/bitcoin/pull/16440
@@ -228,6 +185,8 @@ All of the above, plus (subject to change):
 
 == Test vectors ==
 
+(TODO: update test vectors, which are based on previous iteration where signature proofs contained additional data)
+
 == Native segwit test vector ==
 
 <pre>