{"type":"rich","version":"1.0","author_name":"npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47","author_url":"https://nostr.ae/npub10f96gqrsu4qpygfgvuvzce47aavjvql703egfde0l2hua8dzpszs67ej47","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2014-03-27\n📝 Original message:Le 27/03/2014 00:37, Andreas Schildbach a écrit :\n\u003e Thanks for starting the discussion on finding a better structure.\n\u003e\n\u003e For me, the most important thing is either we're 100% interoperable or\n\u003e 0%. There should not be anything inbetween, as users will delete seeds\n\u003e without knowing there is still money in them on another implementation.\n\nI believe you have a good point here: we should not advertise wallets as\ncompatible if they are not 100% compatible.\n\nOne issue that I have is bandwidth: Electrum (and mycelium) cannot\nwatch as many addresses as they want, because this will create too\nmuch traffic on the servers. (especially when servers send utxo merkle\nproofs for each address, which is not the case yet, but is planned)\n\nFor this reason Electrum imposes a constraint on the number of virgin\naddresses provided to the user. Although the current strategy used by\nElectrum can certainly be improved, it will not scale up to having every\nclient watching thousands of addresses.\n\nThis constraint is not so important for bloom-filter clients. So I guess \nthat\nit makes sense for Multibit to provide hundreds, or even thousands of \nvirgin\naddresses to the user, regardless of how they are used. Such a wallet will\nin general not be recoverable in Electrum, unless the user \"helps\" the\nrecovery procedure. (or the seed has metadata telling the software that\nthis is a Multibit wallet). So we have a problem here, if we advertise \nthese\nwallets as compatible.\n\nMy opinion, as far as Electrum is concerned, is that merchant accounts\nshould behave differently from regular user accounts: While merchants\nneed to generate an unlimited number of receiving addresses, it is also\nacceptable for them to have a slightly more complex wallet recovery \nprocedure\n(for example, the wallet might show an option to \"search for more \naddresses\",\nand it might not need to watch \"old\" addresses anymore)\n\nOTOH, I don't think we can ask regular users to do this, not only \nbecause it\nadds complexity to the wallet recovery procedure (which makes it scarier),\nbut also because we want fully automated synchronization between different\ninstances of a wallet, using only no other source of information than \nthe blockchain.\n\nThe first versions of Electrum allowed users to set the \"gap limit\" \nparameter\nin their GUI preferences, but I removed it from GUI after I realized it \nwas a bad\nidea (users messed with it and did not understand what happened..)\n\nWith bloom filter clients I guess the distinction between these two use \ncases\nis not really necessary, because watching addresses is cheap. So it \nwould be\ngood to hear what you and Mike think about this problem. If you decide \nto let\nthe user create hundreds of unused addresses (and I think it perfectly \nmakes\nsense for you), then I guess it would be better for Electrum to give up on\ncompatibility, rather than running the risk of seeing only a subset of \naddresses.\nAnother option is to handle these seeds as \"merchant\" accounts.\n\n\n\n\n\u003e I heard from multiple sources that using this standard some wallets will\n\u003e only see a subset of the addresses/keys of some other wallets.\n\u003e Implementation differences can always happen (and should addresses as\n\u003e bugs), but I think its unacceptable that this source of issues is by design.\n\u003e\n\u003e I suggest we agree on an even simpler least common denominator and\n\u003e wallets that want to implement some feature on top of that can do but\n\u003e are encouraged to pick a totally different \"cointype\". I guess that\n\u003e would mean removing reserved and account.\n\n\u003e\n\u003e I'm still thinking it might be a good idea to have a separate chain for\n\u003e \"refunds\". Refunds will be rarely used and thus need a much slower\n\u003e moving window than receiving addresses or change.\n\u003e\n\u003e\n\u003e On 03/26/2014 09:49 PM, Mike Hearn wrote:\n\u003e\u003e Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure\n\u003e\u003e our BIP32 wallet structures would be compatible - and I discovered that\n\u003e\u003e only I was planning to use the default structure.\n\u003e\u003e\n\u003e\u003e Because I'm hopeful that we can get a lot of interoperability between\n\u003e\u003e wallets with regards to importing 12-words paper wallets, we\n\u003e\u003e brainstormed to find a structure acceptable to everyone and ended up with:\n\u003e\u003e\n\u003e\u003e    /m/cointype/reserved'/account'/change/n\n\u003e\u003e\n\u003e\u003e The extra levels require some explanation:\n\u003e\u003e\n\u003e\u003e    * cointype:  This is zero for Bitcoin. This is here to support two\n\u003e\u003e      things, one is supporting alt coins based off the same root seed.\n\u003e\u003e      Right now nobody seemed very bothered about alt coins but sometimes\n\u003e\u003e      feature requests do come in for this. Arguably there is no need and\n\u003e\u003e      alt coins could just use the same keys as Bitcoin, but it may help\n\u003e\u003e      avoid confusion if they don't.\n\u003e\u003e\n\u003e\u003e      More usefully, cointype can distinguish between keys intended for\n\u003e\u003e      things like multisig outputs, e.g. for watchdog services. This means\n\u003e\u003e      if your wallet does not know about the extra protocol layers\n\u003e\u003e      involved in this, it can still import the \"raw\" money and it will\n\u003e\u003e      just ignore/not see the keys used in more complex transactions.\n\u003e\u003e\n\u003e\u003e    * reserved is for \"other stuff\". I actually don't recall why we ended\n\u003e\u003e      up with this. It may have been intended to split out multisig\n\u003e\u003e      outputs etc from cointype. Marek, Thomas?\n\u003e\u003e\n\u003e\u003e    * account is for keeping essentially wallets-within-a-wallet to avoid\n\u003e\u003e      mixing of coins. If you want that.\n\u003e\u003e\n\u003e\u003e    * change is 0 for receiving addresses, 1 for change addresses.\n\u003e\u003e\n\u003e\u003e    * n is the actual key index\n\u003e\u003e\n\u003e\u003e For bitcoinj we're targeting a deliberately limited feature set for hdw\n\u003e\u003e v1 so I would just set the first three values all to zero and that is a\n\u003e\u003e perfectly fine way to be compatible.\n\u003e\u003e\n\u003e\u003e The goal here is that the same seed can be written down once, and meet\n\u003e\u003e all the users needs, whilst still allowing some drift between what\n\u003e\u003e wallets support.\n\u003e\u003e\n\u003e\u003e Pieter made the I think valid point that you can't really encode how\n\u003e\u003e keys are meant to be used into just an HDW hierarchy and normally you'd\n\u003e\u003e need some metadata as well. However, I feel interop between wallets is\n\u003e\u003e more important than arriving at the most perfect possible arrangement,\n\u003e\u003e which feels a little like bikeshedding, so I'm happy to just go with the\n\u003e\u003e flow on this one.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ------------------------------------------------------------------------------\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e Bitcoin-development mailing list\n\u003e\u003e Bitcoin-development at lists.sourceforge.net\n\u003e\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\u003e\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\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"}