summaryrefslogtreecommitdiff
path: root/bip-0322.mediawiki
diff options
context:
space:
mode:
authorKarl-Johan Alm <karljohan-alm@garage.co.jp>2019-08-06 17:09:25 +0900
committerKarl-Johan Alm <karljohan-alm@garage.co.jp>2019-08-06 17:09:25 +0900
commitf0784c6e922724c674550ee8aa4bfc72d6d32a8a (patch)
tree0a47469174bda86d077554ed0f8b354ce94798e4 /bip-0322.mediawiki
parenta2645cdc421d13842f4ea180338264942330abff (diff)
BIP322: added background to explain why BIP322 exists, and what it changes
Diffstat (limited to 'bip-0322.mediawiki')
-rw-r--r--bip-0322.mediawiki11
1 files changed, 11 insertions, 0 deletions
diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index 9448945..a4973d8 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -15,6 +15,17 @@
A standard for interoperable generic signed messages based on the Bitcoin Script format.
+== Background ==
+
+* Assume two actors, a prover <code>P</code> and a verifier <code>V</code>.
+* <code>P</code> wants to prove that they own the private key <code>k</code> associated with a given address <code>A</code> (which in turn is derived from the pubkey <code>kG</code>).
+* Let <code>V</code> generate a message <code>M</code> and hand this to <code>P</code>.
+* <code>P</code> generates a signature <code>S</code> by signing the message <code>M</code> using <code>k</code>. Given <code>S</code>, <code>V</code> can prove that <code>P</code> has the private key associated with <code>A</code>.
+
+The astute reader will notice that the above is missing a critical part, namely the pubkey <code>kG</code>, without which the verifier cannot actually verify the message. The current message signing standard solves this via a cryptographic trick, wherein the signature <code>S</code> above is a special "recoverable signature" type. Given the message <code>M</code> and the signature <code>S</code>, it is then possible to recover the pubkey <code>kG</code>. The system thus derives the address for the pubkey <code>kG</code>, and if it does not match <code>A</code>, the proof is deemed invalid.
+
+While this is a neat trick, it unnecessarily restricts and complicates the message signing mechanism; for instance, it is currently not possible to sign a message for a P2SH address, because there is no pubkey to recover from the resulting signature.
+
== Motivation ==
The current message signing standard only works for P2PKH (1...) addresses. By extending it to use a Bitcoin Script based approach, it could be made more generic without causing a too big burden on implementers, who most likely have access to Bitcoin Script interpreters already.