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 04:09:44 +0000 [thread overview]
Message-ID: <CAAS2fgSesKYwn1B=o1uxXG7hkGKF8f5e0jZ1eRWQpMSkMBp1EA@mail.gmail.com> (raw)
In-Reply-To: <5500FCDA.8050407@niftybox.net>
On Thu, Mar 12, 2015 at 2:41 AM, devrandom <c1.sf-bitcoin@niftybox•net> wrote:
> I think there are some important advantages to not being forced to use
> the old wallet to send coins when switching wallets. The three I can
> think of right now are: maintaining transaction history,
Just loading a key doesn't keep transaction history however, if the
loading wallet can't understand or infer metadata about the
transactions. You get some mass of data but to tell actually what the
transactions are, or what they were for, forensic accounting is
required and some data will be potentially unrecoverable.
The best way to preserve historical information is to use reporting
from the wallet in question; which will accurately record the best
available output for this. (E.g. Bitcoin-qt has a CSV export or you
can take a json list-transactions out of it).
> emergency transition when a wallet has a serious (e.g. money losing) bug
This cuts both ways, we've seen significant losses for users in
Bitcoin Core where they've used the console to import keys that they
also used in other insecure clients.
For an emergency transition the user is probably better off with an
explicit unstructured mass private key export, and a sweep function;
and guaranteeing compatibility with that is much easier; and because
it moves funds in one direction there is much less chance of going
from secure to insecure.
> and web
> wallet with server down.
I suppose it would be too much to ask that these web wallets actually
not be totally centrally controlled and have the potential of just
having someone else stand up a server. I guess not. :(
Emergencies being what the are you do with what you can... indeed, I
agree thats a reason that better compatibility is better. (But perhaps
best is that its insane to use software to handle your money that can
just be taken away from you like that...)
> Another important reason to standardize is to reduce the "roll your own
> crypto" temptation on the wallet creator part, where the wallet-specific
> algorithm is more likely to contain weaknesses.
> I do agree that trying to come up with one uber standard will likely
> fail and is probably counter productive.
Careful with this line of thinking: We have no mechanism in the BIP
process to exclude weak cryptography.
A BIP is not a measure of cryptographic integrity. There are existing
BIPs which I consider flawed and would not use or recommend.
It result in some level of review, maybe, and so it can be productive
to at least have more eyes on fewer things; which is a reason I
wouldn't say don't bother trying.
And indeed, I do think that what can be standardized should be, my
words weren't intended to dismiss anyone's efforts, only to encourage
realistic (I think) expectations around what will come of it.
And while I hope for no gratuitous incompatibility, I also hope that
no one working on a wallet hesitates for a minute to offer a new and
interesting functionality just because it doesn't fit into a prefab
shape.
next prev parent reply other threads:[~2015-03-12 4:09 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
2015-03-12 2:41 ` devrandom
2015-03-12 4:09 ` Gregory Maxwell [this message]
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='CAAS2fgSesKYwn1B=o1uxXG7hkGKF8f5e0jZ1eRWQpMSkMBp1EA@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