public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Gregory Maxwell <gmaxwell@gmail•com>
To: devrandom <c1.sf-bitcoin@niftybox•net>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
Date: Thu, 12 Mar 2015 00:11:24 +0000	[thread overview]
Message-ID: <CAAS2fgRVNAPRO5F7yzAv8g-yehgEJ8VoFXapxWmHqnN9-wdq=A@mail.gmail.com> (raw)
In-Reply-To: <5500D4C3.4090207@niftybox.net>

On Wed, Mar 11, 2015 at 11:50 PM, devrandom <c1.sf-bitcoin@niftybox•net> wrote:
> That said, I do agree that mnemonic phrases should be portable, and find
> it unfortunate that the ecosystem is failing to standardize on phrase
> handling.

The fact remains that there are several apparently unresolvable
well-principled perspectives on this subject.

(And I can speak to this personally: There are several BIPs in this
space that I'd rather not see in product with my name on it.)

Unless two wallets have exactly the same feature set, cross importing
keys is going to confuse or break something. Even if you're trying to
be fairly generic the testing overhead for all possible strategies and
structures is large. Expecting compatibility here would be like
expecting two large commercial accounting packages to support the same
internal file formats. Compatibility is only straight forward when the
feature set is as limited as possible.

The space for weird behavior to harm users is pretty large... e.g. you
could load a key into two wallets, such that one can see all the funds
by the other, but not vice versa and and up losing funds by
incorrectly assuming you had no coins; or inadvertently rip of your
business partners by accounting for things incorrectly.

Even ignoring compatibility, most demanded use cases here are ones
that create concurrent read/write use of single wallet without some
coordinating service is inherently somewhat broken because you can
double spend yourself, and end up with stalled and stuck transactions
and causing people to think you tried ripping them off.

I certainly recognize the desirable aspects of just being able to load
a common wallet, and that inexperienced users expect it to just work.
But I don't think that expectation is currently very realistic except
within limited domains. It may be more realistic in the future when
the role of wallets is better established. I don't see any _harm_ in
trying to standardize what can be, I just don't expect to see a lot of
success.

Ultimately, the most fundamental compatibility is guaranteed:  you can
always send your funds to another wallet. This always works and
guarantees that you are never locked in to a single wallet. It is well
tested and cannot drive any software in to weird or confused states.



  parent reply	other threads:[~2015-03-12  0:11 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-01 15:23 Thomas Voegtlin
2015-03-02  7:09 ` Andreas Schildbach
2015-03-02 15:37 ` Mike Hearn
2015-03-02 17:11   ` Jim
2015-03-11 14:58   ` Thomas Voegtlin
2015-03-11 15:31     ` Andreas Schildbach
2015-03-12  8:56       ` Thomas Voegtlin
2015-03-11 17:14     ` Mike Hearn
2015-03-11 19:04       ` Jim
2015-03-11 19:24         ` Ricardo Filipe
2015-03-11 19:46           ` Gregory Maxwell
2015-03-11 22:57             ` Aaron Voisine
2015-03-11 23:22               ` Mike Hearn
2015-03-11 23:50                 ` devrandom
2015-03-11 23:54                   ` Mike Hearn
2015-03-12  0:11                   ` Gregory Maxwell [this message]
2015-03-12  2:41                     ` devrandom
2015-03-12  4:09                       ` Gregory Maxwell
2015-03-12 19:08                         ` Bryan Bishop
2015-03-12 10:30                     ` Andreas Schildbach
2015-03-12 10:28                   ` Andreas Schildbach
2015-03-18  2:06                     ` devrandom
2015-03-12 10:41         ` Andreas Schildbach
2015-03-12  3:43       ` slush
2015-03-12 16:47         ` Mike Hearn
2015-03-12 17:20           ` Gary Rowe
2015-03-12 17:42           ` Gary Rowe
2015-03-12 18:27           ` Natanael
2015-03-12 18:51             ` Andreas Schildbach
2015-03-12 19:14               ` Natanael
     [not found] <1353069350.4360497.1426126034565.JavaMail.yahoo@mail.yahoo.com>
2015-03-12  2:16 ` Thy Shizzle
2015-03-12  3:59   ` Neill Miller
     [not found] <372541993.4372759.1426123313134.JavaMail.yahoo@mail.yahoo.com>
2015-03-12  2:26 ` devrandom
2015-03-12  2:38 Thy Shizzle
2015-03-12 10:43 ` Andreas Schildbach
2015-03-12  4:21 Thy Shizzle
2015-03-12 11:51 ` Neill Miller
2015-03-12 12:59   ` Thy Shizzle
2015-03-12 16:39   ` devrandom
2015-03-12  5:12 Thy Shizzle
2015-03-12  5:25 ` Aaron Voisine
2015-03-12  5:58 Thy Shizzle

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='CAAS2fgRVNAPRO5F7yzAv8g-yehgEJ8VoFXapxWmHqnN9-wdq=A@mail.gmail.com' \
    --to=gmaxwell@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=c1.sf-bitcoin@niftybox$(echo .)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