public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
* [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
@ 2015-01-14 16:37 Ruben de Vries
  2015-01-14 17:39 ` devrandom
  2015-01-14 20:32 ` Jeff Garzik
  0 siblings, 2 replies; 16+ messages in thread
From: Ruben de Vries @ 2015-01-14 16:37 UTC (permalink / raw)
  To: bitcoin-development

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

For p2sh multisig TXs the order of the public keys affect the hash and
there doesn't seem to be an agreed upon way of sorting the public keys.

If there would be a standard (recommended) way of sorting the public keys
that would make it easier for services that implement some form of multisig
to be compatible with each other without much hassle and making it possible
to import keys from one service to another.

I'm not suggesting forcing the order, just setting a standard to recommend,
there doesn't seem to be much reason for (new) services to not follow that
recommendation.

Ryan from BitPay broad this up before (
https://sourceforge.net/p/bitcoin/mailman/message/32092958/) and in bitcore
they've implemented lexicographical sorting on the hex of the public key.
In a short search I can't find any other library that has a sorting
function, let alone using it by default, so bitcore is currently my only
reference.


​Ruben de Vries
​CTO, BlockTrail

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

^ permalink raw reply	[flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
@ 2015-01-16 18:40 Jean-Pierre Rupp
  0 siblings, 0 replies; 16+ messages in thread
From: Jean-Pierre Rupp @ 2015-01-16 18:40 UTC (permalink / raw)
  To: Alan Reiner; +Cc: bitcoin-development

It is better if the scheme is strongly deterministic.On 16 Jan 2015 17:09, Alan Reiner <etotheipi@gmail•com> wrote:
>
> I see no reason to restrict compressed/uncompressed.  Strings don't have to be the same length to sort them lexicographically.  If a multi-sig participant provides an uncompressed key, they are declaring that the key that they use and it will only be used uncompressed.   Clients don't have to go looking for all combinations of compressed & uncompressed.
>
> On 01/16/2015 11:34 AM, Thomas Kerin wrote:
> >
>>
>>
>> It seems there is scope for further narrowing down how a multisig scripthash address should be determined - what do people think of anticipating only compressed keys for scripts?
>>
>> It's possible to cause confusion if one put forward a compressed key at some time, and an uncompressed key at another. A different script hash would be produced even though there is no difference to the keys involved. The client will not search for this.
>>
>>
>> Having spoken with Jean-Pierre and Ruben about this for quite some time now, there is 100% the need for a BIP outlining this. Everyone has had the idea at some point, and some of us already using it, but people shouldn't have to go digging in BIP45 for the two lines which mention it. All we need is a place to put the docs.
>>
>> I am building up a list of implementations which currently support sorting, and briefly describing a motivation for such a BIP.
>>
>>
>> On 16/01/15 10:16, Ruben de Vries wrote:
>> > Since we only need the sorting for creating the scriptPubKey,
>> > wouldn't it make the most sense to sort it by the way it represented in that context?
>>
>>
>> > On Thu, Jan 15, 2015 at 2:03 PM, Wladimir <laanwj@gmail•com <mailto:laanwj@gmail•com>> wrote:
>>
>> >     On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock <bip@mattwhitlock•name <mailto:bip@mattwhitlock•name>> wrote:
>> >     > On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
>> >     >> Internally, pubkeys are DER-encoded integers.
>> >     >
>> >     > I thought pubkeys were represented as raw integers (i.e., they're embedded in Script as a push operation whose payload is the raw bytes of the big-endian representation of the integer). As far as I know, DER encoding is only used for signatures. Am I mistaken?
>>
>> >     OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
>> >     DER-encoded signature on the stack.
>>
>> >     Possibly you're confused with OP_HASH160 <hash160> OP_EQUALVERIFY as
>> >     used in outputs, which compares the 160-bit hash of the pubkey against
>> >     the given hash (usually taken from a bitcoin address).
>>
>> >     It doesn't help understanding to consider either as integers. They are
>> >     binary blob objects with either a fixed format (DER) or a fixed size
>> >     (hashes).
>>
>> >     Wladimir
>>
>>
>>
>>
>> > --
>> > BlockTrail B.V.
>> > Barbara Strozzilaan 201
>> > 1083HN Amsterdam
>> > The Netherlands
>>
>> > Phone:+31 (0)612227277
>> > E-mail:ruben@blocktrail•com <mailto:ruben@blocktrail•com>
>> > Web:www.blocktrail.com
>> > <http://www.blocktrail.com/>
>> > Github:www.github.com/rubensayshi <http://www.github.com/rubensayshi>
>>
>> > BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01
>>
>>
>> > ------------------------------------------------------------------------------
>> > New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
>> > GigeNET is offering a free month of service with a new server in Ashburn.
>> > Choose from 2 high performing configs, both with 100TB of bandwidth.
>> > Higher redundancy.Lower latency.Increased capacity.Completely compliant.
>> > http://p.sf.net/sfu/gigenet
>>
>>
>> > _______________________________________________
>> > Bitcoin-development mailing list
>> > Bitcoin-development@lists•sourceforge.net
>> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
> >
> >
> >
> > ------------------------------------------------------------------------------
> > New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
> > GigeNET is offering a free month of service with a new server in Ashburn.
> > Choose from 2 high performing configs, both with 100TB of bandwidth.
> > Higher redundancy.Lower latency.Increased capacity.Completely compliant.
> > http://p.sf.net/sfu/gigenet
> >
> >
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists•sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

^ permalink raw reply	[flat|nested] 16+ messages in thread
end of thread, other threads:[~2015-01-16 19:08 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-01-14 16:37 [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions Ruben de Vries
2015-01-14 17:39 ` devrandom
2015-01-14 18:00   ` Eric Lombrozo
2015-01-14 18:58   ` Jean-Pierre Rupp
2015-01-14 19:27   ` Jeffrey Paul
2015-01-14 19:58     ` Pavol Rusnak
2015-01-14 23:53     ` Eric Lombrozo
     [not found]       ` <CALKy-wreXNohc_Pe_DLBS1cXoS-3j8C_F7WsKuU=CYYKF9NB1Q@mail.gmail.com>
2015-01-15  1:09         ` Eric Lombrozo
2015-01-15  1:17       ` Matt Whitlock
2015-01-15 12:33         ` Jean-Pierre Rupp
     [not found]         ` <CA+s+GJCsta-FesGv7zW_i2pEtZM5U20ZqP2V_Oog_LBtQBbe-w@mail.gmail.com>
2015-01-16 10:16           ` Ruben de Vries
2015-01-16 16:34             ` Thomas Kerin
2015-01-16 17:09               ` Alan Reiner
2015-01-14 20:32 ` Jeff Garzik
2015-01-15 11:59   ` Jonathan Brown
2015-01-16 18:40 Jean-Pierre Rupp

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox