* 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
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
2015-01-16 16:34 ` Thomas Kerin
@ 2015-01-16 17:09 ` Alan Reiner
0 siblings, 0 replies; 16+ messages in thread
From: Alan Reiner @ 2015-01-16 17:09 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4440 bytes --]
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
[-- Attachment #2: Type: text/html, Size: 7080 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 10:16 ` Ruben de Vries
@ 2015-01-16 16:34 ` Thomas Kerin
2015-01-16 17:09 ` Alan Reiner
0 siblings, 1 reply; 16+ messages in thread
From: Thomas Kerin @ 2015-01-16 16:34 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1.1: Type: text/plain, Size: 4668 bytes --]
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512
It would - it assumes you have the set of keys and are sorting before
you derive and send funds to such a P2SH address.
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
- --
Thomas Kerin
- -------------------------
My PGP key can be found here
<http://pgp.mit.edu/pks/lookup?op=get&search=0x3F0D2F83A2966155>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iQJ8BAEBCgBmBQJUuT2EXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ2MzI1MzM4QjJGOTU5OEUzREMzQzc0MzAz
RjBEMkY4M0EyOTY2MTU1AAoJED8NL4OilmFV4GgP/Rr955cDBA34e58lLdjXkqzi
EYDH5QfsTdUQQVUvkK0OBq7RQwkbb7Kn5u6U8UD3hEhaWwQGhrQ/gOJrqM68glma
YfYupugMesTTu4Fxm/AtNv4Cifr29EZB1gu9hBeZGT4FL863+0ShvWHdHvscOcmg
3SGv0De+1bd93j7p+9jyWh/sYpHEdi0lQBMkkCzSzhXPZzoHEglUmVYBRcmrjaag
ycHuQfN5zjM0fJ18R6f7PCOOAhDi9+7xpikDArvHmKb4BZjOuMBTprN2Mzdg98Uz
Rw4LRsLuht5VCnWHvC8+TUUEMUO8QOMrRxLYJSDVGcl0XYXT0EiRfnkqCr5ab8mm
KqLcxpSLxrDGd4OiHwWB7oDsg9tWXwVmyQgFsTLsxaNkL8AFRG59mAhbK9j+0+1E
Bd/pMx0VgGXpn1Urism5YlrR4FZ5USbYn9O0NxhUkQb550qvRtaAQNUVSJPEW0AG
/2pQdFOOqkI1wI0g2L/ZcC+fwBqUok+5MyMTb4NuuvaMDpR7vOeeobIpYLjL0VVZ
dNzfnlCQxGw/7QrFIbvnye8fNIMZZ9qtJx00bvXYizRyUhrF/FrRgwj2DhEjz6xM
3+CHKXNmb0qGg6jKgHvXQFic2DVo3IaNmZtVDBqyqCBKmC/A65rRws5uxIimUsIC
k4af62ZBGpSAhJ4ajCIY
=Ni9V
-----END PGP SIGNATURE-----
[-- Attachment #1.2: Type: text/html, Size: 7202 bytes --]
[-- Attachment #2: 0xA2966155.asc --]
[-- Type: application/pgp-keys, Size: 5804 bytes --]
[-- Attachment #3: 0xA2966155.asc.sig --]
[-- Type: application/pgp-signature, Size: 639 bytes --]
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
[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
0 siblings, 1 reply; 16+ messages in thread
From: Ruben de Vries @ 2015-01-16 10:16 UTC (permalink / raw)
To: Wladimir; +Cc: Bitcoin Dev, Jeffrey Paul
[-- Attachment #1: Type: text/plain, Size: 1512 bytes --]
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> wrote:
> On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock <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
Web: www.blocktrail.com
Github: 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
[-- Attachment #2: Type: text/html, Size: 3392 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-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>
1 sibling, 0 replies; 16+ messages in thread
From: Jean-Pierre Rupp @ 2015-01-15 12:33 UTC (permalink / raw)
To: Matt Whitlock, bitcoin-development; +Cc: Ruben de Vries, Jeffrey Paul
A public key is a point in the elliptic curve. As such it has an X and
a Y component. Its serialization is described very succintly here:
https://en.bitcoin.it/wiki/Protocol_specification#Signatures
On 15/01/15 01:17, Matt Whitlock wrote:
> 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?
--
Be Happy :)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
2015-01-14 20:32 ` Jeff Garzik
@ 2015-01-15 11:59 ` Jonathan Brown
0 siblings, 0 replies; 16+ messages in thread
From: Jonathan Brown @ 2015-01-15 11:59 UTC (permalink / raw)
To: Jeff Garzik; +Cc: Bitcoin Dev, Ruben de Vries
[-- Attachment #1: Type: text/plain, Size: 2846 bytes --]
In BIP45 it mentions "lexicographically sorting the public keys".
https://github.com/bitcoin/bips/blob/master/bip-0045.mediawiki#Address_Generation_Procedure
On 15 January 2015 at 03:32, Jeff Garzik <jgarzik@bitpay•com> 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 <ruben@blocktrail•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 (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
>>
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
[-- Attachment #2: Type: text/html, Size: 5145 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-14 23:53 ` Eric Lombrozo
[not found] ` <CALKy-wreXNohc_Pe_DLBS1cXoS-3j8C_F7WsKuU=CYYKF9NB1Q@mail.gmail.com>
@ 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>
1 sibling, 2 replies; 16+ messages in thread
From: Matt Whitlock @ 2015-01-15 1:17 UTC (permalink / raw)
To: bitcoin-development; +Cc: Ruben de Vries, Jeffrey Paul
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?
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
[not found] ` <CALKy-wreXNohc_Pe_DLBS1cXoS-3j8C_F7WsKuU=CYYKF9NB1Q@mail.gmail.com>
@ 2015-01-15 1:09 ` Eric Lombrozo
0 siblings, 0 replies; 16+ messages in thread
From: Eric Lombrozo @ 2015-01-15 1:09 UTC (permalink / raw)
To: Andy Alness; +Cc: Bitcoin Dev, Ruben de Vries, Jeffrey Paul
[-- Attachment #1: Type: text/plain, Size: 2692 bytes --]
Ciphrex was using this convention well before BitPay...and BitPay's BIP32
implementation was at least partly taken from ours.
- Eric
On Jan 14, 2015 8:03 PM, "Andy Alness" <andy@coinbase•com> wrote:
> Doing same (BitPay convention) for our multisig support.
>
> On Wed, Jan 14, 2015 at 3:53 PM, Eric Lombrozo <elombrozo@gmail•com>
> wrote:
> > I would highly recommend NOT using Base58 for anything except stuff that
> is
> > to be copy/pasted by the enduser.
> >
> > Internally, pubkeys are DER-encoded integers.
> >
> > - Eric
> >
> > On Jan 14, 2015 2:54 PM, "Jeffrey Paul" <jp@eeqj•com> wrote:
> >>
> >>
> >> > On 20150114, at 09:39, devrandom <c1.sf-bitcoin@niftybox•net> 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.
> >>
> >> To clarify: the raw bytes of the public key itself, not the ascii base58
> >> representation of the pubkey hash - right?
> >>
> >> -jp
> >>
> >> --
> >> Jeffrey Paul EEQJ
> >> jp@eeqj•com https://eeqj.com
> >> +1-800-403-1126 (America) +1-312-361-0355 (Worldwide)
> >> 5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
> >>
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> 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
> >
>
>
>
> --
> Andy Alness
> Software Engineer
> Coinbase
> San Francisco, CA
>
[-- Attachment #2: Type: text/html, Size: 4245 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-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:17 ` Matt Whitlock
1 sibling, 2 replies; 16+ messages in thread
From: Eric Lombrozo @ 2015-01-14 23:53 UTC (permalink / raw)
To: Jeffrey Paul; +Cc: Bitcoin Dev, Ruben de Vries
[-- Attachment #1: Type: text/plain, Size: 1508 bytes --]
I would highly recommend NOT using Base58 for anything except stuff that is
to be copy/pasted by the enduser.
Internally, pubkeys are DER-encoded integers.
- Eric
On Jan 14, 2015 2:54 PM, "Jeffrey Paul" <jp@eeqj•com> wrote:
>
> > On 20150114, at 09:39, devrandom <c1.sf-bitcoin@niftybox•net> 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.
>
> To clarify: the raw bytes of the public key itself, not the ascii base58
> representation of the pubkey hash - right?
>
> -jp
>
> --
> Jeffrey Paul EEQJ
> jp@eeqj•com https://eeqj.com
> +1-800-403-1126 (America) +1-312-361-0355 (Worldwide)
> 5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
>
>
>
> ------------------------------------------------------------------------------
> 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
>
[-- Attachment #2: Type: text/html, Size: 2412 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-14 16:37 Ruben de Vries
2015-01-14 17:39 ` devrandom
@ 2015-01-14 20:32 ` Jeff Garzik
2015-01-15 11:59 ` Jonathan Brown
1 sibling, 1 reply; 16+ messages in thread
From: Jeff Garzik @ 2015-01-14 20:32 UTC (permalink / raw)
To: Ruben de Vries; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1930 bytes --]
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 <ruben@blocktrail•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 (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
>
>
> ------------------------------------------------------------------------------
> 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/
[-- Attachment #2: Type: text/html, Size: 3521 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-14 19:27 ` Jeffrey Paul
@ 2015-01-14 19:58 ` Pavol Rusnak
2015-01-14 23:53 ` Eric Lombrozo
1 sibling, 0 replies; 16+ messages in thread
From: Pavol Rusnak @ 2015-01-14 19:58 UTC (permalink / raw)
To: Jeffrey Paul, devrandom; +Cc: bitcoin-development, Ruben de Vries
On 14/01/15 20:27, Jeffrey Paul wrote:
> To clarify: the raw bytes of the public key itself, not the ascii base58 representation of the pubkey hash - right?
Could you give an example of two pubkeys where the following condition
is met?
raw(pubkey1) > raw(pubkey2) and base58(pubkey1) < base58(pubkey2)
--
Best Regards / S pozdravom,
Pavol Rusnak <stick@gk2•sk>
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
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
2 siblings, 2 replies; 16+ messages in thread
From: Jeffrey Paul @ 2015-01-14 19:27 UTC (permalink / raw)
To: devrandom; +Cc: bitcoin-development, Ruben de Vries
> On 20150114, at 09:39, devrandom <c1.sf-bitcoin@niftybox•net> 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.
To clarify: the raw bytes of the public key itself, not the ascii base58 representation of the pubkey hash - right?
-jp
--
Jeffrey Paul EEQJ
jp@eeqj•com https://eeqj.com
+1-800-403-1126 (America) +1-312-361-0355 (Worldwide)
5539 AD00 DE4C 42F3 AFE1 1575 0524 43F4 DF2A 55C2
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
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
2 siblings, 0 replies; 16+ messages in thread
From: Jean-Pierre Rupp @ 2015-01-14 18:58 UTC (permalink / raw)
To: devrandom, Ruben de Vries; +Cc: bitcoin-development
We in Haskoin do the same.
On 14/01/15 17:39, 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.
--
Be Happy :)
^ permalink raw reply [flat|nested] 16+ messages in thread
* Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions
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
2 siblings, 0 replies; 16+ messages in thread
From: Eric Lombrozo @ 2015-01-14 18:00 UTC (permalink / raw)
To: devrandom; +Cc: Bitcoin Dev, Ruben de Vries
[-- Attachment #1: Type: text/plain, Size: 2760 bytes --]
I think everyone is pretty much following this standard now.
- Eric
On Jan 14, 2015 12:58 PM, "devrandom" <c1.sf-bitcoin@niftybox•net> 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.
> >
> >
> >
> >
> > Ruben de Vries
> > CTO, 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
>
> --
> 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
>
[-- Attachment #2: Type: text/html, Size: 3781 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-14 16:37 Ruben de Vries
@ 2015-01-14 17:39 ` devrandom
2015-01-14 18:00 ` Eric Lombrozo
` (2 more replies)
2015-01-14 20:32 ` Jeff Garzik
1 sibling, 3 replies; 16+ messages in thread
From: devrandom @ 2015-01-14 17:39 UTC (permalink / raw)
To: Ruben de Vries; +Cc: bitcoin-development
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.
>
>
>
>
> Ruben de Vries
> CTO, 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
--
Miron / devrandom
^ permalink raw reply [flat|nested] 16+ messages in thread
* [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
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-16 18:40 [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions Jean-Pierre Rupp
-- strict thread matches above, loose matches on Subject: below --
2015-01-14 16:37 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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox