Sweep/import private key feature request

[DeathAndTaxes]

I assume a redeemed phone card can never have funds placed in it again.  If I were to publish an address for payment, then sweep the private key to get the funds, who is to say that someone will never send funds to that (published) address again?

Why would you do that?

If the private key is INSECURE why would you publish it for future payments?
If the private key is SECURE why do you need to sweep it (just import it as a "full trust" private key)?

We are talking about a key that is simultaneously insecure and published for future payment. The question would be why?  It would be like me selling you a partially used prepaid phone card (the pincode has been scratched off).   You have no security.  While you may use it for the current phone call (and thus end our risk) it is another thing to think you would save that phone card so you can recharge it later (put future funds at risk).  Just buy a new phone card. 

An example in case I am being unclear:
I owe you 20 BTC.  I fund a private key w/ 20 BTC, print it out and give it to you.  This being an unsecure private key you sweep it, and throw the private key away.  One use, never use it again like a spent gift card or prepaid phone card.  Your risk is limited to the current transaction (like any unverified transaction).    The same day you decide to make a donation address.  You take a DIFFERENT SECURE address generated by your wallet and publish that one.  By throwing away the insecure address and using secure addresses for publishing you ensure the wallet remains secure not just now but in the future as well.

You seem to indicate you would do this instead:
I owe you 20 BTC.  I fund a private key w/ 20 BTC, print it out and give it to you.  I know the private key and can steal funds from it at anytime.  Despite the very obvious security risk, you generate a public Bitcoin address from the insecure key and decide to publish this one as a donation address.  You now have no security.  Any future funds sent to that address can be stolen at will.

Can you imagine a realistic scenario where someone would take an insecure private key, generate a public address from it, publish that so there may be future funds coming in and then sweep it, and need to keep track of that insecure private key into perpetuity?  Is it common enough to build that functionality into a wallet?  Is it something we want to support and encourage?

[1714237665]

1714237665

[1714237665]

1714237665

[1714237665]

1714237665

[1714237665]

1714237665

[netrin]

btc_artist, what if the client maintained a wallet.dat and untrusted.dat? The coins in untrusted.dat would never appear in the client balance. A menu option would allow for 'Sweep Untrusted Keys'. An opt-in automatic asynchronous process could sweep periodically. If you wanted to interact with the keys directly, you could simply backup and rename untrusted.dat.

If the private key is INSECURE why would you publish it for future payments?

It IS published in the block chain. Who knows where else it may exist in print.

We are talking about a key that is both insecure and you intend to use for future payment.  The question would be why?

I think you are putting too much emphasis on 'insecure'. In PGP parlance, it would only not be ULTIMATELY trusted.

Let us not be limited to use cases we can currently imagine.

[DeathAndTaxes]

I think you are putting too much emphasis on 'insecure'. In PGP parlance, it would only not be ULTIMATELY trusted.

Let us not be limited to use cases we can currently imagine.

Not even close.  A private key someone else has access to is ABSOLUTELY INSECURE.  Period.  It has absolutely no security value what so ever.  Funds can be stolen at will and that action would be anonymous, impossible to prove, and irrevocable. 

To avoid theft, or fraud you are simply trusting the person(s) who had access to the key won't choose to rob you.  They might but it won't be due to any cryptographic strength.

[netrin]

Can you imagine a realistic scenario where someone would take an insecure private key, generate a public address from it, publish that so there may be future funds coming in and then sweep it, and need to keep track of that insecure private key into perpetuity?  Is it common enough to build that functionality into a wallet?  Is it something we want to support and encourage?

If something is a security risk, or it's a pain in the ass to code without any immediate benefit, that's fair, but I do not like the question "Is it something we want to support and encourage?"

Rather than the recipient republishing an address received from an unknown untrusted entity, you could vaguely imagine cases where trusted (but potentially incompetent) users share some fund. Suppose my girlfriend and I have a bake sale and share an address, either one of us could sweep the keys. Of course there may be better ways to handle this particular instance, but I only use it as an example legitimate case.

[DeathAndTaxes]

Rather than the recipient republishing an address received from an unknown untrusted entity, you could vaguely imagine cases where trusted (but potentially incompetent) users share some fund. Suppose my girlfriend and I have a bake sale and share an address, either one of us could sweep the keys. Of course there may be better ways to handle this particular instance, but I only use it as an example legitimate case.

That would be insecure.  While you could do that if the wallet didn't make it easy to do so you likely wouldn't and thus would choose some mechanism that is secure. 

In essence the user is incorrectly trusting a key which shouldn't be trusted.   Since the user doesn't realize the risk wouldn't he simply IMPORT it

Trusted Key = IMPORT
Untrusted Key = SWEEP

Granted that would be bad too but not much worse and maybe a warning on the import option makes him pick a more secure way to handle payments.

[netrin]

I've generated multiple wallets over the year, created on different machines, with different client versions, with different levels of trust. I've transfered those funds to my latest and greatest secure wallets, but every once in a while I go through this corpus of wallets looking for coins. I have no specific reason not to trust those old keys, but for example, one was made on a Windows machine at work when I was very new to bitcoin. It doesn't have the same level of security in my mind as my wallet on an offline private Linux box.

I will likely import and merge all of my old wallets into a single untrusted/old wallet. But it really should not be difficult to continually sweep those keys. I think it's a reasonable use case, with a relaxed definition of 'insecure'.

Since the user doesn't realize the risk wouldn't he simply IMPORT it ... Granted that would be bad too but not much worse and maybe a warning on the import option makes him pick a more secure way to handle payments.

You are taking my 'off the top of my head' example too far. But yet you admit the problem of social engineering through code. You can't prevent users from doing what they want. You should give them tools they don't need to break, but might learn to understand.

[btc_artist]

I owe you 20 BTC.  I fund a private key w/ 20 BTC, print it out and give it to you.  I know the private key and can steal funds from it at anytime.  Despite the very obvious security risk, you generate a public Bitcoin address from the insecure key and decide to publish this one as a donation address.  You now have no security.  Any future funds sent to that address can be stolen at will.

What if I sweep the private key and transfer my 20 BTC, at a later date you assume you can send me an additional payment using the same public address as before, but I no longer have the private key? Of course, YOU personally wouldn't do this, but people might.  This is why I'd like to keep the insecure private keys around to check/resweep them at a later date, if necessary.

Can you imagine a realistic scenario where someone would take an insecure private key, generate a public address from it, publish that so there may be future funds coming in and then sweep it, and need to keep track of that insecure private key into perpetuity?  Is it common enough to build that functionality into a wallet?  Is it something we want to support and encourage?

Easy.  I generate a (secure) vanity address to receive donations.  I publish the address all over the place and people start donating to it.  I then inadvertantly/unthinkingly/stupidly email the private key as plain text to myself for whatever reason.  The private key is now no longer secure, but I would still like to keep sweeping it to get any additional funds sent to it.  Even if I change my public donation address, it is cached all over the place and people have it saved, etc, so I will keep receiving donations there for some time or even indefinitely. 

Emailing the private key as plain text is only one example. What if the computer storing your unencrypted wallet.dat gets a virus/trojan?  What if the computer gets stolen?  I know you and I would never mail a plain text private key, not would we ever get viruses (we're careful, after all), but there are dozens of scenarios where the secure private keys that correspond to public keys that may continue to receive funds could become compromised and fall into the "insecure" private key category.

[btc_artist]

Trusted Key = IMPORT
Untrusted Key = SWEEP

Agreed.  But for above-mentioned reasons, all keys that have been swept should be kept hidden in an advanced interface somewhere, where you can periodically (or automatically) check and see if funds have been added to any of them.

[paraipan]

Trusted Key = IMPORT
Untrusted Key = SWEEP

Agreed.  But for above-mentioned reasons, all keys that have been swept should be kept hidden in an advanced interface somewhere, where you can periodically (or automatically) check and see if funds have been added to any of them.

+1 sounds nice

[DeathAndTaxes]

Trusted Key = IMPORT
Untrusted Key = SWEEP

Agreed.  But for above-mentioned reasons, all keys that have been swept should be kept hidden in an advanced interface somewhere, where you can periodically (or automatically) check and see if funds have been added to any of them.

That makes sense.

I could see auto-sweep web services being an alternative solution.  You provide a webservice one or more private keys and a public address from a secure wallet.  The service could continually auto-sweep funds for a small fee. Granted there is an element of trust but given that any theft would be obvious and at any time the service would only have access to funds in transit the risk is less than say an ewallet.

[BkkCoins]

Trusted Key = IMPORT
Untrusted Key = SWEEP

Agreed.  But for above-mentioned reasons, all keys that have been swept should be kept hidden in an advanced interface somewhere, where you can periodically (or automatically) check and see if funds have been added to any of them.

Doesn't this just need a flag on an address that indicates whether it should be swept periodically (starting with right now)? You should be able to tag any address with this flag as it's probably useful for various situations. I could see the flag having a minimum value. In fact, simply a "sweep when" value attached to each address would do. When zero it has no effect but above zero it sweeps if funds arrive/accumulate. Maybe you set this threshold when you import according to how you created and will use that key.

[niko]

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.

This.

[sadpandatech]

Just in case anyone here did not see the new Armory client or note its features. It includes a pretty nifty sweep/import feature.
thread here; https://bitcointalk.org/index.php?topic=56424.0

[etotheipi]

Just in case anyone here did not see the new Armory client or note its features. It includes a pretty nifty sweep/import feature.
thread here; https://bitcointalk.org/index.php?topic=56424.0

Indeed.  I'm just about to do a testing release, which has most of the Armory feature list implemented -- including address sweeping and importing.  In fact, the design of that dialog was based on this thread!  I had to disable zero-confirmation transactions until I have time to put in the "correct" solution, but just about everything else is working, or at least usable.  

I've already pulled in a bunch of VanityGen addresses and use it to manage donations.  Then I used the key-backup dialog to print out a list of imported keys onto a single sheet of paper, and tucked away in a safe place so I can never lose them.  

And yes, it supports mini-private key format, and the Base58 private key format [0x80 + 32-byte-priv-key + 4-byte-chksum], as well as raw hex dumps of private keys, and it even makes sure the private key is in the right endianness (assuming you know what the Base58 address is supposed to look like)!  

Now that offline transactions are working, I'll be releasing build-instructions shortly!

[cbeast]

Can't wait til a granny-safe version of this is ready!

[payb.tc]

Can't wait til a granny-safe version of this is ready!

don't forget to make some air holes in your granny safe.


i'm really looking forward to easy-to-use wallet merging software, so i can organise a ton of wallet backups that are from all over the place and from all different dates... a mess. Consolidate the keys into 1 or 2 wallets and shred the rest.

armory sounds interesting, but i'm put off by the fact that the wallet file is not compatible with the satoshi client.

[Red Emerald]

armory sounds interesting, but i'm put off by the fact that the wallet file is not compatible with the satoshi client.

The satoshi client's wallet is not the best and incompatibility with it shouldn't be viewed as a negative IMO. It will hopefully soon be simple enough to export your keys from your old wallets and then import them into your new wallet.  You won't actually care what the wallet format is since you are moving around private keys.

[payb.tc]

The satoshi client's wallet is not the best and compatibility with it shouldn't be viewed as a negative IMO.

is that good or bad? does not compute.

[Red Emerald]

The satoshi client's wallet is not the best and incompatibility with it shouldn't be viewed as a negative IMO.

is that good or bad? does not compute.

EDIT: added an "in" to compatibility. Oops

[Stardust]

I was really looking forward to the import feature in bitcoind (don't care about sweep). Too bad the developers decided to be nanny for us.