From: Thomas Voegtlin <thomasv1@gmx•de>
To: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] New BIP32 structure
Date: Thu, 27 Mar 2014 11:57:42 +0100 [thread overview]
Message-ID: <53340426.4040208@gmx.de> (raw)
In-Reply-To: <lgvobr$q44$1@ger.gmane.org>
Le 27/03/2014 00:37, Andreas Schildbach a écrit :
> Thanks for starting the discussion on finding a better structure.
>
> For me, the most important thing is either we're 100% interoperable or
> 0%. There should not be anything inbetween, as users will delete seeds
> without knowing there is still money in them on another implementation.
I believe you have a good point here: we should not advertise wallets as
compatible if they are not 100% compatible.
One issue that I have is bandwidth: Electrum (and mycelium) cannot
watch as many addresses as they want, because this will create too
much traffic on the servers. (especially when servers send utxo merkle
proofs for each address, which is not the case yet, but is planned)
For this reason Electrum imposes a constraint on the number of virgin
addresses provided to the user. Although the current strategy used by
Electrum can certainly be improved, it will not scale up to having every
client watching thousands of addresses.
This constraint is not so important for bloom-filter clients. So I guess
that
it makes sense for Multibit to provide hundreds, or even thousands of
virgin
addresses to the user, regardless of how they are used. Such a wallet will
in general not be recoverable in Electrum, unless the user "helps" the
recovery procedure. (or the seed has metadata telling the software that
this is a Multibit wallet). So we have a problem here, if we advertise
these
wallets as compatible.
My opinion, as far as Electrum is concerned, is that merchant accounts
should behave differently from regular user accounts: While merchants
need to generate an unlimited number of receiving addresses, it is also
acceptable for them to have a slightly more complex wallet recovery
procedure
(for example, the wallet might show an option to "search for more
addresses",
and it might not need to watch "old" addresses anymore)
OTOH, I don't think we can ask regular users to do this, not only
because it
adds complexity to the wallet recovery procedure (which makes it scarier),
but also because we want fully automated synchronization between different
instances of a wallet, using only no other source of information than
the blockchain.
The first versions of Electrum allowed users to set the "gap limit"
parameter
in their GUI preferences, but I removed it from GUI after I realized it
was a bad
idea (users messed with it and did not understand what happened..)
With bloom filter clients I guess the distinction between these two use
cases
is not really necessary, because watching addresses is cheap. So it
would be
good to hear what you and Mike think about this problem. If you decide
to let
the user create hundreds of unused addresses (and I think it perfectly
makes
sense for you), then I guess it would be better for Electrum to give up on
compatibility, rather than running the risk of seeing only a subset of
addresses.
Another option is to handle these seeds as "merchant" accounts.
> I heard from multiple sources that using this standard some wallets will
> only see a subset of the addresses/keys of some other wallets.
> Implementation differences can always happen (and should addresses as
> bugs), but I think its unacceptable that this source of issues is by design.
>
> I suggest we agree on an even simpler least common denominator and
> wallets that want to implement some feature on top of that can do but
> are encouraged to pick a totally different "cointype". I guess that
> would mean removing reserved and account.
>
> I'm still thinking it might be a good idea to have a separate chain for
> "refunds". Refunds will be rarely used and thus need a much slower
> moving window than receiving addresses or change.
>
>
> On 03/26/2014 09:49 PM, Mike Hearn wrote:
>> Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
>> our BIP32 wallet structures would be compatible - and I discovered that
>> only I was planning to use the default structure.
>>
>> Because I'm hopeful that we can get a lot of interoperability between
>> wallets with regards to importing 12-words paper wallets, we
>> brainstormed to find a structure acceptable to everyone and ended up with:
>>
>> /m/cointype/reserved'/account'/change/n
>>
>> The extra levels require some explanation:
>>
>> * cointype: This is zero for Bitcoin. This is here to support two
>> things, one is supporting alt coins based off the same root seed.
>> Right now nobody seemed very bothered about alt coins but sometimes
>> feature requests do come in for this. Arguably there is no need and
>> alt coins could just use the same keys as Bitcoin, but it may help
>> avoid confusion if they don't.
>>
>> More usefully, cointype can distinguish between keys intended for
>> things like multisig outputs, e.g. for watchdog services. This means
>> if your wallet does not know about the extra protocol layers
>> involved in this, it can still import the "raw" money and it will
>> just ignore/not see the keys used in more complex transactions.
>>
>> * reserved is for "other stuff". I actually don't recall why we ended
>> up with this. It may have been intended to split out multisig
>> outputs etc from cointype. Marek, Thomas?
>>
>> * account is for keeping essentially wallets-within-a-wallet to avoid
>> mixing of coins. If you want that.
>>
>> * change is 0 for receiving addresses, 1 for change addresses.
>>
>> * n is the actual key index
>>
>> For bitcoinj we're targeting a deliberately limited feature set for hdw
>> v1 so I would just set the first three values all to zero and that is a
>> perfectly fine way to be compatible.
>>
>> The goal here is that the same seed can be written down once, and meet
>> all the users needs, whilst still allowing some drift between what
>> wallets support.
>>
>> Pieter made the I think valid point that you can't really encode how
>> keys are meant to be used into just an HDW hierarchy and normally you'd
>> need some metadata as well. However, I feel interop between wallets is
>> more important than arriving at the most perfect possible arrangement,
>> which feels a little like bikeshedding, so I'm happy to just go with the
>> flow on this one.
>>
>>
>>
>> ------------------------------------------------------------------------------
>>
>>
>>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development@lists•sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>>
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
next prev parent reply other threads:[~2014-03-27 10:57 UTC|newest]
Thread overview: 100+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-26 20:49 Mike Hearn
2014-03-26 23:37 ` Andreas Schildbach
2014-03-27 1:01 ` Alan Reiner
2014-03-27 6:15 ` Mike Belshe
2014-03-27 10:57 ` Thomas Voegtlin [this message]
2014-03-27 11:39 ` Mike Hearn
2014-03-27 13:30 ` Thomas Voegtlin
2014-03-27 13:38 ` Mike Hearn
2014-03-27 1:13 ` Allen Piscitello
2014-03-27 5:34 ` Troy Benjegerdes
2014-03-27 7:09 ` Tamas Blummer
2014-03-27 9:42 ` Mike Hearn
2014-03-27 11:35 ` Pavol Rusnak
2014-03-27 15:43 ` Jeff Garzik
2014-03-27 15:57 ` Allen Piscitello
2014-03-27 16:06 ` Pavol Rusnak
2014-03-27 16:13 ` Allen Piscitello
2014-03-27 16:07 ` Tamas Blummer
2014-03-27 16:14 ` Pieter Wuille
2014-03-27 16:21 ` Pavol Rusnak
2014-03-27 16:28 ` Pieter Wuille
2014-03-27 17:49 ` Allen Piscitello
2014-03-28 14:59 ` slush
2014-04-08 12:43 ` slush
2014-04-08 13:18 ` Pieter Wuille
2014-04-08 13:40 ` slush
2014-04-08 13:43 ` slush
2014-04-08 13:53 ` Pieter Wuille
2014-04-08 13:59 ` Thomas Voegtlin
2014-04-08 14:00 ` Tamas Blummer
2014-04-08 14:35 ` Pavol Rusnak
2014-04-08 15:41 ` slush
2014-04-23 17:42 ` Pieter Wuille
2014-04-23 18:01 ` slush
2014-04-23 18:18 ` slush
2014-04-23 18:39 ` Tier Nolan
2014-04-23 18:46 ` Pavol Rusnak
2014-04-23 19:00 ` Tier Nolan
2014-04-23 19:06 ` slush
2014-04-23 19:36 ` Tamas Blummer
2014-04-23 19:46 ` slush
2014-04-23 19:07 ` Tamas Blummer
2014-04-23 19:29 ` Pavol Rusnak
2014-04-23 19:44 ` Luke-Jr
2014-04-23 19:49 ` Pavol Rusnak
2014-04-23 19:55 ` Luke-Jr
2014-04-23 19:57 ` slush
2014-04-23 20:01 ` Luke-Jr
2014-04-23 20:04 ` Pavol Rusnak
2014-04-23 20:09 ` Luke-Jr
2014-04-23 20:16 ` Pavol Rusnak
2014-04-23 20:32 ` Luke-Jr
2014-04-23 20:35 ` Pavol Rusnak
2014-04-23 20:41 ` Luke-Jr
2014-04-23 20:43 ` Pavol Rusnak
2014-04-23 20:54 ` Pieter Wuille
2014-04-23 21:06 ` Pavol Rusnak
2014-04-23 21:18 ` Luke-Jr
2014-04-23 21:22 ` Gregory Maxwell
2014-04-23 21:33 ` Pavol Rusnak
2014-04-23 21:42 ` Pieter Wuille
2014-04-23 21:44 ` Pavol Rusnak
2014-04-23 21:48 ` Gregory Maxwell
2014-04-23 21:53 ` Luke-Jr
2014-04-23 21:24 ` Pavol Rusnak
2014-04-23 21:07 ` slush
2014-04-23 20:59 ` Luke-Jr
2014-04-23 20:17 ` Tamas Blummer
2014-04-23 20:12 ` Pieter Wuille
2014-04-23 20:08 ` Pieter Wuille
2014-04-23 20:01 ` Tamas Blummer
2014-04-23 20:02 ` Luke-Jr
2014-04-23 20:04 ` Tamas Blummer
2014-04-24 6:54 ` Thomas Voegtlin
2014-04-24 7:10 ` Pieter Wuille
2014-04-24 7:21 ` Gregory Maxwell
2014-04-24 8:15 ` Thomas Voegtlin
2014-04-24 7:42 ` Thomas Voegtlin
2014-04-24 8:09 ` Mike Hearn
2014-04-23 18:48 ` Tamas Blummer
2014-04-08 14:49 ` Andreas Schildbach
2014-04-08 15:46 ` slush
2014-04-08 15:58 ` Andreas Schildbach
2014-04-08 16:24 ` slush
2014-03-27 11:20 ` Thomas Voegtlin
[not found] ` <CAJna-HhmFya+3W67qQt0wMhW=B4vJvwdkr-5WnU+KEaKq7uaUA@mail.gmail.com>
2014-03-27 12:06 ` Thomas Voegtlin
2014-03-27 12:28 ` Mike Hearn
2014-03-27 12:49 ` Mike Hearn
2014-03-27 13:12 ` Thomas Kerin
2014-03-27 13:19 ` Mike Hearn
2014-03-27 13:49 ` Thomas Voegtlin
2014-03-27 13:58 ` Jim
2014-03-27 14:20 ` Mike Hearn
2014-03-27 15:17 ` Troy Benjegerdes
2014-03-27 13:07 ` Matias Alejo Garcia
2014-03-27 13:44 ` Pavol Rusnak
2014-03-27 13:53 ` Thomas Voegtlin
2014-03-27 14:03 ` Pavol Rusnak
[not found] ` <CAJna-HitjJbL9TnfxTY=+TvfaeNvZM6aPWmNYmHUCwmw6V8PUg@mail.gmail.com>
2014-03-27 15:04 ` Thomas Voegtlin
2014-03-27 11:36 ` Pavol Rusnak
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=53340426.4040208@gmx.de \
--to=thomasv1@gmx$(echo .)de \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox