Sweep/import private key feature request

[netrin]

Would you like to secure these coins with a new private address? This is recommended, especially if you've received coins from another party.

([ Secure! ])    [no]

Default Secure (transfer coins). I see no realistic use case in which a user would be confused, no more than not having this feature (managing multiple wallets is much more confusing than merged wallets).

[1714278797]

1714278797

[1714278797]

1714278797

[1714278797]

1714278797

[1714278797]

1714278797

[btc_artist]

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

I don't quite agree, since if I securely generate a paper wallet, I know I am the only one with the private key.  But, I concede the point.

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 like "sweep" as well, and I think it would meet all the use cases I have for importing, as long as it keeps a copy of the private keys that have been swept and implements "auto sweep" on them fairly often (once a day?).

[nelisky]

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.

Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way.

[DeathAndTaxes]

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.

Or put another way (a classic software development quote...

Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots.  So far, the Universe is winning.

  ~Rich Cook

[netrin]

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

I like "sweep" as well, and I think it would meet all the use cases I have for importing, as long as it keeps a copy of the private keys that have been swept and implements "auto sweep" on them fairly often (once a day?).

It would be nice if there were still an option to do a clean import. It can be hidden under an advanced tab, with a checkbox confirming that yes I really understand the implications and yes I know it is not recommended and that a kitten will die.

A sweep to a single address has side effects that a non-guru, but still savvy user, might not appreciate, such as merging all transaction history into a single IDENTITY, throwing out any pretense of plausible anonymity.

[DeathAndTaxes]

If there is a debate on importing/sweeping then how about a limited use case of sending funds to your wallet from a private key.

Call it "deposit balance from private key".
User clicks "deposit balance from private key" from the menu, enters key, and the wallet advises user of the balance w/ a "do you wish to transfer the 123.45 BTC from this private key to your wallet."



Would be useful for "redeeming" physical bitcoins (like Cascius coins).

[splatster]

If there is a debate on importing/sweeping then how about a limited use case of sending funds to your wallet from a private key.

Call it "deposit balance from private key".
User clicks "deposit balance from private key" from the menu, enters key, and the wallet advises user of the balance w/ a "do you wish to transfer the 123.45 BTC from this private key to your wallet."



Would be useful for "redeeming" physical bitcoins (like Cascius coins).

I think deposit would be the best thing to call it, but it should still collect funds sent to that key and send them to a key generated within the client.

[Gavin Andresen]

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.

Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way.

The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time).  For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept.

It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work?

[netrin]

What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?

[nelisky]

The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time).  For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept.

It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work?

Yes I can. It's just hard to do so without giving away too much of a potential project idea, but better support trumps business secrecy any day in my book so; I have a storage of priv keys, generated offline, and I need to hot include these on a running server. Now mind you I own these keys, I generated them myself, but they do not exist in a wallet, that would be VERY impractical.

I could take the server down, use pywallet, start with -rescan. But I don't want to HAVE to batch imports, meaning a rescan for each key. Because I know at which time point the key was first used (and most times it will not have been used at all, thus no -rescan is needed), and that is very easy to find when unknown if the blockchain is properly indexed, so I can request a rescan from block nr X.

This is the one case I have where sweep would simply not fit, but for every other case I've come across and use a custom patched client for, sweep would be just fine. Though sweep with an option to keep the key in the wallet but *not* resweep would work just as well.

[btc_artist]

What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?

You would need to re-sweep it periodically to get any additional funds sent to it.

[paraipan]

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.

Agreed, except those doing web services that might depend on this feature are left with either non-official clients or patching the official ones, which gets complicated to maintain in a stable, well tested way.

The current import patch needs work to be of practical use to web services-- it does a scan of the entire blockchain to find transactions to the newly imported key (and keeps the wallet locked that entire time).  For any sweep/import solution to be useful for more than once-in-a-blue-moon use, an index of pubkeys to transactions involving those keys should be kept.

It seems to me the "sweep now, and re-sweep every once-in-a-while" functionality would work nicely for web services. Can you describe a use case that wouldn't work?

would be possible to have the basic sweep feature implemented ? in some kind of "advanced features" section and all the required warnings. And yes "sweep" seems to be more correct describing the action done with they priv key.

[netrin]

What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?

You would need to re-sweep it periodically to get any additional funds sent to it.

This seems to suggest that an swept private key would not be (even after transferring funds to a new address) imported as a first-class citizen like all other private keys in the wallet.

[finway]

re-sweep brings some latency, i think piuk won't worry about this kind of things.

[DeathAndTaxes]

What do we mean by re-sweep? Once the private key is imported, rescanned with the full latest block chain, is there any need to re-anything more before another import?

You would need to re-sweep it periodically to get any additional funds sent to it.

This seems to suggest that an swept private key would not be (even after transferring funds to a new address) imported as a first-class citizen like all other private keys in the wallet.

Hence the word SWEEP not IMPORT. 

There is no guarantee that a private key doesn't have another copy known by another party.  While some users may want to treat an external private key as an IMPORT many wouldn't.  They simply want to transfer funds to private keys they know are secure.

IMHO the ultimate (albeit potentially confusing) solution would be to both import OR sweep private keys.

[netrin]

Then it appears to me that this sweep 'solution' is more confusing, error prone and retarded than anything it's trying to solve.

I believe there are only two general use case categories: (1) I created two wallets myself and want to merge them for convenience or (2) I obtained a private key or a wallet from a third party and want to merge them into my existing wallet.

The 'confusion' due to case (1) is silly. I can't even articulate in a short paragraph how someone could be confused after merging their own wallets. As for (2), perhaps some users might not realize there is a double spend (race to spend) condition, so it is wise to suggest that the user immediately transfers the funds to a new address. After doing so, life should move on; All keys should behave similarly. If another party sends money to the imported key, no problem. If the original creator of the private key forgets that he gave the key away, no problem. How is this user, the one importing, going to get confused? Because there's an earlier history?

[casascius]

I would agree that the "sweep" should be the more general use case: someone wanting to cash in a physical bitcoin, or a "Ron Paul Cheque" or whatever else they might have received.

Sweep will keep their ledger making the most sense: they'll appear to have received funds at the time they did the sweep, not at the time that the physical bitcoin was manufactured.

Sweep is also vital for website operators to be able to accept private keys directly.  I believe this little feature will open up Bitcoin immensely, as it will free the average joe user from ever having to use software or an online wallet - he can keep all his bitcoins on paper, safe from theft or digital loss.  One can buy bitcoins at retail, and go directly to an online merchant and spend them, without any need for exchanges - a HUGE simplification.

Import is something I see as more of an advanced feature.  If we got sweep into the mainline client, and import was something that had to be patched in, I would consider it a victory.  Import is nice if (a) you like maintaining your own paper wallets and like seeing your own transactions appear in your history, and (b) if you'd like to spend straight from the paper wallet and avoid transaction fees (since a "sweep" will consume all the fee-eliminating "bitcoin days" your coins earned sitting on paper).

However, the lack of either of these isn't a show stopper - the sweep function will give the greatest utility with the least complexity.  We need the index it depends on, and then the RPC command, and then something added to the UI.

[netrin]

I do see the absence of these very simple axiomatic key functions as show stoppers. Why do I have to be a guru to wrap up a card to be opened in ten days which reads:

Merry Christmas Dad!

Here's a little something from the interwebz: privkey:5js8shF9Eahjg8aHkjhaCzbcK9s

And more importantly, why must my Dad be an über-geek to receive my paper coins?

[nelisky]

I still feel that import should be a feature embedded in the main client, even if only when compiled with special switches and/or limited to the RPC. This is something I see as very important for my business ideas, but only as part of a server infrastructure.

When it comes to the client side, the GUI, then I most certainly think that import could be completely avoided by the use of sweeping. I would even argue 'KISS' and no auto resweeping should be implemented... if you know more funds are going that key way, just resweep it yourself. Since the block chain is already in the client and we can know what balance exists in that key, we could completely skip the importing and thus display of any transaction log related to the swept key, which would make things very clear to users, even the "lower grade" ones.

+1 for getting sweep in asap, it will make things easier for everyone. The only thing missing then is the (very dangerous) ability to export a private key without keeping it in wallet on the UI, so users can generate an address to send someone (like bitaddress.org does using JS), print QR code, email, whatever and then simply send funds to that address.

We can already do that last part using external tools, but these are prone to a number of attacks, scams and the like. If 'regular joe' is able to send dad some funds using a private key he generated, we'll start seeing a much, much easier way of giving away bitcoins *before* educating people about it... perception of value:

- Hey, why don't you go to this website, read about this new uber crypto pseudo-anonymous currency, browse the forum where many, many users are talking about scams, crypto algorithms, FPGAs, scams, politics and scams, then install the software, wait 2 days for the block chain to download, generate an address for me which by the way will keep changing in the UI and I can try to explain why but without knowing the basic concept behind this it will all sound very complicated and THEN I'll send you 10 btc to get you started.
.. versus ..
- Hey, here's a voucher for 10 bitcoins. You already have the "cash", now you just need to <insert hoops to jump here>.

So while the effort is exactly the same, the latter gives you the value immediately and you are much more likely to jump the hoops

[casascius]

<insert hoops to jump here>.

Where <hoops> may be to just log on to Silk Road and type the code there for instant credit, like a gift card, which will represent a use case even average joe can understand and appreciate.

Then they will use the funds to purchase a ten dollar bill discreetly mailed to them.