Hi Matt,

I think your best bet is probably just push it out privately via blog post / Github, and see if it gains any traction with other developers.

I'm a little uncertain as to the relevance though.  All those variables (purpose, network, asset_type, account, change, index) need to be stored internally within the wallet database, as there's no way to retrieve the path used from just the address, correct?  In that case, what's the meaning of that exact path structure when a) it can't be retrieved from just the address, and b) the values will be stored internally within the wallet when you lookup the address.

Matt



On 06/20/2015 03:42 AM, Matt Smith wrote:
Hey guys,

The crew at Gem is considering a new HD wallet path structure for our
wallets, which are coin-agnostic, that separates the coin_type field
into two fields as such:

m / purpose' / network' / asset_type' / account' / change / index

where network refers to the blockchain (0 - bitcoin, 1 - testnet3, 2 -
litecoin, etc) and the new asset_type refers to the kind of asset to be
held in accounts below that path (Open Assets, Omni, Counterparty).

The intent is to allow us to validate the address format, select the
appropriate daemon to scan for tokenized assets, and choose multiple
blockchain data sources (that may not know anything about token systems
running on the blockchain they expose) relevant to an HDNode in the
wallet using only information in the HDNode's path -- without having to
maintain an explicit mapping of coin_type -> network.

For example, we already have the issue of mapping network identifiers
because of the lack of standardization across cryptocurrency libraries
which ends up being ugly and obnoxious to maintain, i.e.

netcode_map = {
  testnet: testnet3,
  bitcoin_testnet: testnet3,
  testnet3: testnet3,
  XTN: testnet3, ...
}
netcode_i_want = netcode_map[netcode_returned_by_libwhatever]

We want to avoid maintaining a similar asset_type_to_blockchain mapping.
Additionally, it would be helpful for utxo selection to exclude utxos
tied to assets based on path.

BIP43 seems to suggest that we request a BIP number and publish an
informational BIP specifying the new purpose. If that's not appropriate,
then maybe we just need to publish the information in a blog post to
allow any wallet developers who want to to implement
import_from_gem_structure.

I was also wondering if anyone had previously suggested something
similar that I missed when cruising the mailing list archives on the
subject.

Thanks,
–
Matt Smith | Gem
https://gem.co | GH: @thedoctor


------------------------------------------------------------------------------


_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development