slush [ARCHIVE] on Nostr: 📅 Original date posted:2014-04-23 📝 Original message:For those who don't follow ...
📅 Original date posted:2014-04-23
📝 Original message:For those who don't follow github pull requests regularly; there's pull
request for BIP64 defining HD wallet structure as discussed in this thread:
https://github.com/bitcoin/bips/pull/52
On Wed, Apr 23, 2014 at 8:01 PM, slush <slush at centrum.cz> wrote:
>
>
>
> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>>
>> Storing the seed is superior to storing the master node already
>> (whether coin specific or not), as it is smaller.
>>
>>
> ...Except that you're loosing flexibility (serialization, deserialization)
> which gives you BIP32 node.
>
> I see "bip32 seed" as some transitional, internal state from raw entropy
> to bip32 master node and this seed should not be handled by the end user in
> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
> mnemonic format) can be used very widely and have no downsides against
> using raw "bip32 seed".
>
>
>>
>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>> *Bitcoin* improvement proposal, and not something that necessarily
>> applies to other coins (they can adopt it of course, I don't care).
>>
>>
> I also don't care too much about altcoins, but people want them so me, as
> infrastructure developer, need to think about it. And I don't see any
> reason for breaking compatibility between Bitcoin and other altcoins. I
> would be happier if there will be another sentence than "Bitcoin seed", but
> honestly, who cares. It is just some magic string for hashing the raw
> seed...
>
>
>> What I dislike is that this removes the ability of using the magic in
>> the serialization to prevent importing a chain from the wrong coin.
>>
>
> The truth is that even existing software which handle bip32 don't care
> about 'version' at all. I think that "xpub/xprv" distinction is the only
> useful feature of version, so user se if it stores public or private
> information.
>
> But using prefixes which doesn't enforce anything is even more dangerous.
> If somebody exports node "dogeblablabla", it creates false exceptations
> that there's only dogecoin stored.
>
> Marek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/ffd687fd/attachment.html>;
📝 Original message:For those who don't follow github pull requests regularly; there's pull
request for BIP64 defining HD wallet structure as discussed in this thread:
https://github.com/bitcoin/bips/pull/52
On Wed, Apr 23, 2014 at 8:01 PM, slush <slush at centrum.cz> wrote:
>
>
>
> On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille at gmail.com>wrote:
>>
>> Storing the seed is superior to storing the master node already
>> (whether coin specific or not), as it is smaller.
>>
>>
> ...Except that you're loosing flexibility (serialization, deserialization)
> which gives you BIP32 node.
>
> I see "bip32 seed" as some transitional, internal state from raw entropy
> to bip32 master node and this seed should not be handled by the end user in
> any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
> mnemonic format) can be used very widely and have no downsides against
> using raw "bip32 seed".
>
>
>>
>> Fair enough, it would break strictly BIP32. Then again, BIP32 is a
>> *Bitcoin* improvement proposal, and not something that necessarily
>> applies to other coins (they can adopt it of course, I don't care).
>>
>>
> I also don't care too much about altcoins, but people want them so me, as
> infrastructure developer, need to think about it. And I don't see any
> reason for breaking compatibility between Bitcoin and other altcoins. I
> would be happier if there will be another sentence than "Bitcoin seed", but
> honestly, who cares. It is just some magic string for hashing the raw
> seed...
>
>
>> What I dislike is that this removes the ability of using the magic in
>> the serialization to prevent importing a chain from the wrong coin.
>>
>
> The truth is that even existing software which handle bip32 don't care
> about 'version' at all. I think that "xpub/xprv" distinction is the only
> useful feature of version, so user se if it stores public or private
> information.
>
> But using prefixes which doesn't enforce anything is even more dangerous.
> If somebody exports node "dogeblablabla", it creates false exceptations
> that there's only dogecoin stored.
>
> Marek
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/ffd687fd/attachment.html>;