I never said that Bitcoin message field lengths should always be the same. But
before this change they certainly were constant per protocol version. All I'm
saying is that optional lengths shouldn't be used (a field exists or not) and
for every field change, the protocol version should be upgrad
> 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"
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
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 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 und
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":
> >>Standar
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 multiplie
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 th
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,
I think Timo's point is that while you cant do discrete log, you can do y-th
root. So if P = xG is a parent public key (x private key, G base point),
then your proposed multiplier address is hash of Q=yP. However its easy to
find another P such that Q=zP'. ie just "divide by z" (EC multiply by z
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]) ||
>>
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 out
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 persis
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 fam
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?
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
On 18 June 2013 05:48, 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 relationship
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 i
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) prot
It has to be optional because old clients don't send it, obviously.
Why is this even an issue? There's no problem with variable length messages
in any codebase that I'm aware of. Is this solving some actual problem?
On Wed, Jun 19, 2013 at 12:30 AM, Turkey Breast wrote:
> That's me. I never sai
20 matches
Mail list logo
