POLL - Importing Private Keys in Satoshi Client.

SgtSpike

legendary

Activity: 1400

Merit: 1005

Quote from: pointbiz on December 26, 2012, 02:17:07 PM

I think a GUI for importing private keys is seriously needed in bitcoin-qt. The use cases where people have a private key in their hands that they want to import just keep growing.

It is frustrating how simple things like import/export keys which would allow people to actually use Bitcoins takes forever to be implemented/included in the mainline. I agree with the direction of the core devs (re network protocol/security/stability) but one person needs to sidebar on this usability issue.

After we have that then the more complex work for a sweep RPC and GUI should be implemented.

+ a thousand.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: BkkCoins on December 06, 2012, 07:15:50 PM

A client/server UI makes a huge amount of sense. Then core devs can focus on the backend and others can create various interfaces including POS interfaces, or protocol interface layers etc.

This would also allow for a much simpler Electrum server install. I believe if bitcoind had an "address history" rpc call then it would be enough to support Electrum server as a thin layer over top and not need a full MySql/Abe/patched install.

If the Electrum server would only need to be a thin layer after some additional rpc calls are added, why not just move that functionality into bitcoind itself?

pointbiz

sr. member

Activity: 437

Merit: 415

1ninja

I think a GUI for importing private keys is seriously needed in bitcoin-qt. The use cases where people have a private key in their hands that they want to import just keep growing.

It is frustrating how simple things like import/export keys which would allow people to actually use Bitcoins takes forever to be implemented/included in the mainline. I agree with the direction of the core devs (re network protocol/security/stability) but one person needs to sidebar on this usability issue.

After we have that then the more complex work for a sweep RPC and GUI should be implemented.

nibor

sr. member

Activity: 438

Merit: 291

Just bumping to get up to 100 votes!
Thanks

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

Quote from: casascius on December 06, 2012, 02:34:02 PM

Quote from: justusranvier on December 06, 2012, 02:29:23 PM

I think the ideal solution would increase the modularity of the reference code by completely splitting the functionality bitcoind and Bitcoin-Qt. Bitcoin-Qt should be a UI and wallet manager only, with no blockchain or network managing functions and bitcoind should remove the corresponding UI features. Bitcoind should be able to serve alternate UI clients, like Armory or a theoretical bitcoin-curses, directly.

+1 - I was literally about to say just this, but then I saw "Warning - while you were reading a new reply has been posted. You may wish to review your post" and what I wanted to say, right before my eyes.

Bitcoind needs to provide many of the services that for example BlockChain.info provides, such as the unspent outputs of arbitrary addresses.

Each instance of Bitcoind needs to allow a client to subscribe to its view of the network in the form of a "sequential events" subscription. Everything that a Bitcoind node perceives (such as an incoming block, or a confirmed transaction, or blocks became orphan and/or transactions became unconfirmed) needs to be given a log serial number, and a client should be able to connect and ask "Tell me everything that has happened since LSN 1234567".

Bitcoind should have RPC calls to serve bitcoin knowledge over the network (obviously it does, and I feel there should be more, and can articulate). I would love to just run MY OWN bitcoind on my own network, so I have one bitcoind node I trust, and then point as many instances of Armory at it as I wanted, over the network, as though Armory were a thin UI for it.

A client/server UI makes a huge amount of sense. Then core devs can focus on the backend and others can create various interfaces including POS interfaces, or protocol interface layers etc.

This would also allow for a much simpler Electrum server install. I believe if bitcoind had an "address history" rpc call then it would be enough to support Electrum server as a thin layer over top and not need a full MySql/Abe/patched install. I was looking thru this yesterday wondering if I could create an "address history" call.

Right now, due to insufficient rpc calls, it's a fairly major bit of setup to run an Electrum server but instead with a small protocol layer it could be very easy for any bitcoind to also be an Electrum server.

edit: I didn't know it, but this is already taken care of in 0.8.0 pre-release and with the new SPV Electrum server install it's already this easy.

justusranvier

legendary

Activity: 1400

Merit: 1013

In the case of my home lan I have a file server optimized for IO performance, and I have my main desktop which is optimized for CPU and graphics performance. I want to be able to maintain only one copy of the blockchain, on the computer that makes sense to store it on, and run my client applications on the desktop machine. Right now I run bitcoind on the file server, and also run Bitcoin-Qt and Armory on the desktop. Right now on the desktop machine I store its copy of the blockchain on a raid-0 in order to get acceptable performance, but sooner or later one of those drives is going to fail and I'll have to restore everything from backups.

casascius

vip

Activity: 1386

Merit: 1140

The Casascius 1oz 10BTC Silver Round (w/ Gold B)

Quote from: justusranvier on December 06, 2012, 02:29:23 PM

I think the ideal solution would increase the modularity of the reference code by completely splitting the functionality bitcoind and Bitcoin-Qt. Bitcoin-Qt should be a UI and wallet manager only, with no blockchain or network managing functions and bitcoind should remove the corresponding UI features. Bitcoind should be able to serve alternate UI clients, like Armory or a theoretical bitcoin-curses, directly.

+1 - I was literally about to say just this, but then I saw "Warning - while you were reading a new reply has been posted. You may wish to review your post" and what I wanted to say, right before my eyes.

Bitcoind needs to provide many of the services that for example BlockChain.info provides, such as the unspent outputs of arbitrary addresses.

Each instance of Bitcoind needs to allow a client to subscribe to its view of the network in the form of a "sequential events" subscription. Everything that a Bitcoind node perceives (such as an incoming block, or a confirmed transaction, or blocks became orphan and/or transactions became unconfirmed) needs to be given a log serial number, and a client should be able to connect and ask "Tell me everything that has happened since LSN 1234567".

Bitcoind should have RPC calls to serve bitcoin knowledge over the network (obviously it does, and I feel there should be more, and can articulate). I would love to just run MY OWN bitcoind on my own network, so I have one bitcoind node I trust, and then point as many instances of Armory at it as I wanted, over the network, as though Armory were a thin UI for it.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: etotheipi on December 06, 2012, 01:43:58 PM

It's funny you bring that up, because there has been an extended conversation over the past few days on the mailing list, about exactly that. There's some debate about the qualities of an acceptable to solution to promote as the default, and right now Bitcoin-Qt being the only "usable" full node implementation wins because we need full-nodes and that's the safest for the network. But I do agree with you -- there should be a better experience for new users -- and maybe that discussion will yield something like: "Multibit should be default if it implements X, Y and Z and gets some more support behind it".

I think the ideal solution would increase the modularity of the reference code by completely splitting the functionality bitcoind and Bitcoin-Qt. Bitcoin-Qt should be a UI and wallet manager only, with no blockchain or network managing functions and bitcoind should remove the corresponding UI features. Bitcoind should be able to serve alternate UI clients, like Armory or a theoretical bitcoin-curses, directly.

SgtSpike

legendary

Activity: 1400

Merit: 1005

Quote from: etotheipi on December 06, 2012, 01:43:58 PM

Quote from: SgtSpike on December 06, 2012, 01:31:55 PM

Quote from: etotheipi on December 06, 2012, 01:22:42 PM

Quote from: SgtSpike on December 06, 2012, 01:11:49 PM

Quote from: BkkCoins on December 06, 2012, 02:30:24 AM

I find it odd that blockchain.info is reputed to be one of the easy clients and yet it has "Import Private Key" functionality, and Bitcoin-Qt is reputed to be the hard-to-use one and yet it doesn't have several features blockchain.info does. Have people complained that advanced features get in the way of simplicity with blockchain.info? If not, then what's the problem with bringing some more advanced features into Bitcoin-Qt?

I like the idea of plugins. ImportPrivKey could start out as a plugin included but disabled by default. Similar to how Deluge or other apps ship initially with some plugins included but not enabled.

It's because blockchain.info is one of the few Bitcoin servicers that actually understand what a quality user experience is about. The Bitcoin-QT devs just really do not. Nothing against them, I appreciate what they do, but that's just the reality of the situation. They are not listening to what users want, and instead give reasons why they know what is better for the user than the users themselves.

I think the bitcoin-qt devs have decided that security and stability is more important than "luxury" features like this, that are supported by a variety of other programs anyway (and supported by itself, through the RPC interface). They'd rather spend the time dealing with network security to maximize the chance that the network survives an attack, or devastating bugs. I've heard some of the devs suggest that Bitcoin-Qt could become more of a back-end for other programs to leverage, rather than focusing on recreating what those other programs do.

Sure, they are the face of Bitcoin at the moment, and they want to supply a better feature set for its users where possible. But they have an important job to do under-the-hood that us alt-client developers can't do -- improve the network protocol and security. But that's why they added an "Alternative clients" section to the main page, to make people aware that they aren't the only thing in town.

Ok, I understand them coming from that perspective. But if that is the case, they should NOT be the default download on bitcoin.org, where newbies generally find clients. We want people new to Bitcoin to have a user-friendly experience, not an unfriendly barebones client that won't even allow them to export their private keys if they stick around long enough to find out that better clients exist.

The Bitcoin Foundation really needs to vote on a user-friendly alternative client to be displayed as the default download option on the bitcoin.org homepage. I see so many complaints from new users about trying to figure out how to use the QT client, and I can only imagine how many others are being turned away from Bitcoin without saying anything just because it's not easy to use. If the QT client isn't going to be dedicated to improving its feature set and usability, then we need a different client to take its place as the user-friendly version to point new users to.

It's funny you bring that up, because there has been an extended conversation over the past few days on the mailing list, about exactly that. There's some debate about the qualities of an acceptable to solution to promote as the default, and right now Bitcoin-Qt being the only "usable" full node implementation wins because we need full-nodes and that's the safest for the network. But I do agree with you -- there should be a better experience for new users -- and maybe that discussion will yield something like: "Multibit should be default if it implements X, Y and Z and gets some more support behind it".

But that's not the topic of this thread. I do think that a plugin system for Bitcoin-Qt is a good idea, and I've thought about something similar for Armory. Certainly, allowing plugins give more flexibility for non-core-devs to contribute, but at the risk of safety (rogue plugins can be a major security risk).

Glad to hear it is under discussion, that does make me feel better. And yes, I agree, I tried to think of a better client to put in place, but non fit the bill at the moment.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: SgtSpike on December 06, 2012, 01:31:55 PM

Quote from: etotheipi on December 06, 2012, 01:22:42 PM

Quote from: SgtSpike on December 06, 2012, 01:11:49 PM

Quote from: BkkCoins on December 06, 2012, 02:30:24 AM

I find it odd that blockchain.info is reputed to be one of the easy clients and yet it has "Import Private Key" functionality, and Bitcoin-Qt is reputed to be the hard-to-use one and yet it doesn't have several features blockchain.info does. Have people complained that advanced features get in the way of simplicity with blockchain.info? If not, then what's the problem with bringing some more advanced features into Bitcoin-Qt?

I like the idea of plugins. ImportPrivKey could start out as a plugin included but disabled by default. Similar to how Deluge or other apps ship initially with some plugins included but not enabled.

It's because blockchain.info is one of the few Bitcoin servicers that actually understand what a quality user experience is about. The Bitcoin-QT devs just really do not. Nothing against them, I appreciate what they do, but that's just the reality of the situation. They are not listening to what users want, and instead give reasons why they know what is better for the user than the users themselves.

I think the bitcoin-qt devs have decided that security and stability is more important than "luxury" features like this, that are supported by a variety of other programs anyway (and supported by itself, through the RPC interface). They'd rather spend the time dealing with network security to maximize the chance that the network survives an attack, or devastating bugs. I've heard some of the devs suggest that Bitcoin-Qt could become more of a back-end for other programs to leverage, rather than focusing on recreating what those other programs do.

Sure, they are the face of Bitcoin at the moment, and they want to supply a better feature set for its users where possible. But they have an important job to do under-the-hood that us alt-client developers can't do -- improve the network protocol and security. But that's why they added an "Alternative clients" section to the main page, to make people aware that they aren't the only thing in town.

Ok, I understand them coming from that perspective. But if that is the case, they should NOT be the default download on bitcoin.org, where newbies generally find clients. We want people new to Bitcoin to have a user-friendly experience, not an unfriendly barebones client that won't even allow them to export their private keys if they stick around long enough to find out that better clients exist.

The Bitcoin Foundation really needs to vote on a user-friendly alternative client to be displayed as the default download option on the bitcoin.org homepage. I see so many complaints from new users about trying to figure out how to use the QT client, and I can only imagine how many others are being turned away from Bitcoin without saying anything just because it's not easy to use. If the QT client isn't going to be dedicated to improving its feature set and usability, then we need a different client to take its place as the user-friendly version to point new users to.

It's funny you bring that up, because there has been an extended conversation over the past few days on the mailing list, about exactly that. There's some debate about the qualities of an acceptable to solution to promote as the default, and right now Bitcoin-Qt being the only "usable" full node implementation wins because we need full-nodes and that's the safest for the network. But I do agree with you -- there should be a better experience for new users -- and maybe that discussion will yield something like: "Multibit should be default if it implements X, Y and Z and gets some more support behind it".

But that's not the topic of this thread. I do think that a plugin system for Bitcoin-Qt is a good idea, and I've thought about something similar for Armory. Certainly, allowing plugins give more flexibility for non-core-devs to contribute, but at the risk of safety (rogue plugins can be a major security risk).

SgtSpike

legendary

Activity: 1400

Merit: 1005

Quote from: etotheipi on December 06, 2012, 01:22:42 PM

Quote from: SgtSpike on December 06, 2012, 01:11:49 PM

Quote from: BkkCoins on December 06, 2012, 02:30:24 AM

I find it odd that blockchain.info is reputed to be one of the easy clients and yet it has "Import Private Key" functionality, and Bitcoin-Qt is reputed to be the hard-to-use one and yet it doesn't have several features blockchain.info does. Have people complained that advanced features get in the way of simplicity with blockchain.info? If not, then what's the problem with bringing some more advanced features into Bitcoin-Qt?

I like the idea of plugins. ImportPrivKey could start out as a plugin included but disabled by default. Similar to how Deluge or other apps ship initially with some plugins included but not enabled.

It's because blockchain.info is one of the few Bitcoin servicers that actually understand what a quality user experience is about. The Bitcoin-QT devs just really do not. Nothing against them, I appreciate what they do, but that's just the reality of the situation. They are not listening to what users want, and instead give reasons why they know what is better for the user than the users themselves.

I think the bitcoin-qt devs have decided that security and stability is more important than "luxury" features like this, that are supported by a variety of other programs anyway (and supported by itself, through the RPC interface). They'd rather spend the time dealing with network security to maximize the chance that the network survives an attack, or devastating bugs. I've heard some of the devs suggest that Bitcoin-Qt could become more of a back-end for other programs to leverage, rather than focusing on recreating what those other programs do.

Sure, they are the face of Bitcoin at the moment, and they want to supply a better feature set for its users where possible. But they have an important job to do under-the-hood that us alt-client developers can't do -- improve the network protocol and security. But that's why they added an "Alternative clients" section to the main page, to make people aware that they aren't the only thing in town.

Ok, I understand them coming from that perspective. But if that is the case, they should NOT be the default download on bitcoin.org, where newbies generally find clients. We want people new to Bitcoin to have a user-friendly experience, not an unfriendly barebones client that won't even allow them to export their private keys if they stick around long enough to find out that better clients exist.

The Bitcoin Foundation really needs to vote on a user-friendly alternative client to be displayed as the default download option on the bitcoin.org homepage. I see so many complaints from new users about trying to figure out how to use the QT client, and I can only imagine how many others are being turned away from Bitcoin without saying anything just because it's not easy to use. If the QT client isn't going to be dedicated to improving its feature set and usability, then we need a different client to take its place as the user-friendly version to point new users to.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: SgtSpike on December 06, 2012, 01:11:49 PM

Quote from: BkkCoins on December 06, 2012, 02:30:24 AM

I find it odd that blockchain.info is reputed to be one of the easy clients and yet it has "Import Private Key" functionality, and Bitcoin-Qt is reputed to be the hard-to-use one and yet it doesn't have several features blockchain.info does. Have people complained that advanced features get in the way of simplicity with blockchain.info? If not, then what's the problem with bringing some more advanced features into Bitcoin-Qt?

I like the idea of plugins. ImportPrivKey could start out as a plugin included but disabled by default. Similar to how Deluge or other apps ship initially with some plugins included but not enabled.

It's because blockchain.info is one of the few Bitcoin servicers that actually understand what a quality user experience is about. The Bitcoin-QT devs just really do not. Nothing against them, I appreciate what they do, but that's just the reality of the situation. They are not listening to what users want, and instead give reasons why they know what is better for the user than the users themselves.

I think the bitcoin-qt devs have decided that security and stability is more important than "luxury" features like this, that are supported by a variety of other programs anyway (and supported by itself, through the RPC interface). They'd rather spend the time dealing with network security to maximize the chance that the network survives an attack, or devastating bugs. I've heard some of the devs suggest that Bitcoin-Qt could become more of a back-end for other programs to leverage, rather than focusing on recreating what those other programs do.

Sure, they are the face of Bitcoin at the moment, and they want to supply a better feature set for its users where possible. But they have an important job to do under-the-hood that us alt-client developers can't do -- improve the network protocol and security. But that's why they added an "Alternative clients" section to the main page, to make people aware that they aren't the only thing in town.

Yuhfhrh

full member

Activity: 238

Merit: 100

Quote from: ShadowOfHarbringer on December 06, 2012, 06:58:57 AM

Quote from: cbeast on December 05, 2012, 11:10:33 AM

Quote from: proudhon on December 05, 2012, 09:34:11 AM

Quote from: casascius on December 05, 2012, 09:24:37 AM

I think import private key should not be exposed to average users. Sweep private key should be offered instead.
Users are apt to believe that once they import a private key they have ownership of the funds. But someone else who has the private key can still swipe them, a rude awakening. Offering sweep solves this.

+1

+1 Yes, please.

+1

Quote from: JackH on December 05, 2012, 10:55:07 AM

Quote from: Yuhfhrh on December 05, 2012, 04:04:24 AM

Quote from: Meni Rosenfeld on December 05, 2012, 03:17:38 AM

How about an "Advanced" menu which needs to be unlocked with a big warning sign in which such features can be added?

This. Please.

This too

+1

You would like both options very much, yes.

Me too.

SgtSpike

legendary

Activity: 1400

Merit: 1005

Quote from: BkkCoins on December 06, 2012, 02:30:24 AM

I find it odd that blockchain.info is reputed to be one of the easy clients and yet it has "Import Private Key" functionality, and Bitcoin-Qt is reputed to be the hard-to-use one and yet it doesn't have several features blockchain.info does. Have people complained that advanced features get in the way of simplicity with blockchain.info? If not, then what's the problem with bringing some more advanced features into Bitcoin-Qt?

I like the idea of plugins. ImportPrivKey could start out as a plugin included but disabled by default. Similar to how Deluge or other apps ship initially with some plugins included but not enabled.

It's because blockchain.info is one of the few Bitcoin servicers that actually understand what a quality user experience is about. The Bitcoin-QT devs just really do not. Nothing against them, I appreciate what they do, but that's just the reality of the situation. They are not listening to what users want, and instead give reasons why they know what is better for the user than the users themselves.

ShadowOfHarbringer

legendary

Activity: 1470

Merit: 1006

Bringing Legendary Har® to you since 1952

Quote from: cbeast on December 05, 2012, 11:10:33 AM

Quote from: proudhon on December 05, 2012, 09:34:11 AM

Quote from: casascius on December 05, 2012, 09:24:37 AM

I think import private key should not be exposed to average users. Sweep private key should be offered instead.
Users are apt to believe that once they import a private key they have ownership of the funds. But someone else who has the private key can still swipe them, a rude awakening. Offering sweep solves this.

+1

+1 Yes, please.

+1

Quote from: JackH on December 05, 2012, 10:55:07 AM

Quote from: Yuhfhrh on December 05, 2012, 04:04:24 AM

Quote from: Meni Rosenfeld on December 05, 2012, 03:17:38 AM

How about an "Advanced" menu which needs to be unlocked with a big warning sign in which such features can be added?

This. Please.

This too

+1

You would like both options very much, yes.

justusranvier

legendary

Activity: 1400

Merit: 1013

Quote from: etotheipi on December 06, 2012, 01:18:55 AM

It's a feature, not a bug... Armory inherits all the security properties of Bitcoin-Qt by using it as a gateway to the Bitcoin network. If I rewrote all that stuff myself, it'd probably be a disaster. And in the end, since you don't ever need to touch Bitcoin-Qt, you can just minimize it and pretend it isn't there. Armory is a bit slow to start, but the recent beta release includes insta-load so you can manage your wallets (like importing keys) while it is scanning the blockchain.

Do you ever plan to make it possible to use bitcoind (possibly running on a different machine) instead of Bitcoin-Qt?

BkkCoins

hero member

Activity: 784

Merit: 1009

firstbits:1MinerQ

I find it odd that blockchain.info is reputed to be one of the easy clients and yet it has "Import Private Key" functionality, and Bitcoin-Qt is reputed to be the hard-to-use one and yet it doesn't have several features blockchain.info does. Have people complained that advanced features get in the way of simplicity with blockchain.info? If not, then what's the problem with bringing some more advanced features into Bitcoin-Qt?

I like the idea of plugins. ImportPrivKey could start out as a plugin included but disabled by default. Similar to how Deluge or other apps ship initially with some plugins included but not enabled.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: SgtSpike on December 06, 2012, 01:21:15 AM

We're getting a bit sidetracked here, but if I import a key via Armory, is it then available in QT?

This is mostly relevant: if users care this much about importing/sweeping keys, they should know that there are clients that support it -- and Armory makes it damned easy. The downsides of Armory are also relevant, for those who are intrigued by this posting that haven't used Armory before. Obviously, the discussion still needs to be had whether/how importing makes it into Bitcoin-Qt -- but I think it's appropriate for context to mention that there are alternatives.

The key will not be available in Bitcoin-Qt. Using Armory is using a new wallet with a new interface, and is unrelated to your Bitcoin-Qt wallet. You likely won't use your Bitcoin-Qt wallet again. Not everyone wants to make the jump, but few users that do want to go back (especially users advanced enough to be importing keys). Bitcoin-Qt functionality is almost strictly a subset of Armory's functionality. It gives GUI users a ton more stuff (though, Armory doesn't do much for bitcoind users). I can't imagine ever going back to a wallet that requires multiple backups at risk of losing coins...

SgtSpike

legendary

Activity: 1400

Merit: 1005

Quote from: etotheipi on December 06, 2012, 01:18:55 AM

Quote from: SgtSpike on December 06, 2012, 01:15:48 AM

Quote from: etotheipi on December 06, 2012, 01:11:10 AM

If you're willing to go as far as creating plugins for Bitcoin-Qt to do this, you might as well just use Armory. It basically is an add-on, and both importing and sweeping are supported. Only sweeping is supported if you are in "Standard" usermode, with importing being available in "Advanced" and "Expert" (for reasons already described here). It also has batch-importing/sweeping so you don't have to wait for a rescan between each one. Not to mention all the other nice benefits of Armory: printable one-time-only-needed backups, multi-wallet interface, simple cold storage with watching-only wallets...

I just wish it didn't require running both clients at the same time. I suppose it's the same difference, but I don't like waiting for two large softwares to load up instead of just one. Tongue

I do agree that Armory is a much superior client to QT for a variety of reasons though.

It's a feature, not a bug... Armory inherits all the security properties of Bitcoin-Qt by using it as a gateway to the Bitcoin network. If I rewrote all that stuff myself, it'd probably be a disaster. And in the end, since you don't ever need to touch Bitcoin-Qt, you can just minimize it and pretend it isn't there. Armory is a bit slow to start, but the recent beta release includes insta-load so you can manage your wallets (like importing keys) while it is scanning the blockchain.

We're getting a bit sidetracked here, but if I import a key via Armory, is it then available in QT?

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: SgtSpike on December 06, 2012, 01:15:48 AM

Quote from: etotheipi on December 06, 2012, 01:11:10 AM

If you're willing to go as far as creating plugins for Bitcoin-Qt to do this, you might as well just use Armory. It basically is an add-on, and both importing and sweeping are supported. Only sweeping is supported if you are in "Standard" usermode, with importing being available in "Advanced" and "Expert" (for reasons already described here). It also has batch-importing/sweeping so you don't have to wait for a rescan between each one. Not to mention all the other nice benefits of Armory: printable one-time-only-needed backups, multi-wallet interface, simple cold storage with watching-only wallets...

I just wish it didn't require running both clients at the same time. I suppose it's the same difference, but I don't like waiting for two large softwares to load up instead of just one. Tongue

I do agree that Armory is a much superior client to QT for a variety of reasons though.

It's a feature, not a bug... Armory inherits all the security properties of Bitcoin-Qt by using it as a gateway to the Bitcoin network. If I rewrote all that stuff myself, it'd probably be a disaster. And in the end, since you don't ever need to touch Bitcoin-Qt, you can just minimize it and pretend it isn't there. Armory is a bit slow to start, but the recent beta release includes insta-load so you can manage your wallets (like importing keys) while it is scanning the blockchain.

Topic: POLL - Importing Private Keys in Satoshi Client. (Read 4615 times)