rich1.0npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqghttps://nostr.ae/npub1xvnnyhz8e4eklaakjc9xgm5w8pzkuckt923uacz2cftqdqx23g7q3c5rqgnjumphttps://nostr.ae📅 Original date posted:2014-03-27 📝 Original message:The benefit I see is avoiding reuse of keys between coins while not having each wallet implementation have to know about each coin in order to scan for transactions. Wallet X supports Doge and Bitcoin. If both used a shared sequence of keys, say the first two end up Bitcoin, then 10 Doge, then some more Bitcoin. If you took this seed to Wallet Y, which only supports Bitcoin (either the wallet's support or what is installed on the system it's being used), it will see a gap of 10 addresses, and presume no more scanning with a 5 gap limit. The alternative is to reuse keys for each coin. It also seems like a solution might be to only expect interoperability on a single sequence, and provide backups of each final sequence to use between different wallet implementations. This allows flexibility in hierarchies depending on needs and support of wallet, but allows sharing. The short seed would only be useful for the same wallet, but sharing between wallets would use the longer keys. That will give predictable behavior for users (although less friendly) and lead to less errors. -Allen On Thu, Mar 27, 2014 at 11:28 AM, Pieter Wuille <pieter.wuille at gmail.com>wrote: > On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak <stick at gk2.sk> wrote: > > Cointype in path is for separation purposes, not for identification. > > I don't understand what that gains you. > > -- > Pieter > > > ------------------------------------------------------------------------------ > _______________________________________________ > 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/20140327/0e05360a/attachment.html>