> to avoid having an internal mapping from 9'-> 0' to find out what > blockchain to query, this sounds like it should be trivial for any wallet.
Trivial to implement, a headache to *maintain* But if a new platform is released on an existing blockchain, my wallet doesn't need to know about the new magic number it claims in order to handle it correctly. Say I make a new token layer, BobCoin, which runs on bitcoin and say I use an HD wallet and always generate new BobCoin token addresses as m/##'/0'/808'/*'/*/*. If I import that wallet into older HD wallet software that doesn't know anything about BobCoin, it will still: - understand what blockchain to query for utxos on the addresses below that path - be able to generate valid BobCoin addresses without any updates I think this is particularly valuable if you're developing against a platform where updates can't be forced on clients. To be clear: I am not suggesting this as a general-purpose successor to BIP44. – Matt Smith | Gem https://gem.co | GH: @thedoctor On 6/19/15 5:57 PM, Andreas Petersson wrote: >> m/##'/0'/99'/0' >> >> where 99 is the identifier for, say, counterparty > > > What is stopping you from using m/44'/9'/a'/c/i as descibed here: > http://doc.satoshilabs.com/slips/slip-0044.html > > to avoid having an internal mapping from 9'-> 0' to find out what > blockchain to query, this sounds like it should be trivial for any wallet. > > > ------------------------------------------------------------------------------ > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >
signature.asc
Description: OpenPGP digital signature
------------------------------------------------------------------------------
_______________________________________________ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
