<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=ISO-8859-1">
</head>
<body bgcolor="#ffffff" text="#000000">
I would like to propose two things that are closely related. I will
start making BIPS if there's positive feedback. Sorry it's so long,
but I felt both should be in the same email...<br>
<br>
<br>
<u><b>(1) Signature Blocks</b> -- A more-robust, versatile,
message-signing exchange</u><br>
<br>
Satoshi client 0.6.0 introduced message signing, but I've been
fairly unimpressed with the implementation. Strictly speaking, it
works, but it's really not intended for "regular users." There is
no indication of what message was signed or what address signed it.
Key recovery works for the computers processing it, but the user has
no idea what this chunk of random data is. They don't even know if
the message they thought they signed is what's in the signature
(along the lines of the copy&paste virus, the message could be
switched out without the user noticing).<br>
<br>
I have implemented <a
href="https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163">Signature
Blocks</a> in Armory (as of v0.55), which is a fully-functional
expansion on the idea. Along the lines of BIP 10, a signature block
is a human-readable chunk of data that immediately identifies the
address and the message that are being signed. It is easily
copy&pasted via email or text files, and is fairly compact for
visual identification. Click the link above to see an example
signature block and an Armory screenshot of the UI (which needs
improvement, but still usable). The verification process will
include:<br>
<br>
-- Check that the public key (included or recovered) matches the
address field. <br>
-- Verify that the signature matches the included message for this
public key<br>
-- The message is properly formatted with a standardized character
set and escape/replacement scheme for things like newlines or
double-quotes.<br>
<br>
gmaxwell already pointed out that key recovery makes the "Public
Key" field pointless. Okay fine -- I just don't have key recovery
implemented yet in Armory, and when I do I can ditch that field (or
simply make it optional). The point is to create a versatile,
human-readable standardized form, much like the <a
href="https://en.bitcoin.it/wiki/BIP_0010">BIP 0010
signature-collection scheme</a>.<br>
<br>
<br>
<u><b>(2) Sign-Message URI scheme</b><b> </b>-- Request signed
messages from users using URIs</u><br>
<br>
I had the idea that for certain services, the first funding address
could be used to identify the owner of an account, and all account
maintenance (such as cashouts) be done through signed messages with
this address. For instance, the user would need both a login
password <b>and</b> a signed message in order to make a withdrawal
or purchase:<br>
<br>
<tt> ("Please withdraw 12.3 BTC from acct 1828349132 to address
1Hfr3jk2093f")_signed_by_A</tt><br>
<br>
This gives the service the ability to use two separate factors to
authenticate the request (username&password <b>and</b> access
to unencrypted wallet). This <i>could</i> work with manual
signature blocks alone... but it's too many steps for regular
users. However, I think it's workable if we expand bitcoin URIs to
include "Signature Requests".<br>
<br>
The URI scheme would add a few parameters to the scheme, and would
have to have further replacement rules to make sure that messages
are handled properly. The general CONOPs would be (<b>Con</b>cept
of <b>Op</b>eration<b>s</b>):<br>
<br>
-- User navigates to "Withdraw funds" on webpage<br>
-- Webpage has you fill in the details: from-account,
to-address, withdrawal amount<br>
-- Webpage produces a clickable URI link that loads all the
information into your client, including addr-reqd-for-sig<br>
-- Client asks for confirmation and passphrase (if necessary)
then produces a signature (and sig block if necessary)<br>
-- URI may include reply-to field that tells it where to send
the siganture when it's ready<br>
<br>
So the extra tags that would be needed would probably be:<br>
<br>
"<b>requestSig</b>=True": <br>
Flag to identify that this is a signing request URI<br>
"<b>sigNeeded</b>=1Qjf3392k31h" <br>
The address that needs to sign the message<br>
"<b>message</b>=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f"<br>
Some encoding of the message that can be parsed the
same way on all systems<br>
"<b>replyurl</b>=<a class="moz-txt-link-freetext" href="http://requestor.com/sig_replies.asp">http://requestor.com/sig_replies.asp</a>?"<br>
(Optional) After signing, application will submit
the signature to the replyurl<br>
<br>
The reply url could be simply an http URL which will use bitcoin URI
syntax, with the fields above copied. Therefore, to complete the
above request, the application handling the request will simply send
an HTTP request to:<br>
<br>
<tt> <a class="moz-txt-link-freetext" href="http://requestor.com/sig_replies.asp">http://requestor.com/sig_replies.asp</a>?<b>sigNeeded</b>=1Qjf3392k31h&<b>message</b>=...&<b>signature</b>=1fb1893ac193...&<b>replySig</b>=True</tt><br>
<br>
Any thoughts? (I have no doubts that there are :) )<br>
<br>
-Alan<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>