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
138
139
140
141
142
143
144
145
146
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1YW8Z9-00061o-9p
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 19:14:43 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.212.177 as permitted sender)
client-ip=209.85.212.177; envelope-from=natanael.l@gmail.com;
helo=mail-wi0-f177.google.com;
Received: from mail-wi0-f177.google.com ([209.85.212.177])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YW8Z6-0000UT-UO
for bitcoin-development@lists.sourceforge.net;
Thu, 12 Mar 2015 19:14:43 +0000
Received: by widem10 with SMTP id em10so354435wid.2
for <bitcoin-development@lists.sourceforge.net>;
Thu, 12 Mar 2015 12:14:35 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.181.11.202 with SMTP id ek10mr54189390wid.37.1426187674943;
Thu, 12 Mar 2015 12:14:34 -0700 (PDT)
Received: by 10.194.28.170 with HTTP; Thu, 12 Mar 2015 12:14:34 -0700 (PDT)
Received: by 10.194.28.170 with HTTP; Thu, 12 Mar 2015 12:14:34 -0700 (PDT)
In-Reply-To: <mdsn73$qpn$1@ger.gmane.org>
References: <54F32EED.6040103@electrum.org>
<CANEZrP23buJF0ENfrKGRuzpQ3Uod09s-kRcb3CBw1-OmUxEyZg@mail.gmail.com>
<550057FD.6030402@electrum.org>
<CANEZrP2UrRYG2wh3DHHj9B3Sp1X=n+gPCRcoj1Fouu4Lg157UA@mail.gmail.com>
<CAJna-HhHkmOTqNW2R6=Cih+tM_Eeu5o1LBxA4ZNzp-6vm1p6fg@mail.gmail.com>
<CANEZrP2AhCfks7Q+16PHGB0ZEeWwbdbbQM_xj3ebrkgDBgbosg@mail.gmail.com>
<CAAt2M1_zVXnp_EjtZHiP9wSq+cERgibZ_C992zZHtv+Lpmgsfw@mail.gmail.com>
<mdsn73$qpn$1@ger.gmane.org>
Date: Thu, 12 Mar 2015 20:14:34 +0100
Message-ID: <CAAt2M1_ZTaC0uUT20w_OTOBFL8QUVGkpdqnb9GX8NnX3f1rNLw@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Andreas Schildbach <andreas@schildbach.de>
Content-Type: multipart/alternative; boundary=f46d043c0904bf892605111c31d6
X-Spam-Score: -0.6 (/)
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
(natanael.l[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1YW8Z6-0000UT-UO
Cc: 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 19:14:43 -0000
--f46d043c0904bf892605111c31d6
Content-Type: text/plain; charset=UTF-8
Den 12 mar 2015 19:52 skrev "Andreas Schildbach" <andreas@schildbach.de>:
>
> I'm afraid this will never fly. Wallets are just too different and
> that's a good thing! For example, by design choice Bitcoin Wallet and
> bitcoinj doesn't support multiple accounts. How would it ever import
> wallets from MultiBit or Mycelium?
I think I covered that with the "importing wallet says what sections it
supports" part. Then you'd only ask for the library to give you the
addresses from the first branch in the main HD wallet. The user would be
told that you by design can't manage the other parts. The user would be
alerted and get the recommendation to send the funds over manually if they
want to switch their wallet. The user might however just want to export
that one single branch if he's a "power user", so he would proceed to use
it that way.
At export, I recommend the wallet will tell the user what extensions and
standards are in use (and which are necessary to recover how much of their
funds in the target wallet). The user would be asked to confirm that the
target wallet client supports these. The user should be given the option to
hand the list of supported functionality in the target wallet (like a list
of BIP numbers?), and tell the wallet to move the funds around so that the
target wallet can successfully import everything and recover all funds.
Actually, thinking about it I think what we really need first is a standard
synchronization / transition protocol. Right now we don't have more than
the address label syncing plugin for Electrum. We need something for
wallets to synchronize state, with the option for having one wallet tell
the other how to send over all funds (for when they use completely
different standards for managing funds). As the most simple option, the
target wallet would provide a list of addresses to the sending wallet when
you switch (this would satisfy Bryan's request).
--f46d043c0904bf892605111c31d6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr"><br>
Den 12 mar 2015 19:52 skrev "Andreas Schildbach" <<a href=3D"m=
ailto:andreas@schildbach.de">andreas@schildbach.de</a>>:<br>
><br>
> I'm afraid this will never fly. Wallets are just too different and=
<br>
> that's a good thing! For example, by design choice Bitcoin Wallet =
and<br>
> bitcoinj doesn't support multiple accounts. How would it ever impo=
rt<br>
> wallets from MultiBit or Mycelium?</p>
<p dir=3D"ltr">I think I covered that with the "importing wallet says =
what sections it supports" part. Then you'd only ask for the libra=
ry to give you the addresses from the first branch in the main HD wallet. T=
he user would be told that you by design can't manage the other parts. =
The user would be alerted and get the recommendation to send the funds over=
manually if they want to switch their wallet. The user might however just =
want to export that one single branch if he's a "power user",=
so he would proceed to use it that way.</p>
<p dir=3D"ltr">At export, I recommend the wallet will tell the user what ex=
tensions and standards are in use (and which are necessary to recover how m=
uch of their funds in the target wallet). The user would be asked to confir=
m that the target wallet client supports these. The user should be given th=
e option to hand the list of supported functionality in the target wallet (=
like a list of BIP numbers?), and tell the wallet to move the funds around =
so that the target wallet can successfully import everything and recover al=
l funds. </p>
<p dir=3D"ltr">Actually, thinking about it I think what we really need firs=
t is a standard synchronization / transition protocol. Right now we don'=
;t have more than the address label syncing plugin for Electrum. We need so=
mething for wallets to synchronize state, with the option for having one wa=
llet tell the other how to send over all funds (for when they use completel=
y different standards for managing funds). As the most simple option, the t=
arget wallet would provide a list of addresses to the sending wallet when y=
ou switch (this would satisfy Bryan's request). </p>
--f46d043c0904bf892605111c31d6--
|
