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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <jim618@fastmail.co.uk>) id 1YVlvx-00037K-FM
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Mar 2015 19:04:45 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of fastmail.co.uk
designates 66.111.4.26 as permitted sender)
client-ip=66.111.4.26; envelope-from=jim618@fastmail.co.uk;
helo=out2-smtp.messagingengine.com;
Received: from out2-smtp.messagingengine.com ([66.111.4.26])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1YVlvw-0001RZ-8v
for bitcoin-development@lists.sourceforge.net;
Wed, 11 Mar 2015 19:04:45 +0000
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
by mailout.nyi.internal (Postfix) with ESMTP id A70CA2089F
for <bitcoin-development@lists.sourceforge.net>;
Wed, 11 Mar 2015 15:04:36 -0400 (EDT)
Received: from web4 ([10.202.2.214])
by compute1.internal (MEProxy); Wed, 11 Mar 2015 15:04:38 -0400
Received: by web4.nyi.internal (Postfix, from userid 99)
id ADBA0116B14; Wed, 11 Mar 2015 15:04:37 -0400 (EDT)
Message-Id: <1426100677.1908596.239033309.7C4F8D47@webmail.messagingengine.com>
X-Sasl-Enc: TYq3YiucV/SVXp3J7NZG9CyKvufCGoe/QbZKDvseS88+ 1426100677
From: Jim <jim618@fastmail.co.uk>
To: bitcoin-development@lists.sourceforge.net
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain
X-Mailer: MessagingEngine.com Webmail Interface - ajax-07699171
In-Reply-To: <CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
References: <54F32EED.6040103@electrum.org>
<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
<550057FD.6030402@electrum.org>
<CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
Date: Wed, 11 Mar 2015 19:04:37 +0000
X-Spam-Score: -1.4 (-)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(jim618[at]fastmail.co.uk)
-0.0 SPF_PASS SPF: sender matches SPF record
0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in
digit (jim618[at]fastmail.co.uk)
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YVlvw-0001RZ-8v
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: Wed, 11 Mar 2015 19:04:45 -0000
The wallet words system isn't perfect for sure but it does help the user in two main ways:
1) Assuming wallet devs ensure forward compatibility for _their_ wallet the user knows they can recover their bitcoins using the same wallet software in case of a Bad Thing Happening.
2) To an imperfect degree, they can transfer/ recover their bitcoins that are stored in Wallet X into Wallet Y. We need to give them guidance on how to do this.
I think it is up to each wallet team to explain to their users clearly how they can do this in their help. It's only good manners to show your guests where the fire exits are.
It can be a simple help page saying:
"If you want to transfer your bitcoin out of MultiBit HD to Lighthouse, do this, this and this.
If you want to use the Trezor wallet you created in MultiBit HD on myTrezor.com, do this, this and this."
That way users have clear instructions on how to recover their bitcoins.
Users don't care about BIP this or BIP that but they REALLY DO CARE about keeping their bitcoins.
--
http://bitcoin-solutions.co.uk
On Wed, Mar 11, 2015, at 05:14 PM, Mike Hearn wrote:
> Sigh. The wallet words system is turning into kind of a mess.
>
> I thought the word list is in fact not a fixed part of the spec, because
> the entropy is a hash of the words. But perhaps I'm misunderstanding
> something.
>
> The main problem regular SPV wallets have with BIP39 is that there is no
> birth time included in the data. Therefore we must ask users to write down
> a timestamp as well, so we know where to start rescanning the chain. It
> sounds like the Electrum version doesn't fix this, so now we have at least
> FIVE incompatible results from a 12 word list:
>
> - Electrum v2 with a version number but no date
> - myTREZOR with no version and no date and BIP44 key derivation. Some
> seeds I believe are now being generated with 24 words instead of 12.
> - MultiBit HD with no version and a date in a custom form that creates
> non-date-like codes you are expected to write down. I think BIP32 and BIP44
> are both supported (sorta).
> - GreenAddress with no version, no date and BIP32
> - Other bitcoinj based wallets, with no version and a date written down
> in normal human form, BIP32 only.
>
> I really hope we can recover from this somehow because otherwise all
> wallets will have to provide the user with a complicated matrix of
> possibilities and software combinations, and in practice many won't bother
> so these word combinations will actually end up being wallet specific for
> no particularly good reason, just very minor details like the presence or
> absence of single fields.
>
> It feels like we somehow fell flat on our faces just before the finishing
> line. This is deeply unfortunate. Compatibility and UX consistency is
> important!
>
> Currently, I don't have any bright ideas for how to get everyone back onto
> the same page with a fully compatible system that is acceptable to all. If
> anyone else has suggestions, I'm all ears.
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
|
