It's a problem if you work with iterators to deserialize the byte stream. Even
failing that, it's just sloppy programming. What happens in the future when new
fields are added to the version message? It's not a big deal to say that this
protocol version has X number of fields, that (higher)
Bitcoin-Qt on master does send it now although it doesn't affect anything,
but as old pre-filtering versions will continue to exist, you'll always
have to be able to deserialize version messages without it.
Bitcoin version messages have always had variable length, look at how the
code is written
On 18 June 2013 05:48, Alan Reiner etothe...@gmail.com wrote:
*Goal*: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead of
the standard one-use Base58-Hash160 addresses. This allows parties with a
persistent
If you want to criticise the Bitcoin protocol for sloppyness, the variable
length of some messages isn't where I'd start.
Note that ping has the same issue, its length has changed over time to
include the nonce.
If your parser can't handle that kind of thing, you need to fix it. The
protocol has
I’m also running into this exact same issue with my parser, now I understand
why the relay field behavior I was seeing doesn’tmatch the wiki.
So to parse a version message, you can’t rely on the protocol version? You have
to know how long the payload is, and then parse the message accordingly?
On 06/19/2013 08:19 AM, Melvin Carvalho wrote:
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be
less keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar
On Mon, Jun 17, 2013 at 11:48:22PM -0400, Alan Reiner wrote:
_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
checksum)
Also suppose the payee has spent the
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
This maybe simpler and trivially compatible with existing type2 public keys
(ones that are multiples of a parent public key): send an ECDSA signature of
the multiplier, and as we know you can compute (recover) the parent public
key from an the ECDSA signature made using it.
Adam
On Wed, Jun 19,
On 06/19/2013 02:36 PM, Adam Back wrote:
This maybe simpler and trivially compatible with existing type2 public
keys
(ones that are multiples of a parent public key): send an ECDSA
signature of
the multiplier, and as we know you can compute (recover) the parent
public
key from an the ECDSA
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the canonical way
to do this with BIP32 is for the parties to exchange PubKey and *ChainCode*.
I don’t understand the use case for handing out individual
On Wed, Jun 19, 2013 at 10:39:04AM -0400, Alan Reiner wrote:
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~
On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the
canonical way to do this with BIP32 is for the parties to exchange
PubKey and *ChainCode*.
I don't
Hi Alan,
“BIP 32 does not prescribe a way to use multiple chains like you described
with the convenient type-2 derivation (though we could create a variant
that does)”
What do you think is missing from BIP32 for this? A wallet creates a
child-node using the public / type-2 CDF, hands out
On 06/19/2013 05:58 PM, Jeremy Spilman wrote:
Hi Alan,
“BIP 32 does not prescribe a way to use multiple chains like you described
with the convenient type-2 derivation (though we could create a variant
that does)”
What do you think is missing from BIP32 for this? A wallet creates a
BIP 32 already specifies how to use the first three tree levels: M/i/j/k,
i~wallet, j~Internal/External, k~address. The first level is actually
type-1 derived, and thus we cannot create an arbitrary number of them
without pre-computing them from the offline wallet. So it's not free to
17 matches
Mail list logo
