Bitcoin Forum

You can currently do this but is a bit manual:
https://en.bitcoin.it/wiki/How_to_import_private_keys_v7%2B

I have developed and posted a pull request for this to the developers:
https://github.com/bitcoin/bitcoin/pull/2050

However they have concluded that users need protecting from themselves so are not including it.

This is just a poll to get users input on the subject.

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

This. Please.

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.

https://en.bitcoin.it/wiki/Sweepprivkey

On the other hand, I see no reason why "sweep" would need to be under an advanced menu, any more than you'd expect "Redeem iTunes Gift Card" to be on the advanced menu of iTunes.

+1

This too

I would rather see export private key functionality.
I believe that the needle is pointing in a direction where users migrate to alternative clients. Let's make the transition easier. I know that they can just move the funds elsewhere, but many users have sent the corresponding addresses to other users/web-sites and/or use vanity addresses.
Also, exporting a key is much much easier, no need to have Bitcoin-QT rescan the block chain.

+1  Yes, please.

I'd rather vote for both import / export private key functionality under 'Advanced' menu option, reading something like 'Do only if you know exactly what you're doing!'. And may be some special marking of the imported keys to be visibly distinct to those generated by current wallet.

Or perhaps... we forget about the advanced menu and just make the import private key function available, but the user is prompted with an option of sweeping the funds when they do it. Like when they go to import the key it will show a message like "If someone else had this private key before you, your funds may be stolen. You can eliminate this risk by transferring the funds into your other secure addresses. Would you like to sweep the funds into another account?".

Problem solved. You're welcome. ;D

This is good. May be instead of 'your other secure addresses' this warning should read 'your organic addresses'? Just mark addresses to imported and organic with proper warning if imported addresses are attempted to be used as payment receipt or request payment addresses.

I would have that prompt off by default and not even bother with the explanation, and if anything, have an option in the advanced menu that turns that prompt on.  So, by default, one can only "sweep" a private key.  BUt if they go to the advanced menu, they could turn on a checkbox that gives them the choice of sweep/import each time they do it.  And that's a HUGE if.  I think if users can sweep keys, there is no good reason for them to import them into their wallet, and plenty of reasons for them not to.

The main advantage to importing versus sweeping is a) seeing future funds in your wallet if you're expecting them, b) preserving the bitcoin-days-destroyed and number of confirmations, resulting in a far less likelihood of needing to pay a fee to immediately respend the money.  Advantage A could be offered with a checkbox: "Remember this key and sweep any funds that arrive in the future?" and a boolean flag on the address that prods the client to sweep any time incoming money is seen.  Advantage B is relatively obscure and only those experts who are micro-managing their wallet should care to control it, especially if the coin selection algorithm is decent.  Someone with that much expertise and that much desire for control already understands the command line anyway, making it arguable that an import option is good enough when restricted to the RPC API.

If the number of confirmations is important for not incurring a fee, wouldn't sending any coins put into the address to another address you control require a fee?

I much prefer keeping my private key written down than backing up my wallet.

I found it difficult to import my private key when I needed to spend money from that address. I could only do it from the command line and only had access to my phone and tablet at the time. I had to install the client and download the blockchain to my work computer which took a while.

I wish there was a way to import on the Bitcoin App.

Indeed.  Any sort of private key from a gift card (or casascius coin) should be import and then the funds immediately sent to another private key, to prevent the previous private key holder from touching those funds.

I'll agree with adding "sweep" to the GUI, and leaving "import" to the RPC API.

The import use cases are things where people are doing some crazy things managing their own offline wallets or whatnot, and I think the command line is fine for things like that. Sweep is for people handing you a physical token (or QR code or the like) to pay you for something, and is a great way for me to give people their first coins.

If private keys are being sweeped, should the client still store these keys and sweep any further payments to these addresses too?

I think yes.

How about making this as a plugin to the bitcoin client? Then anyone that knows what they are doing would also know about the plugin, thus allowing them to install it. At the same time, all new users wont have more confusing buttons and terminologies they need to understand.

I think checkbox.  Right below the text box where they type the key.  "Remember this key and sweep any future incoming payments?".  The fact that MtGox has done it by default without providing any warning or notice has confused a lot of people, and confusion over money that moves by itself when you weren't expecting it is not confidence building.

On the other hand, a popup box would be needed to warn them that this will only happen while the client is running and synchronized with the network.  An expectation that their money "auto-forwards" like forwarding your calls when your mobile phone is off would also result in a rude awakening if someone finds that their money could be stolen by someone who was able to grab it before the sweep did.

I think it should be built in, and look as much like "Redeem iTunes Gift Card" does in iTunes: a simple button or menu option, and that's all you see until you go there and click it.  It doesn't confuse anyone: the concept is understandable even for children and grandma.  The setup infrastructure for finding and loading plugins would be far more intrusive and complex.

(Just for fun, I went to look at iTunes's redemption screen, and discovered that you can actually redeem iTunes gift cards just by holding them up to the computer's web cam.  The pictures in the interface suggest it does OCR on the gift card number, rather than any sort of bar code.  Now, that's user friendly.  Kudos to BlockChain.info for offering something similar for reading QR code private keys)

Interesting idea, I'm curious though about how it would handle the likelihood that autoswept funds would need a transaction fee?  What if the transaction fee ended up being a significant portion (or all) of the the swept funds?

It would have to pay the fee out of the autoswept funds - there's no clean alternative.  To avoid the fee, it would have to involve some of the user's coins (messy), or wait until the transaction is old enough (not good).

If the fee were most or all of the swept funds, it might as well not attempt to sweep them.

Advanced configuration options could include: Minimum amount to auto-sweep? (default: 0.01 BTC).  Auto-sweep even when a fee must be deducted? (default: yes)

Guys I really think this should be either kept extremely simple or extremely complex (from a general users point of view).

Mom and pop out there (which is pretty much the entire world online right now), have never even touched anything we all know as FTP client.

The gap between this little core of people here and the world is huge. Adding something that is way to user friendly will piss people off here since its not allowing for cool functions. Adding it too complex wideness the gap to mom and pop people. Plugins are seriously a great way to archive all the geekishness and still have a client that will only take mom and pop users 1 year to understand  ;D

I totally agree with the concept of plugins but believe that sweeping private keys should be a core feature.  Kind of like a normal bank account: depositing cash and checks is a core feature, investing in stocks is a plugin.

Everyone has used an FTP client before... to name a few in no particular order: Internet Explorer, Chrome, Safari, Firefox.  Being able to browse the web doesn't make them any less an FTP client.

I believe on the contrary that private keys should be kept private as much as possible and never exposed to users to "redeem" or "swipe" in the first place. Importing private keys for anything else than constantly monitoring their addresses and swiping them is dangerous at best and leads to a lot of coins lost at worst.

I'd rather have people come up with a way to create signed transactions that can go to any address and trade these around than exposing private keys and thinking about how to swipe them again and who else might have seen them.

I disagree.

Say I've just generated a vanity address that I wish to use in my QT client.  Aside from some command-prompt wizardry, there is no way for me to use it.

If an import option is offered, it absolutely MUST have the option to NOT sweep the funds.  I don't care if that is a feature reserved in some advanced options dialog, but it NEEDS to be an option.  There are plenty of legitimate use cases where private key importation without instant sweeping is necessary and desirable.

Also, I am 100% for GUI-based private key exportation as well.  Keeping the private keys locked up in a non-accessible format only hinders flexibility.  Again, it can be in an advanced options dialog for all I care, but it really needs to be an option for those who want to use it.

I am not sure I agree with such a blanket proposition.  I think the term "private key" is simply a language expression and does not mean that all "private keys" should be kept "private" the same way people should keep their genitals "private" while riding public transit.  Rather it should be dictated by the needs of the application employing them.

If a Bitcoin client using a deterministic wallet scheme would suffer a compromise of the whole wallet if one were to disclose a private key, well hell yeah, let's do our best to make sure the only way one can ever see one is to use no less than a debugger or a hacked client.  But if I want to make up a random number to assist me in handing you bitcoins on a piece of paper - a number that will be thrown away once you're done - just like a gift card or a money pack or phone card - I see no reason that that I should need to shield that number from your eyes the same way I'd be expected to shield you from seeing up my shorts... just because the algorithm you'll be feeding that number to refers to it as a "private" key.

Bad example:

The difference is like giving you a cheque that you can cash and teaching you how to forge my signature to sign one single transaction that I know about.

I know you want this functionality because of your coins and whatnot, but seriously I'd rather have sweeping private keys/wallets as a web service than within the client.
There needs to be a better way to keep bitcoins "portable" (= not under my control anymore but anyone else can redeem them to any address) than to give away private keys.

About vanity addresses, as far as I saw one can already combine a private key to such an address made up of 2 parts (so people can mine for them without knowing the private key), so that could be built in in some point of time. As you still need to have the 2nd part unique (and to your own) that doesn't solve the "physical bitcoin coin" issue though that anyone should be able to redeem.

This would make a good topic for the foundation..

Because of my coins... and the bills you can print... and the bitcoins one can dispense from a vending machine, or a POS receipt printer, or a million other uses that don't involve smartphones and desktop PC's.

I'd rather have it in bitcoind, because then other websites can accept private keys directly as payment.  If I had to pick between having a "Casascius Coin Redeemer" in the client versus an RPC call for sweeping private keys, I'd enthusiastically opt for the latter.


But there's not, and there's nothing wrong with that.  Private keys are just numbers.  Ultimately you have to give somebody 1's and 0's they have to keep private so they can take the money and nobody else, regardless of how it's implemented.


That's already been built.  https://bitcointalk.org/index.php?topic=128699.0 (https://bitcointalk.org/index.php?topic=128699.0).  You can have a two-factor trust-in-nobody physical bitcoin today, and I brought it to you.  You can even print your own two-factor paper wallets.  The second factor can be a full private key or just a passphrase.  Best yet (fwiw), if a website offered a "redeem" option, a user would never see the unencrypted private key (assuming that really matters).

Small nitpick. The wording should not be "Your funds can be stolen" but "The funds are not yours" or something like that.

Just look at the results of the poll so far. Why are we even debating whether people want this or not. It's clear most people want it. Hell, there have been several times where I could have used it for multiple different reasons. And a lot of those times I wouldn't need the sweep function either, I just wanted to import my private keys in a simple easy way. Is that so much to ask for christ sakes. If we are letting stupid people be the guide of bitcoins future, the future is looking dull.

My suggestion solves all the problems. It lets people know the risk of not sweeping the funds, and gives them the option of sweeping the funds, but also allows them to import the key without sweeping the funds. It's important to have both options available because they both server their own purpose and are useful under different circumstances. This isn't rocket science.

So that's your preference, but why prevent other people from using the client how they wish?  If I KNOW I am the sole owner of a particular private key, then why should I not be able to import it into my client so it can hang with the rest of my bitcoin wallet?

Vanity addresses can easily be generated by anyone on their home machines.  It doesn't have to be through a two-factor system (though I admit that the vanity-gen pool is very neat as well!)

I understand protecting people from stupidity, but the restrictions you'd like to see are going too far.  You eliminate so many use-cases by not allowing private key imports.


Lol, +1.  I don't understand why this is even a debate.

If you're willing to go as far as creating plugins for Bitcoin-Qt to do this, you might as well just use Armory (http://bitcoinarmory.com/).  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... </shameless plug>

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.  :P  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?

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

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.

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

+1

+1

You would like both options very much, yes.

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.

Me too.  ;D

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.

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.

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.

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.

Just bumping to get up to 100 votes!
Thanks

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.

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?

+ a thousand.