Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1YBSFM-0002XN-KT for bitcoin-development@lists.sourceforge.net; Wed, 14 Jan 2015 18:00:48 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.215.41 as permitted sender) client-ip=209.85.215.41; envelope-from=elombrozo@gmail.com; helo=mail-la0-f41.google.com; Received: from mail-la0-f41.google.com ([209.85.215.41]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1YBSFJ-0006G5-OC for bitcoin-development@lists.sourceforge.net; Wed, 14 Jan 2015 18:00:48 +0000 Received: by mail-la0-f41.google.com with SMTP id hv19so9518185lab.0 for ; Wed, 14 Jan 2015 10:00:39 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.112.154.70 with SMTP id vm6mr5472513lbb.18.1421258439397; Wed, 14 Jan 2015 10:00:39 -0800 (PST) Received: by 10.112.61.106 with HTTP; Wed, 14 Jan 2015 10:00:39 -0800 (PST) Received: by 10.112.61.106 with HTTP; Wed, 14 Jan 2015 10:00:39 -0800 (PST) In-Reply-To: <1421257150.8969.4.camel@niftybox.net> References: <1421257150.8969.4.camel@niftybox.net> Date: Wed, 14 Jan 2015 10:00:39 -0800 Message-ID: From: Eric Lombrozo To: devrandom Content-Type: multipart/alternative; boundary=089e0115f5a46a16c8050ca0843f 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 (elombrozo[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: 1YBSFJ-0006G5-OC 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: Wed, 14 Jan 2015 18:00:48 -0000 --089e0115f5a46a16c8050ca0843f Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable I think everyone is pretty much following this standard now. - Eric On Jan 14, 2015 12:58 PM, "devrandom" wrote: > At CryptoCorp we recommend to our customers that they sort > lexicographically by the public key bytes of the leaf public keys. i.e. > the same as BitPay. > > On Wed, 2015-01-14 at 17:37 +0100, 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 > > 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. > > > > > > > > > > =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 Ashbur= n. > > 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 > > -- > Miron / devrandom > > > > > > -------------------------------------------------------------------------= ----- > 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 > --089e0115f5a46a16c8050ca0843f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

I think everyone is pretty much following this standard now.=

- Eric

On Jan 14, 2015 12:58 PM, "devrandom" = <c1.sf-bitcoin@niftybox.ne= t> wrote:
At = CryptoCorp we recommend to our customers that they sort
lexicographically by the public key bytes of the leaf public keys.=C2=A0 i.= e.
the same as BitPay.

On Wed, 2015-01-14 at 17:37 +0100, 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<= br> > 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/3209= 2958/) 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 sortin= g
> 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.<= br> > GigeNET is offering a free month of service with a new server in Ashbu= rn.
> Choose from 2 high performing configs, both with 100TB of bandwidth. > Higher redundancy.Lower latency.Increased capacity.Completely complian= t.
> http://p.sf.= net/sfu/gigenet
> _______________________________________________ Bitcoin-development ma= iling list Bit= coin-development@lists.sourceforge.net https://list= s.sourceforge.net/lists/listinfo/bitcoin-development

--
Miron / devrandom




---------------------------------------------------------------------------= ---
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
--089e0115f5a46a16c8050ca0843f--