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@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:

https://github.com/bitcoin/bips/pull/52



On Wed, Apr 23, 2014 at 8:01 PM, slush <slush@centrum.cz> wrote:



On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille <pieter.wuille@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


------------------------------------------------------------------------------
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
http://p.sf.net/sfu/ExoPlatform
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development