Sweep/import private key feature request

[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

[1714175300]

1714175300

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