Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YBjRT-0003tC-4B for bitcoin-development@lists.sourceforge.net; Thu, 15 Jan 2015 12:22:27 +0000 X-ACL-Warn: Received: from mail-ig0-f171.google.com ([209.85.213.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YBjRR-0005Pf-5w for bitcoin-development@lists.sourceforge.net; Thu, 15 Jan 2015 12:22:26 +0000 Received: by mail-ig0-f171.google.com with SMTP id z20so27650485igj.4 for ; Thu, 15 Jan 2015 04:22:19 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=3nlmOfR3hz1XWnOdXdVs/c5apGrmJSM9/xsw4eXJ6JQ=; b=gjNRy8XphFpCjF6gdBZEVlqHchrFOSiP1oKW1BA91llVzCX1mNr5I3TLLaMlupXryS rt2xAY9iZOJ1WSxuVswtQ8GCrpmSCEa2V8EioitxpIvkNaLaSOff2m2E3cKbZqVXMK5H cdvHVAoUNBwpZLxmw0ysNeu1XWqJLf4vtbjcCggJI8q4RJ+PNSc4Xo6SM5Dz4BxBJj7G 8doMuQvWbzM67NvACPXeykXm9EhcqlG/dGQo2lEE+EQTVpBWkwPS5BzJ4QYeDmPE5Q8p 9MdXQydH1jSZjIrnLKsh6Z2XsPN/SA1ykJUCVT4JQ7cubtg0p8Wf4I7l00BcD/YGan0A 1fLw== X-Gm-Message-State: ALoCoQlZBVQg6Euabp+8DwlfNQoi98f1/PigseqttxCI+VLneUKEGqNYJUalIg9HMQPta9DRl0mM MIME-Version: 1.0 X-Received: by 10.107.12.214 with SMTP id 83mr9397422iom.61.1421323155419; Thu, 15 Jan 2015 03:59:15 -0800 (PST) Received: by 10.64.12.131 with HTTP; Thu, 15 Jan 2015 03:59:15 -0800 (PST) X-Originating-IP: [118.69.18.61] In-Reply-To: References: Date: Thu, 15 Jan 2015 18:59:15 +0700 Message-ID: From: Jonathan Brown To: Jeff Garzik Content-Type: multipart/alternative; boundary=001a113fc0eeca3fb2050caf9502 X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1YBjRR-0005Pf-5w Cc: Bitcoin Dev , Ruben de Vries Subject: Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Jan 2015 12:22:27 -0000 --001a113fc0eeca3fb2050caf9502 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable In BIP45 it mentions "lexicographically sorting the public keys". https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#Address_Gene= ration_Procedure On 15 January 2015 at 03:32, Jeff Garzik wrote: > Sounds like this warrants a micro-BIP just to get everybody on the same > page. > > > On Wed, Jan 14, 2015 at 11:37 AM, Ruben de Vries > wrote: > >> 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 key= s >> that would make it easier for services that implement some form of multi= sig >> to be compatible with each other without much hassle and making it possi= ble >> 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 no= t >> 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. >> >> >> =E2=80=8BRuben de Vries >> =E2=80=8BCTO, BlockTrail >> >> >> ------------------------------------------------------------------------= ------ >> 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 >> >> > > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > -------------------------------------------------------------------------= ----- > 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 > > --001a113fc0eeca3fb2050caf9502 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
In BIP45 it mentions "lexicographically sorting the p= ublic keys".

https://github.com/bi= tcoin/bips/blob/master/bip-0045.mediawiki#Address_Generation_Procedure<= br>

On 15 Ja= nuary 2015 at 03:32, Jeff Garzik <jgarzik@bitpay.com> wrote= :
Sounds like this warra= nts a micro-BIP just to get everybody on the same page.


On Wed, Jan 14, 2015 at 11:37 AM, Ruben de Vries = <ruben@blocktr= ail.com> wrote:
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 (recomme= nded) 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 with= out much hassle and making it possible to import keys from one service to a= nother.

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

Ryan from BitPay broad this up b= efore (https://sourceforge.net/p/bitcoin/mailman/message/320= 92958/) 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 bitc= ore is currently my only reference.


=E2=80=8BRuben de Vries
=E2=80=8BCTO, BlockTrail

------------------------------------------= ------------------------------------
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/s= fu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment




--
Jeff Garzik
Bitcoin c= ore developer and open source evangelist
BitPay, Inc. =C2=A0 =C2=A0 =C2= =A0https://bitpay.com/

-----------------------------------------------------------------------= -------
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/s= fu/gigenet
_______________________________________________
Bitcoin-development mailing list
Bitcoin-develo= pment@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-de= velopment


--001a113fc0eeca3fb2050caf9502--