Sweep/import private key feature request

[casascius]

Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?

[paraipan]

Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?

+1

[netrin]

Pretty-please, is importprivkey or sweepprivkey or (mergeWallet or) any similar functionality coming soon?

Beautiful-please...

[btc_artist]

Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?

Pretty please with a cherry on top.

[Luke-Jr]

Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?

This isn't a place to spam feature demands. If you really want to see this functionality, help get it usable and stable/tested.

The big issue is that importing a key as-is will suddenly show a bunch of "send"s in your history, and likely creates a security risk. What is more likely to be workable is the "sweep" functionality that resends any balance on a private key to a new known-secure private key, but nobody has written that yet.

[netrin]

Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?

This isn't a place to spam feature demands. If you really want to see this functionality, help get it usable and stable/tested.

The big issue is that importing a key as-is will suddenly show a bunch of "send"s in your history, and likely creates a security risk. What is more likely to be workable is the "sweep" functionality that resends any balance on a private key to a new known-secure private key, but nobody has written that yet.

Is there a thread discussing these security risks?

I no longer use the C++ client because it fulfills few of my use cases. Alternatives reduce the incentive to test and improve the 'reference implementation'. Perhaps there could be an unstable/risky 'and the kitchen sink' nightly build.

[Luke-Jr]

Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?

This isn't a place to spam feature demands. If you really want to see this functionality, help get it usable and stable/tested.

The big issue is that importing a key as-is will suddenly show a bunch of "send"s in your history, and likely creates a security risk. What is more likely to be workable is the "sweep" functionality that resends any balance on a private key to a new known-secure private key, but nobody has written that yet.

Is there a thread discussing these security risks?

It's simply that you're inputting a private key from an external source, when the mindset most users will have is that their balance is theirs. ie, the risk that someone else somewhere has a copy of the private key.

[btc_artist]

It's simply that you're inputting a private key from an external source, when the mindset most users will have is that their balance is theirs. ie, the risk that someone else somewhere has a copy of the private key.

Both import and sweep cases are valid.  If I *know* my private key is secure, I may want to have it in my wallet to receive coins sent there in the future.  If I'm redeeming an unknown private key, I would use sweep which would immediately send the coins to a new key in my wallet, and still maintain the swept key to sweep it again if/when more funds are sent. They are both valid with separate use cases.  There's no security issue.  The client just needs to be clear about what they both do. 

Sorry for getting off topic.  These posts should be moved to another thread.

[btc_artist]

Topic split from: https://bitcointalk.org/index.php?topic=54488.0

[casascius]

Pretty-please, is importprivkey or sweepprivkey or any similar functionality coming soon?

This isn't a place to spam feature demands. If you really want to see this functionality, help get it usable and stable/tested.

The big issue is that importing a key as-is will suddenly show a bunch of "send"s in your history, and likely creates a security risk. What is more likely to be workable is the "sweep" functionality that resends any balance on a private key to a new known-secure private key, but nobody has written that yet.

I put up a bounty worth (at the time) $500 USD for this feature, so I think I deserve to be on a slightly higher level of respect than a spammer.  Although it was denominated in BTC, I would be likely to revise the bounty to be worth the same in USD.

I have put a detailed spec in the wiki as to how I believe sweepprivkey should work.

One obstacle is there needs to be an index so that there is a time-efficient lookup from a Bitcoin address (e.g. hash160) to the blocks that contain references to it.  That index ought to be an option (build-on-first-use etc.) so it doesn't consume disk space of those not interested in using it.  Once this is done, the actual implementation of sweepprivkey ought to be fairly simple.

User jarpiain on github has made some sort of progress on this that could likely be incorporated.

[netrin]

It's simply that you're inputting a private key from an external source, when the mindset most users will have is that their balance is theirs. ie, the risk that someone else somewhere has a copy of the private key.

I think you are pushing the general understanding of 'security' way too far. As if running shoes should be equipped with special sensors and alarms preventing you from tying your shoe laces together.

How did I get this private key? I created it myself, I stole it, or someone gave it to me. If I now see transactions from before I imported this private key, that would be fully expected behavior. At most it is confusing, but I see no security issue what-so-ever.

It's certainly valid to expect features to be well tested, but we should balance utility against impossible-to-protect-the-user-from-himself conservative development practices, lest we relegate the 'reference implementation' into oblivion.

[btc_artist]

When importing the private key, just have a check box that says

If this private key may be known to others, check here to transfer the bitcoins to a new key in your wallet. A transaction fee may apply

In either case, you keep the imported private key in the wallet, in case more BTC is sent to it.

[paraipan]

When importing the private key, just have a check box that says

If this private key may be known to others, check here to transfer the bitcoins to a new key in your wallet. A transaction fee may apply

In either case, you keep the imported private key in the wallet, in case more BTC is sent to it.

+1, nice elegant way of importing keys.

How about exporting/importing priv keys to file too, with a .bit extension for ex. Should export a newly generated key and fund it with the amount you enter in the respective dialog.

[Gavin Andresen]

In either case, you keep the imported private key in the wallet, in case more BTC is sent to it.

So what happens when two users import the same private key into their wallets?
 (or you accidently or on-purpose import the same private key into two of your wallets?)

You can say "Don't Do That", but if they CAN do that, then they WILL.

[netrin]

You can say "Don't Do That", but if they CAN do that, then they WILL.

So what. They CAN delete their wallet, and they WILL.

[btc_artist]

In either case, you keep the imported private key in the wallet, in case more BTC is sent to it.

So what happens when two users import the same private key into their wallets?
 (or you accidently or on-purpose import the same private key into two of your wallets?)

You can say "Don't Do That", but if they CAN do that, then they WILL.

Then whoever spends them or sends them to another address first keeps them.  I honestly don't see a problem with that-- that's why you'd have the check box to send the funds to a new key if the one being imported may be known to others.

[netrin]

Anyone clever enough to have two wallets is clever enough to understand the implications of merging them. The utility of merging, upgrading backed up wallets, splitting, side-channel transactions, etc far outweighs a bit of potential confusion.

[btc_artist]

Gavin, I think it's important to remember that as developers we will never be able to protect all the stupid people from all the mistakes they might make.  We can and should try an make the product as robust and foolproof as possible, but even more importantly, we need to make the product as powerful and as flexible as possible at the same time.  If there is a clash between the two, we should choose to make the product more powerful, instead of fighting the futile battle of protecting stupid people from themselves.

[nelisky]

A product with both 'foolproof' and 'powerful' is possible in theory. Let those that are capable of compiling switch the 'advanced' mode on, though of course there will be someone sending ready built 'advanced' versions to foolish users.

Make it a configuration that you have to edit by hand, and make the first run of the client show a bit red flashing 1999-web-page-like dialog stating they WILL screw up eventually, so be careful.

Not giving the option by default is a smart move, maybe even only give using RPC to start with and see how inventive users get. But not giving the option at all because it might be dangerous... I gave a user an address for him to send me 70 coins for some stuff I sold... but I gave one of my *sending* addresses instead of *receiving*. I was stupid, but what allowed this to happen? Was it the copy to clipboard feature? The address book? Should we get rid of both?

[Gavin Andresen]

I like "sweep" -- it has very clear semantics that I think users will understand:  "Take all the funds that were sent THERE, and send them to me RIGHT NOW."

Automatic sweep-every-once-in-a-while functionality would be fine, as long as it was coded properly (sweeps should only be done if you have the full block-chain, not if you're busy catching up, and shouldn't be done immediately to avoid a flurry of accidental double-spends if you have several wallets setup to sweep the same key(s)).

I don't like "import" -- it has muddy semantics that I think users will not understand.  "You kind-of-sort-of own the funds that were sent THERE, unless somebody else happens to have a copy of THERE that you may or may not know about."

Import is bad because it can lead to a situation like:
 Start up bitcoin, see you have 1 BTC in your wallet (sent to an imported private key in block 111,000)
 So you send half of it to your friend to pay for lunch.
 ... bitcoin chugs away, and it turns out that 1BTC was spent already, in block 190,000.
 User is all "wtf??? where did my BTC go???"

If you're an uber-geek and know what you're doing, then you should use geeky, dangerous tools like PyWallet to do what you want to do.