[Bitcoin-development] New BIP32 structure
tier.nolan at gmail.com
Wed Apr 23 18:39:40 UTC 2014
Different users could have different gap limit requirements. 20 seems very
low as the default.
A merchant could easily send 20 addresses in a row to customers and none of
them bother to actually buy anything.
Setting the gap limit to high is just a small extra cost in that case.
Bip-32 serialization doesn't have a way of adding meta data though.
On Wed, Apr 23, 2014 at 7:18 PM, slush <slush at centrum.cz> wrote:
> 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:
> 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
>>> 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
>> 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.
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bitcoin-dev