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
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
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 :)
Jean-Pierre Rupp from Haskoin here.
I support a hard fork to fix consensus bugs. The Bitcoin protocol should
eventually get to a state where it is documented in a clear and understandable
fashion. Bugs are bugs, and are the enemy. We should not attempt to live with
them. We should
Hello people,
We are working on some of this stuff. We had some very early draft on
how we envisioned multisig happening. It is all implemented in Haskoin
available as multiple repositories in Github. I am happy to see this
gathering momentum.
Our multisig system uses BIP-0032 HD wallets, and
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Una potencial falla de seguridad ha sido descubierta en Bitcoin-Qt
para Windows. Si tienes Bitcoin-Qt para Windows en alguna versión
entre 0.5 y 0.6, deberías salir del programa, y actualizar a la
versión 0.5.3.1 o 0.6rc4 AHORA.
La aplicación de
6 matches
Mail list logo
