{"type":"rich","version":"1.0","author_name":"npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","author_url":"https://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-04-23\n📝 Original message:Different users could have different gap limit requirements.  20 seems very\nlow as the default.\n\nA merchant could easily send 20 addresses in a row to customers and none of\nthem bother to actually buy anything.\n\nSetting the gap limit to high is just a small extra cost in that case.\n\nBip-32 serialization doesn't have a way of adding meta data though.\n\n\nOn Wed, Apr 23, 2014 at 7:18 PM, slush \u003cslush at centrum.cz\u003e wrote:\n\n\u003e For those who don't follow github pull requests regularly; there's pull\n\u003e request for BIP64 defining HD wallet structure as discussed in this thread:\n\u003e\n\u003e https://github.com/bitcoin/bips/pull/52\n\u003e\n\u003e\n\u003e\n\u003e On Wed, Apr 23, 2014 at 8:01 PM, slush \u003cslush at centrum.cz\u003e wrote:\n\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille \u003cpieter.wuille at gmail.com\u003ewrote:\n\u003e\u003e\u003e\n\u003e\u003e\u003e Storing the seed is superior to storing the master node already\n\u003e\u003e\u003e (whether coin specific or not), as it is smaller.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e ...Except that you're loosing flexibility (serialization,\n\u003e\u003e deserialization) which gives you BIP32 node.\n\u003e\u003e\n\u003e\u003e I see \"bip32 seed\" as some transitional, internal state from raw entropy\n\u003e\u003e to bip32 master node and this seed should not be handled by the end user in\n\u003e\u003e any form. In the oposite, well-serialized bip32 node (in xpriv, or even in\n\u003e\u003e mnemonic format) can be used very widely and have no downsides against\n\u003e\u003e using raw \"bip32 seed\".\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e Fair enough, it would break strictly BIP32. Then again, BIP32 is a\n\u003e\u003e\u003e *Bitcoin* improvement proposal, and not something that necessarily\n\u003e\u003e\u003e applies to other coins (they can adopt it of course, I don't care).\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e I also don't care too much about altcoins, but people want them so me, as\n\u003e\u003e infrastructure developer, need to think about it. And I don't see any\n\u003e\u003e reason for breaking compatibility between Bitcoin and other altcoins. I\n\u003e\u003e would be happier if there will be another sentence than \"Bitcoin seed\", but\n\u003e\u003e honestly, who cares. It is just some magic string for hashing the raw\n\u003e\u003e seed...\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\u003e What I dislike is that this removes the ability of using the magic in\n\u003e\u003e\u003e the serialization to prevent importing a chain from the wrong coin.\n\u003e\u003e\u003e\n\u003e\u003e\n\u003e\u003e The truth is that even existing software which handle bip32 don't care\n\u003e\u003e about 'version' at all. I think that \"xpub/xprv\" distinction is the only\n\u003e\u003e useful feature of version, so user se if it stores public or private\n\u003e\u003e information.\n\u003e\u003e\n\u003e\u003e But using prefixes which doesn't enforce anything is even more dangerous.\n\u003e\u003e If somebody exports node \"dogeblablabla\", it creates false exceptations\n\u003e\u003e that there's only dogecoin stored.\n\u003e\u003e\n\u003e\u003e  Marek\n\u003e\u003e\n\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Start Your Social Network Today - Download eXo Platform\n\u003e Build your Enterprise Intranet with eXo Platform Software\n\u003e Java Based Open Source Intranet - Social, Extensible, Cloud Ready\n\u003e Get Started Now And Turn Your Intranet Into A Collaboration Platform\n\u003e http://p.sf.net/sfu/ExoPlatform\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/dd62bab3/attachment.html\u003e"}