rich1.0npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdhttps://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdnjumphttps://nostr.ae📅 Original date posted:2014-04-23 📝 Original message: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: > > 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 >> > > > > ------------------------------------------------------------------------------ > 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 at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140423/dd62bab3/attachment.html>