Re: [Bitcoin-development] Electrum 2.0 has been tagged

[Natanael <natanael.l@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1920 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 2148 bytes --]