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