Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions

[Thomas Kerin <me@thomaskerin.io>]

[-- 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 --]