summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorAlan Reiner <etotheipi@gmail.com>2013-04-14 01:21:21 -0400
committerbitcoindev <bitcoindev@gnusha.org>2013-04-14 05:22:26 +0000
commit54128a52215e58643177923ce779ea47b634029e (patch)
treee74a63e30a4344dc50e3ff183d093a1d18966b1c
parent10e2b722cdcc9aa407f68772cc7df5f3ce254663 (diff)
downloadpi-bitcoindev-54128a52215e58643177923ce779ea47b634029e.tar.gz
pi-bitcoindev-54128a52215e58643177923ce779ea47b634029e.zip
Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig
-rw-r--r--46/a190362e8f1df7283f4e93461a88a14838c897246
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?&nbsp;
+ Really, anything that encodes the signed message next to the
+ signature, so that there's no ambiguities about what was signed.&nbsp;
+ 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...:&nbsp;&nbsp; &lt;message&gt;".&nbsp;&nbsp; <br>
+ <br>
+ I know people argue they'd like to get away from raw addresses and
+ copy-and-paste.&nbsp; 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.&nbsp; 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:
+
+ &lt;01&gt; &lt;varint n&gt; &lt;varint m&gt; &lt;sig or key&gt; {&lt;sig or key&gt;, ...}
+
+Each signature or key can be one of the following forms:
+
+ sig: &lt;1B/1C/1D/1E&gt; &lt;32 byte r&gt; &lt;32 byte s&gt;
+ compress key: &lt;02/03&gt; &lt;32 byte x&gt;
+ uncompressed key: &lt;04&gt; &lt;32 byte x&gt; &lt;32 byte y&gt;
+
+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 &amp; 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--
+
+