diff options
author | Alan Reiner <etotheipi@gmail.com> | 2013-04-14 01:21:21 -0400 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2013-04-14 05:22:26 +0000 |
commit | 54128a52215e58643177923ce779ea47b634029e (patch) | |
tree | e74a63e30a4344dc50e3ff183d093a1d18966b1c | |
parent | 10e2b722cdcc9aa407f68772cc7df5f3ce254663 (diff) | |
download | pi-bitcoindev-54128a52215e58643177923ce779ea47b634029e.tar.gz pi-bitcoindev-54128a52215e58643177923ce779ea47b634029e.zip |
Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig
-rw-r--r-- | 46/a190362e8f1df7283f4e93461a88a14838c897 | 246 |
1 files changed, 246 insertions, 0 deletions
diff --git a/46/a190362e8f1df7283f4e93461a88a14838c897 b/46/a190362e8f1df7283f4e93461a88a14838c897 new file mode 100644 index 000000000..d5c2611c9 --- /dev/null +++ b/46/a190362e8f1df7283f4e93461a88a14838c897 @@ -0,0 +1,246 @@ +Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] + helo=mx.sourceforge.net) + by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) + (envelope-from <etotheipi@gmail.com>) id 1URFOU-0007Yr-U0 + for bitcoin-development@lists.sourceforge.net; + Sun, 14 Apr 2013 05:22:26 +0000 +Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com + designates 209.85.216.173 as permitted sender) + client-ip=209.85.216.173; envelope-from=etotheipi@gmail.com; + helo=mail-qc0-f173.google.com; +Received: from mail-qc0-f173.google.com ([209.85.216.173]) + by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) + (Exim 4.76) id 1URFOT-0006ZW-Qr + for bitcoin-development@lists.sourceforge.net; + Sun, 14 Apr 2013 05:22:26 +0000 +Received: by mail-qc0-f173.google.com with SMTP id b12so1766175qca.32 + for <bitcoin-development@lists.sourceforge.net>; + Sat, 13 Apr 2013 22:22:20 -0700 (PDT) +X-Received: by 10.224.8.129 with SMTP id h1mr16548314qah.86.1365916940347; + Sat, 13 Apr 2013 22:22:20 -0700 (PDT) +Received: from [192.168.1.85] (c-76-111-96-126.hsd1.md.comcast.net. + [76.111.96.126]) + by mx.google.com with ESMTPS id e2sm23929507qey.3.2013.04.13.22.22.19 + (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); + Sat, 13 Apr 2013 22:22:19 -0700 (PDT) +Message-ID: <516A3CD1.20704@gmail.com> +Date: Sun, 14 Apr 2013 01:21:21 -0400 +From: Alan Reiner <etotheipi@gmail.com> +User-Agent: Mozilla/5.0 (X11; Linux x86_64; + rv:17.0) Gecko/20130329 Thunderbird/17.0.5 +MIME-Version: 1.0 +To: bitcoin-development@lists.sourceforge.net +References: <20130414050958.GA11142@savin> +In-Reply-To: <20130414050958.GA11142@savin> +X-Enigmail-Version: 1.5.1 +Content-Type: multipart/alternative; + boundary="------------040706080107010709030104" +X-Spam-Score: -0.6 (/) +X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. + See http://spamassassin.org/tag/ for more details. + -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for + sender-domain + 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider + (etotheipi[at]gmail.com) + -0.0 SPF_PASS SPF: sender matches SPF record + 1.0 HTML_MESSAGE BODY: HTML included in message + -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from + author's domain + 0.1 DKIM_SIGNED Message has a DKIM or DK signature, + not necessarily valid + -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature +X-Headers-End: 1URFOT-0006ZW-Qr +Subject: Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to + P2SH multisig +X-BeenThere: bitcoin-development@lists.sourceforge.net +X-Mailman-Version: 2.1.9 +Precedence: list +List-Id: <bitcoin-development.lists.sourceforge.net> +List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe> +List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development> +List-Post: <mailto:bitcoin-development@lists.sourceforge.net> +List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help> +List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>, + <mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe> +X-List-Received-Date: Sun, 14 Apr 2013 05:22:27 -0000 + +This is a multi-part message in MIME format. +--------------040706080107010709030104 +Content-Type: text/plain; charset=ISO-8859-1 +Content-Transfer-Encoding: 7bit + +If we're going to extend/expand message signing, can we please add a +proper ASCII-armored format for it? Really, anything that encodes the +signed message next to the signature, so that there's no ambiguities +about what was signed. You can keep the "bare signatures" as an option +for backwards compatiblity, but offer this as the primary one. + +What we really want is to have the user copy an ASCII-armored block of +text into the client (or we could have a URI-extension for this), and +the app pops up with a window that says "The following message has a +valid signature from address 1XKjf32kJbf...: <message>". + +I know people argue they'd like to get away from raw addresses and +copy-and-paste. But it'll be a while before that happens, and there's a +lot of demand for Armory to become compatible with Bitcoin-Qt signing. +People are obviously using it. + +-Alan + + + + + +On 04/14/2013 01:09 AM, Peter Todd wrote: +> Currently signmessage/verifymessage only supports messages signed by a +> single key. We should extend that to messages signed by n-of-m keys, or +> from the users point of view, P2SH multisig addresses. +> +> rpc.cpp:signmessage() returns the output of SignCompact(). That in turn +> starts with a header byte marking the signs of the various keys to allow +> for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E +> +> +> For multisig signmessage signatures this is extended: +> +> <01> <varint n> <varint m> <sig or key> {<sig or key>, ...} +> +> Each signature or key can be one of the following forms: +> +> sig: <1B/1C/1D/1E> <32 byte r> <32 byte s> +> compress key: <02/03> <32 byte x> +> uncompressed key: <04> <32 byte x> <32 byte y> +> +> Note that we have to provide all pubkeys, even if they aren't used for a +> given signature, to allow the P2SH address to be reconstructed. +> +> Decoding/encoding is a bit code-intensive due to the all the cases, but +> on the other hand this format keeps the size down to an absolute +> minimum. Alternatively I could use length bytes. +> +> The format is backwards compatible in the sense that older versions will +> fail safely on new signatures, even ones that have been truncated. +> Similarly new signatures are easily distinguished from old, and going +> forward if we for some reason need yet another signature format the +> leading byte can be incremented. +> +> Signing incomplete signatures on messages can be handled by converting +> pubkeys to signatures. Similarly the RPC signmessage command can be +> extended with an optional "existing signature" option. +> +> +> +> ------------------------------------------------------------------------------ +> Precog is a next-generation analytics platform capable of advanced +> analytics on semi-structured data. The platform includes APIs for building +> apps and a phenomenal toolset for data science. Developers can use +> our toolset for easy data analysis & visualization. Get a free account! +> http://www2.precog.com/precogplatform/slashdotnewsletter +> +> +> _______________________________________________ +> Bitcoin-development mailing list +> Bitcoin-development@lists.sourceforge.net +> https://lists.sourceforge.net/lists/listinfo/bitcoin-development + + +--------------040706080107010709030104 +Content-Type: text/html; charset=ISO-8859-1 +Content-Transfer-Encoding: 7bit + +<html> + <head> + <meta content="text/html; charset=ISO-8859-1" + http-equiv="Content-Type"> + </head> + <body text="#000000" bgcolor="#FFFFFF"> + <div class="moz-cite-prefix">If we're going to extend/expand message + signing, can we please add a proper ASCII-armored format for it? + Really, anything that encodes the signed message next to the + signature, so that there's no ambiguities about what was signed. + You can keep the "bare signatures" as an option for backwards + compatiblity, but offer this as the primary one.<br> + <br> + What we really want is to have the user copy an ASCII-armored + block of text into the client (or we could have a URI-extension + for this), and the app pops up with a window that says "The + following message has a valid signature from address + 1XKjf32kJbf...: <message>". <br> + <br> + I know people argue they'd like to get away from raw addresses and + copy-and-paste. But it'll be a while before that happens, and + there's a lot of demand for Armory to become compatible with + Bitcoin-Qt signing. People are obviously using it.<br> + <br> + -Alan<br> + <br> + <br> + <br> + <br> + <br> + On 04/14/2013 01:09 AM, Peter Todd wrote:<br> + </div> + <blockquote cite="mid:20130414050958.GA11142@savin" type="cite"> + <pre wrap="">Currently signmessage/verifymessage only supports messages signed by a +single key. We should extend that to messages signed by n-of-m keys, or +from the users point of view, P2SH multisig addresses. + +rpc.cpp:signmessage() returns the output of SignCompact(). That in turn +starts with a header byte marking the signs of the various keys to allow +for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E + + +For multisig signmessage signatures this is extended: + + <01> <varint n> <varint m> <sig or key> {<sig or key>, ...} + +Each signature or key can be one of the following forms: + + sig: <1B/1C/1D/1E> <32 byte r> <32 byte s> + compress key: <02/03> <32 byte x> + uncompressed key: <04> <32 byte x> <32 byte y> + +Note that we have to provide all pubkeys, even if they aren't used for a +given signature, to allow the P2SH address to be reconstructed. + +Decoding/encoding is a bit code-intensive due to the all the cases, but +on the other hand this format keeps the size down to an absolute +minimum. Alternatively I could use length bytes. + +The format is backwards compatible in the sense that older versions will +fail safely on new signatures, even ones that have been truncated. +Similarly new signatures are easily distinguished from old, and going +forward if we for some reason need yet another signature format the +leading byte can be incremented. + +Signing incomplete signatures on messages can be handled by converting +pubkeys to signatures. Similarly the RPC signmessage command can be +extended with an optional "existing signature" option. + +</pre> + <br> + <fieldset class="mimeAttachmentHeader"></fieldset> + <br> + <pre wrap="">------------------------------------------------------------------------------ +Precog is a next-generation analytics platform capable of advanced +analytics on semi-structured data. The platform includes APIs for building +apps and a phenomenal toolset for data science. Developers can use +our toolset for easy data analysis & visualization. Get a free account! +<a class="moz-txt-link-freetext" href="http://www2.precog.com/precogplatform/slashdotnewsletter">http://www2.precog.com/precogplatform/slashdotnewsletter</a></pre> + <br> + <fieldset class="mimeAttachmentHeader"></fieldset> + <br> + <pre wrap="">_______________________________________________ +Bitcoin-development mailing list +<a class="moz-txt-link-abbreviated" href="mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-development@lists.sourceforge.net</a> +<a class="moz-txt-link-freetext" href="https://lists.sourceforge.net/lists/listinfo/bitcoin-development">https://lists.sourceforge.net/lists/listinfo/bitcoin-development</a> +</pre> + </blockquote> + <br> + </body> +</html> + +--------------040706080107010709030104-- + + |