Sweep/import private key feature request

[casascius]

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

[1714283642]

1714283642

[1714283642]

1714283642

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

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

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

[paraipan]

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

woot, bitcoin coupons accepted everywhere even in the satoshi client (key sweep), mtgox have it already

[barbarousrelic]

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

This can already happen, say, if a person has a copy of their wallet on their Linux partition and another on their Windows partition. If you spend the money on the Linux partition, and then a few days later boot to Windows, it will appear you are richer than you are until the blocks all download.

And correct me if I'm wrong, but the person being sent the nonresistant half bitcoin would never see the transaction, right?

[netrin]

For two parties with accepting services, Mt. Gox redeemable codes are much easier and faster to transfer than real bitcoins, but would offer no benefit over private key import/export.

Could someone please explain how a 'sweep' is more simple and less confusing than 'import and transfer'?

I realise the blockchain is slow. That is an issue. But it won't be solved by complicating local key management.

[Gavin Andresen]

This can already happen, say, if a person has a copy of their wallet on their Linux partition and another on their Windows partition. If you spend the money on the Linux partition, and then a few days later boot to Windows, it will appear you are richer than you are until the blocks all download.

... and that's exactly why I discourage people from doing things like that. It is too easy for two "copies" of a wallet to get out-of-sync.

You have to be a geek and muck around with copying the wallet.dat file from one place to another to get into trouble, and that is by design. I have no problem at all with geeky tools that let you do dangerous things (like PyWallet).

The JSON-RPC interface is trickier, because adding dangerous functionality there might encourage web services to do not-so-smart things like sending private keys over unencrypted/unprotected channels ("Email the private key as a Christmas gift" works great for a while, and then the bad guys start looking for privkeys in traffic they're sniffing and spend them before your Dad can....)

[casascius]

The JSON-RPC interface is trickier, because adding dangerous functionality there might encourage web services to do not-so-smart things like sending private keys over unencrypted/unprotected channels ("Email the private key as a Christmas gift" works great for a while, and then the bad guys start looking for privkeys in traffic they're sniffing and spend them before your Dad can....)

I'm not sure this qualifies as something we should be protecting people against, similar to what Netrin mentioned about preventing people from tying their own shoelaces together.

If someone sends a private key, or a MoneyPak card number, or their mother's maiden name over an encrypted channel, that's not Bitcoin's problem, or GreenDot's problem, or their mother's problem.  If someone gets their bitcoins stolen out of their plaintext e-mail, the situation will self-correct for the future, much like in the case where someone ties their shoes together.

[coretechs]

I'd send an Amazon gift code in email, how is that any different?

What about the security of users who have to futz around with swapping wallets and or scripts to move around bitcoin?  It's very tempting to just use a third party tool which lets you import private keys into an online wallet, but telling new users to trust a 3rd party is even worse given the history of mybitcoin, etc.

I think sharing a private key, be it a pass-phrase to be hashed, or a more securely generated key, is the easiest way to send bitcoin anywhere without worrying about any of the security issues present in cyberspace.  Sure, someone may eavesdrop, but the functionality benefits far outweigh the *potential* security risks.  Importing private keys manually (via sweep at the least) should definitely be an option in the client.

If anonymity is important, the ability to easily transfer and later redeem coins OUTSIDE of the blockchain (via privkey xfer) is just as important as transferring them within the network.

[DeathAndTaxes]

I'd send an Amazon gift code in email, how is that any different?

What about the security of users who have to futz around with swapping wallets and or scripts to move around bitcoin?  It's very tempting to just use a third party tool which lets you import private keys into an online wallet, but telling new users to trust a 3rd party is even worse given the history of mybitcoin, etc.

I think sharing a private key, be it a pass-phrase to be hashed, or a more securely generated key, is the easiest way to send bitcoin anywhere without worrying about any of the security issues present in cyberspace.  Sure, someone may eavesdrop, but the functionality benefits far outweigh the *potential* security risks.  Importing private keys manually (via sweep at the least) should definitely be an option in the client.

If anonymity is important, the ability to easily transfer and later redeem coins OUTSIDE of the blockchain (via privkey xfer) is just as important as transferring them within the network.

The attack window is very small on Amazon gift code.  Once you use it (by attaching it to an amazon account) the code is worthless.

Not true w/ a private key.  Just importing private key into wallet leaves it open for attack so the attack window is no much longer (potentially months or years).  Worse if the client isn't aware this is a potentially compromised key the user could use the corresponding public key to receive funds.  So even if the address had a value 0 when attacker found private key he could keep searching block chain and steal coins into the future.

The Amazon gift code IMHO is a good counter example.  Any functionality in the client should perform similarly.

[coretechs]

Then I suggest thinking about ways to making the functionality a one-time sweep - i.e. Enter "code" to redeem/transfer stored coins to your wallet.  It shouldn't be suggested that the bitcoin address from a physical token should be reused for any reason.  The balance could just be reported by the sweep function, i.e. "You have redeemed 10 BTC that have been sent to your wallet", just like an Amazon gift code is credited to your account.  There is no need to keep the private key in the users wallet file at all - make a second wallet temporarily, rescan, submit the transaction to transfer it to an address in the users wallet and throw the temp one away. This is the manual process I have used in the past, I'm sure it could be simplified in the client.

[DeathAndTaxes]

Then I suggest thinking about ways to making the functionality a one-time sweep - i.e. Enter "code" to redeem/transfer stored coins to your wallet.  It shouldn't be suggested that the bitcoin address from a physical token should be reused for any reason.  The balance could just be reported by the sweep function, i.e. "You have redeemed 10 BTC that have been sent to your wallet", just like an Amazon gift code is credited to your account.  There is no need to keep the private key in the users wallet file at all - make a second wallet temporarily, rescan, submit the transaction to transfer it to an address in the users wallet and throw the temp one away. This is the manual process I have used in the past, I'm sure it could be simplified in the client.

I agree.  It the way users think of other "codes".  Get a prepaid phone card, scratch to reveal the code, enter the code and you phone has the "value" the card is worthless.  Someone send you an Amazon giftcard, enter the code into your Amazon account and it now has the value.  The code is now worthless.

Granted there are other edge cases but it is the most common scenario and it should be simple to do in the client.  Say someday physical stores started carrying Cascius coins or other physical bitcoin manifestation.   There should be a simple mechanism to transfer that "value" from the coin to their wallet just like users do everyday w/ giftcards, xbox live cards, phone cards, etc.

[casascius]

The attack window is very small on Amazon gift code.  Once you use it (by attaching it to an amazon account) the code is worthless.

Not true w/ a private key.  Just importing private key into wallet leaves it open for attack so the attack window is no much longer (potentially months or years).  Worse if the client isn't aware this is a potentially compromised key the user could use the corresponding public key to receive funds.  So even if the address had a value 0 when attacker found private key he could keep searching block chain and steal coins into the future.

The Amazon gift code IMHO is a good counter example.  Any functionality in the client should perform similarly.

I think this is true in theory, but not in practice.  If I receive a private key in a birthday card, or from a website that sends it to me in the clear, I have no reason to expect that someone (money elves?) are going to think they should send me payments that, heaven forbid, will be lost if I don't have some automatic means to ensure they can be claimed.

I believe that the vast majority of the time a private key is passed from person to person, it's intended as a single use.  It won't be long, people will catch on to the fact that anyone who knows their private key can spend their money, and that this will be understood not as a scandal, but as part of how the system works, just like people understand that anyone who has their car keys (or functional copies thereof) can drive their car, and that that's not Honda's fault.

It reminds me of the debate over what example address should be used in the Wikipedia article about Bitcoin - until it was settled on an invalid address, people were getting caught up over making sure that the address in the article wasn't usable for accepting payments, because it would be unfair, so it was said, for someone to have their address in the Wikipedia article, because they would be the lucky but undeserving recipients of all the payments that people would be supposedly be sending there just to test their Bitcoin clients.

I think people have an inflated perception of how many people (or "money elves") out there are just looking to send money somewhere just for the sake of doing so.  I think that making an effort to ensure that payments made by money elves is as misguided as putting up sticky spiderweb nets in one's front yard just to catch ten dollar bills that people might be throwing in the street during a windstorm.  And that the worry that someone somewhere is just looking to blindly send you money to an address you never gave out as your own is totally overblown.

[Red Emerald]

I'm really looking forward to when this is in the mainline client.

[splatster]

I'm really looking forward to when this is in the mainline client.

Same here.

[piotr_n]

I'm really looking forward to when this is in the mainline client.

Same here.

Me too.
If you're concerned about less advanced users going crazy, just add a command line switch to enable the feature, please.
It will serve a good purpose.

[paraipan]

I'm really looking forward to when this is in the mainline client.

Same here.

Me too.
If you're concerned about less advanced users going crazy, just add a command line switch to enable the feature, please.
It will serve a good purpose.

+1

[BkkCoins]

I'd like to see sweep and import in the current client. "Sweep" for more typical uses like paper wallets and coupons etc. And "Import" so I can once again create vanity addresses and get them into my wallet easily.

Right now, due to encryption there seems to be no way to add a vanity address (is there?). I'd also be fine with a revert encryption option to turn it off so pywallet could once again be used to import, and then turn on encryption again. I personally don't mind using an "advanced" tool but I'm irritated that there is no way to import a vanity address now.

[paraipan]

....
Right now, due to encryption there seems to be no way to add a vanity address (is there?). I'd also be fine with a revert encryption option to turn it off so pywallet could once again be used to import, and then turn on encryption again. I personally don't mind using an "advanced" tool but I'm irritated that there is no way to import a vanity address now.

there is a way to import keys using pywallet... link

[casascius]

there is a way to import keys using pywallet... link

The biggest reason I want to see this in the client - at least as an RPC call - is that every bitcoin-accepting merchant will suddenly be able to accept typed private keys as payment.  A sweep RPC command will make implementing private key acceptance drop-dead simple for any site operator, since they'll just pipe the "Redeem Private Key" screen into a sweep RPC call, sweep the funds to a new address like they already generate for normal BTC transactions, and treat it like a normal incoming payment from elsewhere.

Average Joe will then be able to be a full citizen in the bitcoin economy using only paper wallets.  He can buy bitcoins at retail, and enter them at the marketplace or merchant of his choice like a gift card.  Pywallet isn't feasible for merchants to automate that on their website quite yet, since it can't add funds to a running instance of bitcoind.  Sweep will be a BIG deal for Bitcoin.

[netrin]

From a merchant's perspective is there any difference between these scenarios?:

1) customer sends bitcoin from a Green address; merchant can see the unconfirmed transaction in the aether.

2) customer gives private key to merchant who then sweeps and transfers coins and can see the unconfirmed transaction in the aether.

[BkkCoins]

....
Right now, due to encryption there seems to be no way to add a vanity address (is there?). I'd also be fine with a revert encryption option to turn it off so pywallet could once again be used to import, and then turn on encryption again. I personally don't mind using an "advanced" tool but I'm irritated that there is no way to import a vanity address now.

there is a way to import keys using pywallet... link

I asked about this on the pywallet thread to verify. Just because the wallet is unlocked for 10-15 minutes doesn't imply that pywallet can then access the wallet to import a key. No one answered or confirmed that this works. I don't think it will. Does unlocking the wallet actually re-write it to disk so that pywallet can use it? And if it does this is a security concern since an unencrypted wallet exists on disk even if briefly and potentially more so if the client crashed while the wallet was open. My assumption was that unlocking simply keeps the unencrypted wallet in memory or even just sets a flag that says it's ok to decrypt it as needed. I that case pywallet can not update the wallet.

It seems the only way now is to create a new wallet, import all your old keys (for me that includes previously created vanity keys) into it and then encrypt it again. And in that case I'd probably just leave the wallet unencrypted and use gpg manually (to encrypt it) as that gives me more flexibility.

I personally think that things like this should just be put on an advanced menu for advanced users and not have developers trying to protect the masses by dumbing down tools. Or, an rpc command is fine too. Advanced users can easily use that and novices will never do dumb things that way.

In the specific case of importing a new vanity address/key you are never worried about past transactions and rescanning the chain.

[DeathAndTaxes]

From a merchant's perspective is there any difference between these scenarios?:

1) customer sends bitcoin from a Green address; merchant can see the unconfirmed transaction in the aether.
2) customer gives private key to merchant who then sweeps and transfers coins and can see the unconfirmed transaction in the aether.

Private key shouldn't be considered green.  It should be considered unverified.

A dishonest customer could give you the private key and at the same time create a transaction using that private key to transfer funds to another address.  A variant on the classic double spend.  If his transaction gets into the block first then your transaction is nullified.  Alternatively is he is a bad miner/customer he could use Finney attack involving a private key.

The only private keys which should be considered "green" would be those in physical form protected by hologramic (or other countermeasure) where you both trust the integrity of the physical key AND the issuer.  If the issuer and counter measuers can be trusted then you can assume that nobody has seen the private key except you and there is no risk of a double spend.

[etotheipi]

This is a good discussion, and thanks for letting me know how I can add $500 income to my first release of Armory.  I hope that bounty is still valid   But I'm also interested to converge on a good way to "responsibly" implement these features...

Regardless of the Armory software itself, I have proven with the PyBtcEngine/ArmoryEngine that it's possible to scan the entire blockchain for a new address within a reasonable amount of time:

• If you're holding the entire blockchain in memory, the code can find all transactions in less than one second. 
• If it's not in memory, then I can load the blockchain from disk, index it, and scan for the address in less than 15s.

(the top-layer is Python, but I have a super-optimized C++ layer doing all the blockchain operations).

It might be possible to wrap the C++ engine and link it as a dll, purely for doing these types of scans.  It sidesteps a lot of the issues expressed in this thread (in the medium term, when it's still feasible to hold the entire blockchain), as you don't have to trust anyone more than you trust the blockchain itself in order to find and sweep funds for a given address/key. 

As for the Armory software itself, I already have the ability to import external private keys, and appropriate warnings have been displayed on the import dialog.  You can always add a new wallet just for importing untrusted private keys, though I recognize that it can still be dangerous for folks who don't quite understand the under-the-hood stuff.   The default behavior is to import the key as a permanent address in your wallet, but after reading this thread, I might make "sweeping" be the default behavior.  I might also move this feature to the "advanced" mode.  Recommendations are welcome.

[casascius]

• If it's not in memory, then I can load the blockchain from disk, index it, and scan for the address in less than 15s.

Somehow, I suspect that this scan will be highly dependent on the blockchain file not being fragmented on disk, or being on flash memory.  If overly fragmented, the hard drive simply may not be able to deliver the whole file in 15 seconds regardless of how well the code performs.

I think an index is desirable regardless, because at best, an optimized blockchain scan scales O(n) and an index scales O(log n)... as the block chain gets bigger, the index scan will be faster than the full scan by increasing orders of magnitude.

[etotheipi]

• If it's not in memory, then I can load the blockchain from disk, index it, and scan for the address in less than 15s.

Somehow, I suspect that this scan will be highly dependent on the blockchain file not being fragmented, or being on flash memory.

I think an index is desirable regardless, because at best, an optimized blockchain scan scales O(n) and an index scales O(log n)... as the block chain gets bigger, the index scan will be faster than the full scan by increasing orders of magnitude.

I don't disagree with you, and my goal for the first release of Armory is feature-based proof-of-concept, with no concern for how heavy the client is.  In the future, I will be converting to index-based approaches, as you suggested.  I actually already have a method for indexing all addresses, I just don't have it integrated as the "go-to" source of information for addresses.  That will be investigated for the next release.

But it doesn't change the fact that is still works right now, and even it's 30s-60s for a scan, it's a still "workable" as a client feature for users that want their money.  If someone wants to use the library in their own client for this purpose, I can help them get it integrated/linked.

[netrin]

Isn't a radix hash index O(1), or constant with respect to chain size? The performance look-up penalty is the number of instances of a single address, not the total number of addresses nor blocks.

[etotheipi]

Isn't a radix hash index O(1), or constant with respect to chain size? The performance look-up penalty is the number of instances of a single address, not the number of addresses.

It depends what kind of tree structure you're using.   If you keep a tree of every address as the key, and a list of block numbers as the values, then a trie/patricia tree will have constant access time (actually, a function of the length of the addresses).  But, it requires prefix searching and C++ doesn't have this kind of tree available in the STL.

So I have to settle for map<key,val> which is a binary tree ~ O(log(n)).  But in the grand scheme of things O(log(n)) is much "closer" to O(1) than O(n).  In this application, it's probably indistinguishable.

[DeathAndTaxes]

The default behavior is to import the key as a permanent address in your wallet, but after reading this thread, I might make "sweeping" be the default behavior.  I might also move this feature to the "advanced" mode.  Recommendations are welcome.

Yeah the way I see it there are three good choices.

Default IMPORT (option in menu to change to SWEEP).

Default SWEEP (option in menu to change to IMPORT).

Default prompt the user (w/ option "check to always xxxx").

I guess it really depends on what people are using it for.  I would recommend any wallet explain to the user what is happening (maybe w/ a help icon for more detailed info).

Something like (sweep version as summing no auto-sweep)

"You are about to sweep xxxx BTC from private key xxxxxx into your wallet.  This will not import the key.  If you receive funds at the address asssociated with this private key you will need to sweep the funds again. ( check box) no longer warn me about sweeping funds.   

[netrin]

"You are about to sweep xxxx BTC from private key xxxxxx into your wallet.  This will not import the key.  If you receive funds at the address asssociated with this private key you will need to sweep the funds again. ( check box) no longer warn me about sweeping funds.  

Why not the third option, where "SWEEP" means, "Import and immediately transfer coins"? I think "SWEEP" with second class keys is the worst of all worlds: confusing to newbies, disempowering to geeks, and complicated to maintain.

Thus with import implied, the only question is: "Do you want to transfer funds to a new trusted address?" Yes (recommended) or No (I know what I'm doing).

[etotheipi]

"You are about to sweep xxxx BTC from private key xxxxxx into your wallet.  This will not import the key.  If you receive funds at the address asssociated with this private key you will need to sweep the funds again. ( check box) no longer warn me about sweeping funds.  

Why not the third option, where "SWEEP" means, "Import and immediately transfer coins"? I think "SWEEP" with second class keys is the worst of all worlds: confusing to newbies, disempowering to geeks, and complicated to maintain.

Thus with import implied, the only question is: "Do you want to transfer funds to a new trusted address?" Yes (recommended) or No (I know what I'm doing).

My only concern with this is that it does leave open an attack vector for the person who gave you the key.  By importing that key into your wallet permanently, it's funds look like they belong 100% to you.  The person who gave you that key, can then send you money to that key to make you believe you received it, and then transfer the money back to themselves once the exchange is complete.

You could argue for an "auto-sweep" function/option, but I am not fond of any kind of automated transaction... anything that moves money when the user isn't looking, especially when it might require a tx fee, is asking for people to stop trusting your software.  Not to mention, I would have to create a new class of keys/wallets in my software to handle "kind of trusted" private keys, and it would confuse users who now have to understand this new class of information.

I prefer the option of sweep once, throw away the key.  If the user is importing an untrusted key to be used once, then they should only use it once to sweep, and not leave themselves open to such games as above.  Otherwise, it leaves the door open for not-even-so-creative attackers to plant a key in your wallet that they own, and then start pulling your funds out from under you when you use it for other transactions.  By throwing it away, we avoid the mess entirely.

[DeathAndTaxes]

My only concern with this is that it does leave open an attack vector for the person who gave you the key.  By importing that key into your wallet permanently, it's funds look like they belong 100% to you.  The person who gave you that key, can then send you money to that key to make you believe you received it, and then transfer the money back to themselves once the exchange is complete.

+1.  My thoughts exactly.  I don't really see the case where someone would want to import and sweep. Sweep is a mechanism used to secure funds from a compromised (or potentially compromised) key. If you can't guarantee the security of the key it shouldn't be imported.  If you can guarantee the security of the key why do you need to create an unnecessary transaction to sweep the value to another equally secure key in the same wallet?

It is a good idea for everyone to get into the mindset that things we don't trust completely don't belong in the wallet.  Period.

IMPORT = FULL TRUST
Example you generated an vanity address and want to integrate it into an existing wallet.  No need to transfer funds (if any) as you implicitly trust this key. Import is essentially saying "Yes I am absolutely sure there is no chance this key has been compromised and I am confident risking future coins into perpetuity with that assertion."

SWEEP = UNTRUSTED.
Example would be someone gives you a funded private key.  It has value right now but it might not in the future.  Sweeping ensures the transaction can't be reversed but the same risk that necessitated the "sweep" remains, thus the key can NEVER be trusted. There is no reason to risk future attack by integrating a compromised (even potentially compromised) key into your wallet.    Sweep is essentially saying "Hell no I don't trust this key I have no idea where it has been.  Still I would like those coins please."

While there may be edge cases I think they are rare and not worth the confusion it would create.  Two cases is already potentially confusing.  The SWEEP vs IMPORT having a clear line helps to reinforce the broader concept that your wallet (and keys inside it) should remain private and secure.  You shouldn't put insecure stuff in there and if you feel your wallet is compromised you should stop using those keys.  The risk isn't just in the here and now but all future value in those keys into perpetuity.

[netrin]

Why not the third option, where "SWEEP" means, "Import and immediately transfer coins"? I think "SWEEP" with second class keys is the worst of all worlds: confusing to newbies, disempowering to geeks, and complicated to maintain.

Thus with import implied, the only question is: "Do you want to transfer funds to a new trusted address?" Yes (recommended) or No (I know what I'm doing).

My only concern with this is that it does leave open an attack vector for the person who gave you the key.  By importing that key into your wallet permanently, it's funds look like they belong 100% to you.  The person who gave you that key, can then send you money to that key to make you believe you received it, and then transfer the money back to themselves once the exchange is complete.

Then that can and must be handled at the user interface level. Not twisting up the data model.

Flag the address in the wallet as untrusted/imported and mark it with skull and cross bones in the GUI or: "100 BTC (20 untrusted)" in the HIGHLY UNLIKELY case of this occurring. You could also perpetually import coins sent to imported addresses to new addresses, but second class keys in the data model is a backassward design.

You could argue for an "auto-sweep" function/option, but I am not fond of any kind of automated transaction... anything that moves money when the user isn't looking, especially when it might require a tx fee, is asking for people to stop trusting your software.

It can and should be optional, recommended or not. It is far worse to have strange behavior ALWAYS, rather than strange behavior in the unlikely and potential malicious case of someone planting a trojan-address in your wallet.

Not to mention, I would have to create a new class of keys/wallets in my software to handle "kind of trusted" private keys, and it would confuse users who now have to understand this new class of information.

How is this 'new class' of flagged key different from your 'second class' swept key?

I prefer the option of sweep once, throw away the key.

That's draconian and at best it could be optional though I am sure no one would elect to throw a key away. Why should anyone ever throw a key away? On this point Satoshi would agree with me.

[DeathAndTaxes]

That's draconian and at best it could be optional though I am sure no one would elect to throw a key away. Why should anyone ever throw a key away? On this point Satoshi would agree with me.

I sure as hell would (see post above).  

You either trust a private key or you don't.  By trust I mean you are 100% absolutely certain that nobody else on this planet has ever seen the private key.

If you trust a key why do you need to sweep it?
If you don't trust a key why are you putting something you don't trust in your wallet?

[etotheipi]

How is this 'new class' of flagged key different from your 'second class' swept key?

I prefer the option of sweep once, throw away the key.

That's draconian and at best it could be optional though I am sure no one would elect to throw a key away. Why should anyone ever throw a key away? On this point Satoshi would agree with me.

Netrin, I sympathize with your arguments, but I can't concede to them.  As an application developer where I will be implicitly responsible the for well-being of a lot of peoples' money, I just simply cannot do it.  It's not to say that it shouldn't ever be done: maybe another developer would have the patience and creativity to design such a system and add more value than risk, but that's not me.  When something goes wrong, my fault or the users', I'll still be dealing with it.  And I will deal with it by putting in the 90% solution as we just discussed... so far I haven't been compelled by this discussion otherwise.

But it's not a lost cause for the argument you made.  Yes, throwing away the key is strange.  The default for "sweep" will be to for them to put in the private key, the client sweeps it, and then it's never seen again.    But that's not really the end of the story... the user still has the private key.   If they disagree with the fact that they don't have the option to sweep and import... then just run the dialog again and make it a permanent part of your wallet.  Done.   

So my client effectively "supports" that option and advanced/smart users who want this behavior can get it.  I just refuse to directly support/encourage it, because as has been described above, it opens up much more risk to the user than the value it adds.

[netrin]

That's draconian and at best it could be optional though I am sure no one would elect to throw a key away. Why should anyone ever throw a key away? On this point Satoshi would agree with me.

I sure as hell would (see post above).

Look either you trust a key or you don't.  By trust I mean you are 100% absolutely certain that nobody else on this planet has seen the private key but you.

If you trust a key why do you need to sweep it?
If you don't trust a key why are you putting something you don't trust in your wallet?


A import and sweep is essentially saying I don't trust the key (think if I don't sweep funds might be taken/reversed) BUT I would like to trust this key for future funds.

I misunderstood your position before your re-edit (EDIT: and Etotheipi's re-clarification). I suppose sweep and purge is at least consistent with respect to the data model. As is pure import.

Call me a pack-rat then, I abhor the idea of throwing a published address into the aether. But, my use cases are admittedly obscure. If I want to keep an untrusted key, I could just import it into a untrusted wallet. Everyone is happy. OK, I'm on board for exclusively both IMPORT and SWEEP (and forget).

[btc_artist]

For private keys that are known to be secure, I want the option to import them as first-class citizens in my wallet (think a securely-generated vanity address I want to be using).  For private keys given to me by someone else, I want to transfer the funds to a new key in my wallet, but I want to keep a list of those private keys that have been transferred from, so that if any more funds ever shows up in any of them, I can also transfer those funds to my wallet.

I think part of the inherent problem is that the Satoshi client shows transactions and your total balance. This is fundamentally wrong. It should show all your key pairs and the funds that are in each. When you send a payment, you choose one or more keys to send the funds from. If it was done this way, each key/address pair could be marked as generated in the client or imported.

If I have a bunch of USD in my wallet in my pants, the actual physical selection of bills I have is important to some degree. What if I want to tip someone with a small bill? What if I need to make a small purchase where large bills are not accepted? What if one of the bills might be counterfeit and worthless? All of this is important information and if shown in the client, mitigates many of the problems of how to deal with imported/swept private keys.

[paraipan]

yep agree with DeathAndTaxes, maybe we should think that any priv key is more like a prepaid card. The company or vendor that made the card know the priv code and you only have to scratch the protecting film to redeem the value.
In theory you could save the card in case they send any amount of value in the future but we know that isn't the reality. Every time i refill my mobile credit, that card is trashed or guarded few days just in case. Same thing could be done with "untrusted" priv keys, save them in a separate cache file that you can purge regularly.

[netrin]

For private keys given to me by someone else, I want to transfer the funds to a new key in my wallet, but I want to keep a list of those private keys that have been transferred from, so that if any more funds ever shows up in any of them, I can also transfer those funds to my wallet.

I think part of the inherent problem is that the Satoshi client shows transactions and your total balance. This is fundamentally wrong. It should show all your key pairs and the funds that are in each.

This is my way of thinking as well. But we must admit that we are not the typical user. I have little understanding of the average user's mental model (of any technology, whether email or electricity) and I imagine they have none at all but it is hopeless to try to educate them at this phase. Shouldn't the 'coin control' patch give you what you want?

I'm actually pretty cool with the idea of a 'trusted wallet' and an 'untrusted wallet'. I would like a service that does pull/sweep untrusted keys periodically. In fact, I'd like a service that randomly scrambles all of my coins while I am sleeping. These features are possible but perhaps none of them are on topic with respect to 'sweep/import private keys'.

[btc_artist]

Call me a pack-rat then, I abhor the idea of throwing a published address into the aether. But, my use cases are admittedly obscure. If I want to keep an untrusted key, I could just import it into a untrusted wallet. Everyone is happy. OK, I'm on board for exclusively both IMPORT and SWEEP (and forget).

I agree mostly.  Why not have:

1. IMPORT and keep the key as a first-class citizen in your wallet.
2. SWEEP key and TRANSFER any funds to your wallet (or another arbitrary address). There would be a separate interface (completely independent from the wallet) in the program showing a list of all keys that have been swept, and showing any balance in each of them. This would not be included in the wallets balance, unless you SWEEP them again.

[DeathAndTaxes]

I think part of the inherent problem is that the Satoshi client shows transactions and your total balance. This is fundamentally wrong. It should show all your key pairs and the funds that are in each. When you send a payment, you choose one or more keys to send the funds from. If it was done this way, each key/address pair could be marked as generated in the client or imported.

If I have a bunch of USD in my wallet in my pants, the actual physical selection of bills I have is important to some degree. What if I want to tip someone with a small bill? What if I need to make a small purchase where large bills are not accepted? What if one of the bills might be counterfeit and worthless? All of this is important information and if shown in the client, mitigates many of the problems of how to deal with imported/swept private keys.

Well "bills" are an incomplete abstraction of wealth.  They only come in certain sizes, you need to deal w/ counterfeits, you can accidentally give the wrong one, you can make mistakes when making change, etc.

None of those concerns are relevent w/ Bitcoin.  For 99% of users the per address value of their wealth distribution isn't material.  They only want to know three things
1) how much wealth do I have?
2) did that transaction clear?
3) are my funds safe?

The abstraction of addresses into a wallet was intentional and good IMHO.  There may be isolated cases where knowing you have 1.28928392729873894 BTC in address a, 0.1827789347389 BTC in address b ...  (hundreds if not more addresses later) .... etc  is valuable but for most people it is just noise.  It doesn't answer the three questions above.

[DeathAndTaxes]

I agree mostly.  Why not have:

1. IMPORT and keep the key as a first-class citizen in your wallet.
2. SWEEP key and TRANSFER any funds to your wallet (or another arbitrary address). There would be a separate interface (completely independent from the wallet) in the program showing a list of all keys that have been swept, and showing any balance in each of them. This would not be included in the wallets balance, unless you SWEEP them again.

I would have problem with that but it seems excessive.  I mean it would be like when I use a prepaid card for a cellphone my phone showing my current balance, transactions, and expiration and then having a separate section which shows me all the prepaid codes and their current value ($0.00).

Can you think of any instance where you would receive an insecure funded private key and you anticipate someone sending you funds there in the future? Why? Why not just use a new "disposable" funded private key? 

I really think most users have no reason to look at a list of spent 0 BTC insecure private keys anymore than they keep track of spent giftcard or phone cards.

[btc_artist]

The abstraction of addresses into a wallet was intentional and good IMHO.  There may be isolated cases where knowing you have 1.28928392729873894 BTC in address a, 0.1827789347389 BTC in address b ...  (hundreds if not more addresses later) .... etc  is valuable but for most people it is just noise.  It doesn't answer the three questions above.

The abstraction was definitely intentional, but I'm not sure it was good. It works well for casual users (the majority), but for one has fundamental privacy concerns.  So for some (most?) it would be noise, and for others it would be essential.  I don't see the problem with having the funds to address breakdown in an advanced tab that casual users can ignore. 

I agree mostly.  Why not have:

1. IMPORT and keep the key as a first-class citizen in your wallet.
2. SWEEP key and TRANSFER any funds to your wallet (or another arbitrary address). There would be a separate interface (completely independent from the wallet) in the program showing a list of all keys that have been swept, and showing any balance in each of them. This would not be included in the wallets balance, unless you SWEEP them again.

I would have problem with that but it seems excessive.  I mean it would be like when I use a prepaid card for a cellphone my phone showing my current balance, transactions, and expiration and then having a separate section which shows me all the prepaid codes and their current value ($0.00).

Can you think of any instance where you would receive an insecure funded private key and you anticipate someone sending you funds there in the future? Why? Why not just use a new "disposable" funded private key? 

I really think most users have no reason to look at a list of spent 0 BTC insecure private keys anymore than they keep track of spent giftcard or phone cards.

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?

[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?

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

[paraipan]

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.

yeah lots of great features and improvements left alone for the supposedly ultimate feature... p2sh (multi redeem) or what it's name is

we need sweep now, fast initial blockchain download and lots more. I'm really disappointed atm 

[Gavin Andresen]

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.

Huh?  GIT HEAD bitcoind supports import private key functionality:

Code:

importprivkey <bitcoinprivkey> {label}

Whether or not that's ever supported by the GUI is a different issue, and there I think we SHOULD be more concerned about people using the GUI shooting themselves in their feet.

[Gavin Andresen]

yeah lots of great features and improvements left alone for the supposedly ultimate feature... p2sh (multi redeem) or what it's name is

we need sweep now, fast initial blockchain download and lots more. I'm really disappointed atm 

I've been very clear about my top development priorities:

1. Network stability: DoS threats, scaling-up issues, etc.
2. Wallet security/backup.

I see everything else as lower priority; I want users to be confident that their bitcoins can't get stolen even if they slip up and open an attachment in Outlook that the aughtn't have opened before I want a downloads-the-entire-blockchain-in-10-seconds client with all sorts of other bells and whistles.

[etotheipi]

Armory is just about ready for alpha, I just need a few more folks to help test.  All core features I envisioned for the first release are there -- including the sweep/import functionality, as discussed earlier in this thread.  It is available only in "Advanced" and "Developer" usermodes.  Standard users will not be able to import or sweep (though sweeping might be okay, but I haven't separated the dialogs yet).

Pursuant to Gavin's warnings, Armory really only works once the Satoshi client is sync'd with the network, so that particular warning is not relevant to Armory.  The other thing is, Armory does a full scan of the blockchain for the new key, immediately.  It takes less than a second to do a full scan since it's full-RAM.  Even when I do HDD-based blockchain, the scan is about 20s (which is completely reasonable).  It will display the transactions on the wallet ledger by blockheader time.  You can examine the ledger for the individual address by double-clicking it in the wallet-properties/address-list dialog.

Yes, there could be some confusion if a user imports a key already in their satoshi wallet.    This is one reason I am not encouraging Satoshi->Armory wallet conversions (and have not supplied any function for doing it).  I would really prefer users only import new keys.  Similarly, Armory provides a warning if the key you are importing is already in one of your other wallets.  It makes sure that you have the ability to shoot yourself in the foot if you want to, but help you avoid it if that wasn't your intention.

Most importantly, everything is well-described in Armory.  Short descriptions on screen, mouse-over tooltips and additional popups to explain what you are doing. All based on the discussions in this thread.  So thanks!  

Please help test it!  https://bitcointalk.org/index.php?topic=56424 . Hell, just use it!  If you want to manage masses of imported keys, there is no better way than using Armory, just be aware of the risks mentioned throughout this thread.  Even if you don't want to use it as your main client, you can use it simply for sweeping (it will sweep into your Armory wallet, but you can send it to your Satoshi wallet as soon as it gets 1 confirmation).

[etotheipi]

P.S. - What's the chance that Casascius would payout some of his bounty for Armory's import&sweep feature?   I recognize Armory isn't a 100% solution until I bring down the memory requirements, but there's no doubt that I created a client with the functionality, fully tested and easy-to-use.   Hell, I even implemented mini-private key format in the dialog, just so that physical bitcoins can be redeemed!  (that was his motivation for the bounty, wasn't it?)

[casascius]

P.S. - What's the chance that Casascius would payout some of his bounty for Armory's import&sweep feature?   I recognize Armory isn't a 100% solution until I bring down the memory requirements, but there's no doubt that I created a client with the functionality, fully tested and easy-to-use.   Hell, I even implemented mini-private key format in the dialog, just so that physical bitcoins can be redeemed!  (that was his motivation for the bounty, wasn't it?)

Very damn good to say the least.  Please accept an immediate 10BTC silver round from me for your efforts thus far.  I will PM you a coupon code.

[nelisky]

Huh?  GIT HEAD bitcoind supports import private key functionality:

Code:

importprivkey <bitcoinprivkey> {label}

This being present on the GUI is of absolutely no importance to me... I had noticed this in HEAD, but I never checked if the official release has this through RPC or not.

But is it in to stay Gavin? I may finally move my web help libs to use a non patched client

[casascius]

Huh?  GIT HEAD bitcoind supports import private key functionality:

Code:

importprivkey <bitcoinprivkey> {label}

This being present on the GUI is of absolutely no importance to me... I had noticed this in HEAD, but I never checked if the official release has this through RPC or not.

But is it in to stay Gavin? I may finally move my web help libs to use a non patched client

Possibly importantly, how long does this function take to run.  If it requires a complete scan of the block chain, the request will take quite a few minutes to run.  I've been suggesting for quite a while there needs to be the option of an index built on bitcoin address as a key field, so the import/sweep can be done in O(log n) time with respect to the size of block chain rather than O(n).

[paraipan]

yeah lots of great features and improvements left alone for the supposedly ultimate feature... p2sh (multi redeem) or what it's name is

we need sweep now, fast initial blockchain download and lots more. I'm really disappointed atm  

I've been very clear about my top development priorities:

1. Network stability: DoS threats, scaling-up issues, etc.
2. Wallet security/backup.

I see everything else as lower priority; I want users to be confident that their bitcoins can't get stolen even if they slip up and open an attachment in Outlook that the aughtn't have opened before I want a downloads-the-entire-blockchain-in-10-seconds client with all sorts of other bells and whistles.

got that, only thing is people want GUI features, they are actually begging to be implemented, so please try listening them for a moment. I see the protocol and the network as a whole pretty stable and redundant, the scaling could have some issues but not much of a problem given that you're a great coder and have a team that helps you allot. I've still got to see the 4mb/year blockchain proposed by Satoshi in his paper. Imagine the surprise when i downloaded it for the first time, ~750mb

Most of us are superficial, i learned that pretty fast, but i think you already know it. Try let them feel good with the project and collaborate in the base client or else you will see others take advantage pretty fast and that could be a real problem. It doesn't cost you nothing, the people get their "bells and whistles" and you get to follow your project agenda allot more easier not having to worry for people migrating to other clients for that reason.

If you strangle the project you don't win nothing exactly the opposite, you lose control. I want "bells and whistles" too and don't want to use some extra client to have that. People propose you things every day and i've seen nice pull requests sum up on git for months without being merged. The only reason i keep being around is that bitcoin is backed by the people and them using it, so if you manage to scatter the "pack" bitcoin would be valueless. You don't want that, right ?

We can easily have all the features we want with all the coders lining up with their contributions, so please don't be "nanny" for us and let the experiment go forward. Let them shot in their foots if that is what it takes to learn when they have to pull the trigger. Put all the warnings you need, disclaimers and such and let them "pimp it", while not touching the protocol.

Sorry for being such harsh but is the f...ng truth. I will be around.

[casascius]

P.S. - What's the chance that Casascius would payout some of his bounty for Armory's import&sweep feature?   I recognize Armory isn't a 100% solution until I bring down the memory requirements, but there's no doubt that I created a client with the functionality, fully tested and easy-to-use.   Hell, I even implemented mini-private key format in the dialog, just so that physical bitcoins can be redeemed!  (that was his motivation for the bounty, wasn't it?)

Just for the record, my motivation for seeing private key sweep in the Satoshi client is not in support of physical bitcoins - it's support for how I view Bitcoin should be used by average computer-illiterate joes.  The whole physical bitcoin project is intended as a promotion of bitcoin and a methodology for using it - part of why you see me trying to give the whole business away and enable people to compete with me.

Supporting private key sweep in the Satoshi client will make it very easy for websites to accept private keys as payment, ultimately in the hope that someone can buy Bitcoins at retail and use them directly at a merchant like a gift card, bypassing need for wallets and clients entirely.

[etotheipi]

I mostly agree with paraipan.  I really believe that the Satoshi client should be expanding in both directions.  I think Bitcoin's adoption is going to suffer if security-related upgrades are 100% priority for the next X years.  I really think there needs to be "visible" progress, too:  eye-candy, new core features, more options/customizability, etc.  Without it, the project starts to look stale.  Bitcoin-Qt was a nice change, but it didn't introduce any new features.  Users have no reason to get excited about new releases.

I am not suggesting that what you are doing is in any way, not important.  I believe what you're doing is critical, and I'm so glad someone is doing it.  But most other (potential) users are very shallow, and get bored easily.  I strongly believe that at least a little effort should be spent paying attention to feel-good upgrades that all users can use.  I can say that because I agree with paraipan that the network has been around for a while, and in the short-term these security issues will not make or break the network.  But wider user adoption will most definitely make the network, and I believe that the development effort should be well-rounded in this regard.

Armory was my response to seeing this over the last year.  I desperately wanted these features, I know other users desperately wanted these features, and I was in a perfect position to do it.  While I surely enjoy the attention that my monopoly on these features will get me, I'm hoping that the competition will inspire the core Bitcoin devs to try to expand the features of the Satoshi client -- all new users are going to end up at bitcoin.org, not the "Alternative Clients" sub-forum of bitcointalk.org.  

It might be a different story, if the satoshi client was tailored more as as a rock-solid backend for third-party software to leverage (like Armory is doing right now), and focus bitcoin.org on promoting other projects that provide the variety of functionality that users want (Armory, Electrum, Bitcoinj, Intersango, android/iphone apps, etc).   But right now, the Satoshi client alone represents "Bitcoin," and thus I think it needs broader range of development efforts.

[Stardust]

Huh?  GIT HEAD bitcoind supports import private key functionality:

Code:

importprivkey <bitcoinprivkey> {label}

I should have checked that before talking, my apologies.

Whether or not that's ever supported by the GUI is a different issue, and there I think we SHOULD be more concerned about people using the GUI shooting themselves in their feet.

I agree.

[sadpandatech]

P.S. - What's the chance that Casascius would payout some of his bounty for Armory's import&sweep feature?   I recognize Armory isn't a 100% solution until I bring down the memory requirements, but there's no doubt that I created a client with the functionality, fully tested and easy-to-use.   Hell, I even implemented mini-private key format in the dialog, just so that physical bitcoins can be redeemed!  (that was his motivation for the bounty, wasn't it?)

Very damn good to say the least.  Please accept an immediate 10BTC silver round from me for your efforts thus far.  I will PM you a coupon code.

Quoting this for epicness!  Good looking out, Casascius. And nice work on Armory, Etotheipi!

[etotheipi]

I want to brag that not only did I just release Armory Alpha, but I bought a few Casascius bitcoins (because they're cool), and just peeled off one of the holograms on a 1 BTC coin and swept it using Armory.  It works!  I guess it would've been a good idea to take a screenshot... d'oh!

Also, the 10 BTC rounds are damned sexy.  They're expensive (20 BTC for a 10 BTC coin), but they're also an ounce of solid silver, and come in a nice jewelry box with protective case.  Even if BTC crashes, it's about $35 worth of silver (like a dual investment!)

[dooglus]

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.

Huh?  GIT HEAD bitcoind supports import private key functionality:

Code:

importprivkey <bitcoinprivkey> {label}

I just took a look, and it turns out there are 6 new RPC commands in the GIT HEAD:

Code:

addmultisigaddress <nrequired> <'["key","key"]'> [account]
dumpprivkey <bitcoinaddress>
getblock <hash>
getblockhash <index>
getmininginfo
importprivkey <bitcoinprivkey> [label]

Just FYI.