1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <c1.sf-bitcoin@niftybox.net>) id 1YVt4A-0006ub-0R
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 02:41:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of niftybox.net
designates 95.142.167.147 as permitted sender)
client-ip=95.142.167.147;
envelope-from=c1.sf-bitcoin@niftybox.net; helo=i3.hyper.to;
Received: from i3.hyper.to ([95.142.167.147])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YVt48-0006iL-Gb
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 02:41:41 +0000
Received: from localhost (localhost [127.0.0.1])
by i3.hyper.to (Postfix) with ESMTP id 1F497E0030;
Thu, 12 Mar 2015 03:41:34 +0100 (CET)
Received: from i3.hyper.to ([127.0.0.1])
by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10032)
with ESMTP id EgFni-P4UjBU; Thu, 12 Mar 2015 03:41:33 +0100 (CET)
Received: from localhost (localhost [127.0.0.1])
by i3.hyper.to (Postfix) with ESMTP id 4BD3CE0057;
Thu, 12 Mar 2015 03:41:33 +0100 (CET)
X-Virus-Scanned: amavisd-new at i3.hyper.to
Received: from i3.hyper.to ([127.0.0.1])
by localhost (i3.hyper.to [127.0.0.1]) (amavisd-new, port 10026)
with ESMTP id KkQhfb2LaSdZ; Thu, 12 Mar 2015 03:41:33 +0100 (CET)
Received: from [10.1.10.188] (142-254-47-143.dsl.dynamic.sonic.net
[142.254.47.143])
by i3.hyper.to (Postfix) with ESMTPSA id 2B528E0030;
Thu, 12 Mar 2015 03:41:31 +0100 (CET)
Message-ID: <5500FCDA.8050407@niftybox.net>
Date: Wed, 11 Mar 2015 19:41:30 -0700
From: devrandom <c1.sf-bitcoin@niftybox.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Gregory Maxwell <gmaxwell@gmail.com>
References: <54F32EED.6040103@electrum.org> <CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com> <550057FD.6030402@electrum.org> <CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com> <1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com> <CALC81CPonBX5pGucU9Pu7P7S042c+h8=vNvocX=7f9Yi_kqv5w@mail.gmail.com> <CAAS2fgRuBwn6HXeZeth+x-R8DAdsVZmYy4nMA3kN+oJaURftgw@mail.gmail.com> <CACq0ZD64rZAQs1mWQdwgx1WJq2btAVs3GbegPpkO-Wh49SoGeA@mail.gmail.com> <CANEZrP3ri6QDqomWKMnLqj_ZJxVDOY4QRvWa=L4RzdKFzz+WsQ@mail.gmail.com> <5500D4C3.4090207@niftybox.net>
<CAAS2fgRVNAPRO5F7yzAv8g-yehgEJ8VoFXapxWmHqnN9-wdq=A@mail.gmail.com>
In-Reply-To: <CAAS2fgRVNAPRO5F7yzAv8g-yehgEJ8VoFXapxWmHqnN9-wdq=A@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 AWL AWL: Adjusted score from AWL reputation of From: address
X-Headers-End: 1YVt48-0006iL-Gb
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Electrum 2.0 has been tagged
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 12 Mar 2015 02:41:42 -0000
On 2015-03-11 05:11 PM, Gregory Maxwell wrote:
> 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.
You make some good points. However, I still hope for standardization by
"profile". E.g. a "consumer profile" for wallets with just one account,
a "business profile" for small business wallets. If an application
falls outside of the standardized profiles, they can roll their own or
try to promote a new standard.
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, emergency
transition when a wallet has a serious (e.g. money losing) bug and web
wallet with server down.
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.
>
> 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.
>
--
devrandom / Miron
|
