POLL - Importing Private Keys in Satoshi Client.

[ShadowOfHarbringer]

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

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.

[SgtSpike]

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.

[Yuhfhrh]

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

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. 

[etotheipi]

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.

[SgtSpike]

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]

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]

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.

[justusranvier]

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.

[casascius]

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]

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.

[BkkCoins]

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.

[nibor]

Just bumping to get up to 100 votes!
Thanks

[pointbiz]

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.

[justusranvier]

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?

[SgtSpike]

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.