bip-0322: replace motivation, add myself to the "thanks to" list

1 files changed, 5 insertions, 5 deletions

diff --git a/bip-0322.mediawiki b/bip-0322.mediawiki
index e515b56..f13544f 100644
--- a/bip-0322.mediawiki
+++ b/bip-0322.mediawiki
@@ -17,11 +17,11 @@ A standard for interoperable signed messages based on the Bitcoin Script format,
 
 == Motivation ==
 
-The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This approach minimizes the burden for implementers as message signing can be expected to be part of a library or project that includes Bitcoin Script interpreters already.
+The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network).
 
-Additionally, the current message signing only proves that the message has been committed to by the recipient of a given invoice address.
-It does not prove anything about the invoice address itself, nor that the signer has access to the private keys used to implement this invoice.
-More importantly, it does not prove ownership nor access to any funds, even if the same private key would be a valid signer for spending them - and this is a commonly desired use case.
+Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
+
+Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations.
 
 == Specification ==
 
@@ -121,7 +121,7 @@ TODO
 
 == Acknowledgements ==
 
-Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, and many others for their feedback on the specification.
+Thanks to David Harding, Jim Posen, Kalle Rosenbaum, Pieter Wuille, Andrew Poelstra, and many others for their feedback on the specification.
 
 == References ==