From: Tier Nolan <tier.nolan@gmail.com>
To: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP32 "wallet structure" in use? Remove it?
Date: Sat, 26 Apr 2014 11:48:07 +0100 [thread overview]
Message-ID: <CAE-z3OWcZdQ0J3vNYQ7whGHOZZzMh=wYKxCKtrf1i8VSseZArQ@mail.gmail.com> (raw)
In-Reply-To: <535B8C43.8030502@gmx.de>
[-- Attachment #1: Type: text/plain, Size: 4408 bytes --]
Maybe the solution is to have a defined way to import an unknown wallet?
This means that the gap space and a search ordering needs to be defined.
Given a blockchain and a root seed, it should be possible to find all the
addresses for that root seed.
The hierarchy that the wallet actually uses could be anything.
On Sat, Apr 26, 2014 at 11:36 AM, Thomas Voegtlin <thomasv1@gmx.de> wrote:
> I totally agree with gmaxwell here. The cost of interoperability is too
> high. It would force us to freeze all features, and to require a broad
> consensus everytime we want to add something new.
>
> In addition, some partial level of compatibility would probably lead to
> users not able to recover all their funds when they enter their seed in
> another wallet. That is not acceptable, and should be avoided.
>
>
>
>
> Le 25/04/2014 17:46, Gregory Maxwell a écrit :
> >
> > I don't believe that wallet interoperability at this level is possible
> > in general except as an explicit compatibility feature. I also don't
> > believe that it is a huge loss that it is so.
> >
> > The structure of the derivation defines and constrains functionality.
> > You cannot be structure compatible unless you have the same features
> > and behavior with respect to key management. To that extent that
> > wallets have the same features, I agree its better if they are
> > compatible— but unless they are dead software they likely won't keep
> > the same features for long.
> >
> > Even if their key management were compatible there are many other
> > things that go into making a wallet portable between systems; the
> > handling of private keys is just one part: a complete wallet will
> > have other (again, functionality specific) metadata.
> >
> > I agree that it would be it would be possible to support a
> > compatibility mode where a wallet has just a subset of features which
> > works when loaded into different systems, but I'm somewhat doubtful
> > that it would be widely used. The decision to use that mode comes at
> > the wrong time— when you start, not when you need the features you
> > chose to disable or when you want to switch programs. But the obvious
> > thing to do there is to just specify that a linear chain with no
> > further branching is that mode: then that will be the same mode you
> > use when someone gives you a master public key and asks you to use it
> > for reoccurring changes— so at least the software will get used.
> >
> > Compatibility for something like a recovery tool is another matter,
> > and BIP32 probably defines enough there that with a bit of extra data
> > about how the real wallet worked that recovery can be successful.
> >
> > Calling it "vendor lock in" sounds overblown to me. If someone wants
> > to change wallets they can transfer the funds— manual handling of
> > private keys is seldom advisable, and as is they're going to lose
> > their metadata in any case. No one expects to switch banks and to
> > keep their account records at the new bank. And while less than
> > perfect, the price of heavily constraining functionality in order to
> > get another result is just too high.
> >
> >
> ------------------------------------------------------------------------------
> > Start Your Social Network Today - Download eXo Platform
> > Build your Enterprise Intranet with eXo Platform Software
> > Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> > Get Started Now And Turn Your Intranet Into A Collaboration Platform
> > http://p.sf.net/sfu/ExoPlatform
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
>
>
> ------------------------------------------------------------------------------
> Start Your Social Network Today - Download eXo Platform
> Build your Enterprise Intranet with eXo Platform Software
> Java Based Open Source Intranet - Social, Extensible, Cloud Ready
> Get Started Now And Turn Your Intranet Into A Collaboration Platform
> http://p.sf.net/sfu/ExoPlatform
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
[-- Attachment #2: Type: text/html, Size: 5557 bytes --]
next prev parent reply other threads:[~2014-04-26 10:48 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-25 10:23 [Bitcoin-development] BIP32 "wallet structure" in use? Remove it? Andreas Schildbach
2014-04-25 14:53 ` Jim
2014-04-25 15:46 ` Gregory Maxwell
2014-04-25 15:49 ` Mike Hearn
2014-04-25 21:58 ` Aaron Voisine
2014-04-26 10:36 ` Thomas Voegtlin
2014-04-26 10:48 ` Tier Nolan [this message]
2014-04-26 10:59 ` Tamas Blummer
2014-04-26 11:03 ` Tamas Blummer
2014-04-26 12:24 ` Pavol Rusnak
2014-04-26 13:41 ` Pieter Wuille
2014-04-26 16:03 ` Jeff Garzik
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='CAE-z3OWcZdQ0J3vNYQ7whGHOZZzMh=wYKxCKtrf1i8VSseZArQ@mail.gmail.com' \
--to=tier.nolan@gmail.com \
--cc=bitcoin-development@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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