[Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

[Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1635 bytes --]

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.

-- 
'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

[Alan Reiner]

[-- Attachment #1: Type: text/plain, Size: 3175 bytes --]

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


[-- Attachment #2: Type: text/html, Size: 4260 bytes --]

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1313 bytes --]

On Sun, Apr 14, 2013 at 01:21:21AM -0400, Alan Reiner wrote:
> 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 already looked into ASCII-armoring PGP style for a different project.
(timestamping) Basically you'd want to follow RFC2440, section 7
"Cleartext signature framework":

-----BEGIN BTC SIGNED MESSAGE-----

Hello world!
-----BEGIN BTC SIGNATURE-----
IKBeCbxXHvD1TJh8ZlMySo26w5z6YZQD1xqKgbhsvlhEgcFD+kvKx4LzUz1yxg/8
IdYdBnzez77VDq3odHrVftg=
-----END BTC SIGNATURE-----

Pretty simple really and doesn't need to be done prior to other
signmessage changes. There may be an issue passing \r's through the RPC
interface; the RFC specifies CRLF line endings.

-- 
'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

[Alan Reiner]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 04/14/2013 02:25 AM, Peter Todd wrote:
> On Sun, Apr 14, 2013 at 01:21:21AM -0400, Alan Reiner wrote:
>> 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 already looked into ASCII-armoring PGP style for a different project.
> (timestamping) Basically you'd want to follow RFC2440, section 7
> "Cleartext signature framework":
>
> -----BEGIN BTC SIGNED MESSAGE-----
>
> Hello world!
> -----BEGIN BTC SIGNATURE-----
> IKBeCbxXHvD1TJh8ZlMySo26w5z6YZQD1xqKgbhsvlhEgcFD+kvKx4LzUz1yxg/8
> IdYdBnzez77VDq3odHrVftg=
> -----END BTC SIGNATURE-----
>
> Pretty simple really and doesn't need to be done prior to other
> signmessage changes. There may be an issue passing \r's through the RPC
> interface; the RFC specifies CRLF line endings.
>
Perfect.  That was the spec I was looking for but too lazy to find it. 
I guess I'll lead by example and just do it in Armory.  I'll let users
pressure the other devs to follow :)

- -Alan
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlFq9GIACgkQYdHIW5RKKv1A2gCeMfdttPylmPqPqemo0Q2uACEt
eAcAn21a7sYy+TNIinRR3SlVgm4VbJPh
=qGlo
-----END PGP SIGNATURE-----

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

[Luke-Jr]

On Sunday, April 14, 2013 5:09:58 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.

I think it would be wise to figure out HD wallet changes before trying to 
extend message signing. For privacy/safety, it would be a good idea to avoid 
signing with the same private key twice under any circumstances, so it might 
make sense to create a new address format the represent a chain of keys 
instead of one key or combination of keys.

Luke

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 967 bytes --]

On Sun, Apr 14, 2013 at 05:26:37AM +0000, Luke-Jr wrote:
> On Sunday, April 14, 2013 5:09:58 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.
> 
> I think it would be wise to figure out HD wallet changes before trying to 
> extend message signing. For privacy/safety, it would be a good idea to avoid 
> signing with the same private key twice under any circumstances, so it might 
> make sense to create a new address format the represent a chain of keys 
> instead of one key or combination of keys.

Sure, which is why I have the header byte so that when we do come up
with a chain of keys thing, that in turn can get it's own magic number
allocated.

FWIW I have an application now where a multisig signmessage would be
useful.

-- 
'peter'[:-1]@petertodd.org

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]