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 laa...@gmail.com wrote:
On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock b...@mattwhitlock.name
wrote:
-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
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
It is better if the scheme is strongly deterministic.On 16 Jan 2015 17:09, Alan
Reiner etothe...@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
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 jgar...@bitpay.com wrote:
Sounds like this warrants a micro-BIP just to get everybody on the same
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
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 ru...@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
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)
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 :)
On 20150114, at 09:39, devrandom c1.sf-bitc...@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
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 j...@eeqj.com wrote:
On 20150114, at 09:39, devrandom c1.sf-bitc...@niftybox.net 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
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
I think everyone is pretty much following this standard now.
- Eric
On Jan 14, 2015 12:58 PM, devrandom c1.sf-bitc...@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.
14 matches
Mail list logo
