Proposed RPC command: sweepprivkey

[casascius]

I have submitted a proposal for a new RPC command called sweepprivkey (sweep funds from a private key).  It can be found at https://en.bitcoin.it/wiki/Sweepprivkey.
 
This function is useful for merchants who wish to accept typed or scanned Bitcoin private keys as payments, without imposing any specific methodology on how the payments must be processed. sweepprivkey has no direct effect on anything in the local wallet or transaction history -- the function simply generates a transaction in real-time to sweep the funds to another address, and broadcasts it. That destination address may or may not be in the local wallet.
 
The local wallet is only affected if the destination address is in the wallet, and only in an indirect sense: the wallet reacts to the sudden presence of a new transaction referencing it, just the same as if that transaction had been received from a peer.

It is my understanding that similar functionality has been implemented into bitcoinj.

[1714037983]

1714037983

[Andrew Vorobyov]

Thumbs up!

[Gavin Andresen]

Encouraging people to expose their private keys makes me nervous. They're "private" for a reason, and it seems to me the vast majority of private keys will, a few years from now, either be stored on a secure device which is designed to never reveal them or will be split.

Why would a merchant "wish to accept typed or scanned Bitcoin private keys as payment" ? They're going to generate a transaction immediately anyway, it seems to me making a payment that way just opens up more potential ways of getting defrauded (e.g. merchant keeps the private key in case more bitcoins are ever sent to the same address, or merchant sends change to the same address and then a few days later uses the private key to take back the change).

I don't see any privacy or transaction-fee-saving advantages, either; am I missing something?

(I do see the usefulness of importing private keys into your wallet, that's a different feature that I'd like to be in the next release).

[casascius]

The usefulness is that Joe Sixpack, who is part of the "unbanked" population, can go to a check cashing place, and receive bitcoins for cash on what amounts to a special gift card where he can go and do all kinds of wonderful things on websites that, um, cannot accept Visa and Mastercard for whatever reason.  And he can do it right now - not after his Dwolla clears, not after his wire goes through, not after his blockchain finishes downloading.

He doesn't care or understand blockchains or crypto and isn't downloading the client, can't afford a smartphone (bad credit - prepaid is his only option) and wouldn't ever wire money to MtGox, rather he just wants to have some fun with his habit of choice.  These are throwaway, single use codes.  No different than a GreenDot MoneyPak... he who knows the code and spends it first gets the funds.

Ultimately, the goal is to widen the audience of people who CAN use Bitcoin to do something they already want to do, rather than limiting it to being a way that computer-savvy experts can send funds to other computer-savvy experts.

There are a lot of Joes out there, and if Joes understood that they could get magic gift cards at any check cashing places, I feel those places would be lining up to make a few percent on reselling our bitcoins to Joes.

[willphase]

would prefer a way to just import/export signed transactions via the RPC interface, then the sweepprivkey command could just be offloaded to a separate application.

Will

[dogisland]

I have submitted a proposal for a new RPC command called sweepprivkey (sweep funds from a private key).  It can be found at https://en.bitcoin.it/wiki/Sweepprivkey.

I faced this problem when implementing StrongCoin.com.

I haven't figured out how to sign transactions in the client yet, so I'm having to send the private key to bitcoind.

I'm using the patched bitcoind for key import. With the following commands I can simulate a sweepprivkey

1. importprivkey
2. sendmany
3. removeprivkey

Each payment takes about a minute to process.

Moving forward I can see more use cases for people who want to interact with Bitcoin as an API but don't want it to store the private keys.

My understanding is that the only time a private key is needed is when a payment is made. To make it easy to sign payments on the client side it would be nice to have the following in bitcoin.

1. getinfoforpayment - retrieve everything from the block chain required for a payment. You specify the destination addresses and the source address.

The client application then signs the information.

2. sendrawtransaction - bitcoin pushes the transaction out onto the network.

[error]

Why would a merchant "wish to accept typed or scanned Bitcoin private keys as payment" ? They're going to generate a transaction immediately anyway, it seems to me making a payment that way just opens up more potential ways of getting defrauded (e.g. merchant keeps the private key in case more bitcoins are ever sent to the same address, or merchant sends change to the same address and then a few days later uses the private key to take back the change).

I think the point is for the merchant (or someone else) to be able to cash out and immediately invalidate a BitBill or any other physical token which contains a Bitcoin private key.

[casascius]

1. getinfoforpayment - retrieve everything from the block chain required for a payment. You specify the destination addresses and the source address.

The client application then signs the information.

2. sendrawtransaction - bitcoin pushes the transaction out onto the network.

I strongly agree with this.

for #1, I'd be looking for: getunspenttransactions <listofaddresses> [<minconfirms>] [<detaillevel>]

Where the client returns all the unspent transactions belonging to any of the addresses in the list anywhere on the block chain, including txid+index, the block number (if confirmed), and a flag saying whether to report just the value of the output, or an encoded version of the entire transaction (so the client can confirm the txid is really worth the claimed value).

Such a feature would depend on the maintenance of an index not present in the software.  It's an index that would tie bitcoin address references to the blocks that reference them, and would only be used by some users, wouldn't be worth the resource cost on the rest who didn't need it, and ought to be an option (e.g. built on first use).

[Steve]

I think as far as exposing private keys, that cat is already out of the bag regardless of whether such an RPC command exists or not (we have casascius coins and bitbills that are already handling private keys).

I had discussions last week along these lines with TTBit at our Orlando meetup.  He brought some bills he printed that included the private key.  I actually think there are some compelling use cases for this in addition to the one casascius mentioned (side note, TTBit was kind enough to sell me a handful of casascius coins...very nice!).

Imagine this scenario...you want to go out for dinner and drinks and you want to pay with bitcoins, but you don't want to fumble with the smartphone (or you don't have one, or data access is cost prohibitive, or you want to make sure you don't go crazy and spend all your bitcoins).  You could print up 10 bills of say 1 BTC each.  Each bill would have a scannable public/private key.  To pay for things, you give these to the restaurant and they either:

- sweep all funds and send change to another "change" address you also printed on the bill
- sweep all funds and print you a new bill for the amount of the change (with a new unique public/private key pair)
- leave the change on the bill for you to use again

If you lose one of these bills, you only lose the amount stored on the bill (and maybe not even that if you kept the keys and can later spend the funds before anyone else does).  You could even take it a step further and encrypt the keys with a pin code that you would have to give the recipient (or type into a key pad) in order to decrypt the keys.

The key difference here is that at the point of the transaction, only the recipient needs software and an internet connection to complete the transaction.  You do have to trust the merchant, but that's not so different from the situation today when you give them a $20 bill and expect them to return with change or you trust that they won't steal your CC number, etc.  I still like the idea of a trusted, personal hardware device, but in the short term, this low tech solution could prove quite useful.

[casascius]

You could print up 10 bills of say 1 BTC each.  Each bill would have a scannable public/private key.  To pay for things, you give these to the restaurant and they either:

I fully agree with that.  I have given out bitcoins this way.  And I also keep virtually all of my bitcoins this way (broken down into convenient increments so they can be re-imported like "bills").

I recently got a QR code "gun" keyboard wedge scanner, and am kicking myself that I didn't put QR codes on my paper wallets.  Another batch I guess.

[TTBit]

Steve: Just saw this post. Nice meeting with you.

I'm a little out of place in the development area; please excuse.

The issues I see with exposing private keys are:
a) the client may assign change to that address at any time if in wallet.dat
b) a new bitcoin user may expose his private key for his public payment address, which he receives a stream of payments.

If all semi-private keys meant to be 'published/printed' started with a certain prefix (i.e '1BTC' or '2'), the client would never send change to those addresses. When a new user creates a new address, he could select 'for deposit only' if it were his billing address.

In general, I see value in exchanging private keys in print for payment.

edit: easier to get funds out of 'savings' addresses that only exist on paper/your head.

[casascius]

I am pretty sure the client only sends change to addresses pulled in from the 'reserve' pool, not imported keys.

[Pieter Wuille]

I am pretty sure the client only sends change to addresses pulled in from the 'reserve' pool, not imported keys.

Correct, though the "importwallet" command has a function to import a key into the reserve pool.

[mndrix]

If a user wants to fund an online wallet, buying a private key (mini or otherwise) from a trusted vendor in the physical world and typing it into any online wallet service would be very convenient.  This is possible without API support, but having API support makes it easier for services to support these kinds of Bitcoin "gift cards".

[casascius]

If a POS program offered a "sweep" screen - which in turn called sweepprivkey -  that's all a business would need to conveniently accept bitcoins along with a 2d keyboard-wedge barcode scanner.

Such a screen would instantly validate and sweep funds from a scanned private key, as well as provide instant feedback as to the value of a bill as well as validity.

People could print their own money - which sounds scary - up until the point of realization that it's only valid once verified.

[Red Emerald]

I really like this idea.  Good work