From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <54F32EED.6040103@electrum.org> <550057FD.6030402@electrum.org> Date: Thu, 12 Mar 2015 20:14:34 +0100 Message-ID: From: Natanael To: Andreas Schildbach 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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" : > > 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


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 impo= rt
> 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 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.

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.

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).

--f46d043c0904bf892605111c31d6--