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:
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 :)
There are many legitimate uses for a larger OP_RETURN, and application
developers are already complaining that the current size is not enough. It is
about adding value to the blockchain. I know it can grow the blockchain
faster, but so far at 40 bytes Bitcoin hasn't experienced death
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
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
Our multisig system uses BIP-0032 HD wallets, and
-BEGIN PGP SIGNED MESSAGE-
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
Mail list logo