Forget Paper Wallets - Paper transactions?

[Richy_T]

So you create a paper wallet. On the way to the bank, a super-government-spy-satellite reads your code. Or your bank's security is compromised or you just get lazy and leave the paper wallet on your desk and you have a break-in and it gets stolen. All your precious bitcoins are now gone.

So how about instead of creating a wallet, you create a transaction which can later be put onto the blockchain and will send the coins to a specific Bitcoin address? The transaction is signed so cannot be altered or redirected to another address. You don't have to worry about the security of your bitcoins so much because any potential thief not only has to compromise the security of your bitcoin storage but also of your target wallet (which could be a paper wallet, of course). I'd imagine the process something like this...


Store
1) Software generates wallet. RAM only if possible. Displays public address.
2) You send funds to public address.
3) Software generates transaction for sending funds to your target public address, does all necessary signing, converts to QR code (or whatever your preference is) and saves/prints/whatever.
4) Software wipes & deletes wallet

Redeem
1) Scan/convert QR code.
2) Paste here http://blockchain.info/pushtx .
3) Wait for confirmations.

Thoughts? Has this been done before?

[1715696156]

1715696156

[1715696156]

1715696156

[1715696156]

1715696156

[mgio]

It's an interesting idea.

Basically you now need two pieces of information to recover your coins. The transaction and the new wallet's keys. I see it as another thing to misplace making your money as good as stolen.

I prefer to just use a wallet stored on a USB drive with a very secure password (like 16 characters or more). It's easier to make backups that way too so you won't have a single point of failure.

[Richy_T]

It's an interesting idea.

Basically you now need two pieces of information to recover your coins. The transaction and the new wallet's keys. I see it as another thing to misplace making your money as good as stolen.

I prefer to just use a wallet stored on a USB drive with a very secure password (like 16 characters or more). It's easier to make backups that way too so you won't have a single point of failure.

The target wallet could be just your regular wallet as well. The point is there would be no way for anyone to siphon off your funds into their own wallet.

[timeofmind]

The person who stole your wallet would do that transaction before you managed to submit yours, so your transaction would effectively be a double-spend and be rejected by the network.... or am I missing something?

[timeofmind]

The person who stole your wallet would do that transaction before you managed to submit yours, so your transaction would effectively be a double-spend and be rejected by the network.... or am I missing something?

Ah. sorry. I get it. You don't store your wallet at all. ok.

[timeofmind]

The person who stole your wallet would do that transaction before you managed to submit yours, so your transaction would effectively be a double-spend and be rejected by the network.... or am I missing something?

Ah. sorry. I get it. You don't store your wallet at all. ok.

So someone would need to steal both your target wallet and the transaction.

[bg002h]

So do you mean to have a signed, valid, but not transmitted emergency transaction sending all of your funds to a new address not in your wallet (For which you have a private key stored elsewhere)?

This would set up a race condition where whoever gets their transaction into a block first wins.  Since change addresses are precomputed and stored in the wallet, you would need to create an address outside of your wallet carefully.

Alternatively, what if they stole the target address private key? Then you would have no way to spend your funds safely.

The Bitcoin protocol does have a method of sending funds to an IP address and the computer at the IP address will supply the recipient address... So, in theory, the private/public key pair of the destination address need not be created yet.

You could register an account with a large mining pool (who could get your send to IP address transaction in a block quickly) to create the recipient address and store the private key for you and handover the funds when the incoming coins from the addresses you had told them they would come from arrived.

[K1773R]

Good idea Richy!

Suggestion: send the coins to a new temporary Address, wait for 6 confirmations, now create a tx for an address you want the coins go to and save it (or create QR code, saving is better). Why? Since the "actual location" of the coins would be a temporary address which is imported nowhere, not even having the users wallet.dat would help. if someone would have the privkeys he could still steal your BTC as your TX would be a double spend (thats why the thing with the temporary address). Nobody knows the privkey of the temporary address so the bitcoins are "lost" until you publish your signed raw TX

how about this?

[timeofmind]

Alternatively, what if they stole the target address private key? Then you would have no way to spend your funds safely.

You could keep many copies of the private key. When you submit the transaction, you also quickly move the money from your target address quickly before the thief manages to spend it.

Basically, this makes your money half as likely to be stolen, and twice as likely to be lost accidentally...

[Richy_T]

Good idea Richy!

Suggestion: send the coins to a new temporary Address, wait for 6 confirmations, now create a tx for an address you want the coins go to and save it (or create QR code, saving is better). Why? Since the "actual location" of the coins would be a temporary address which is imported nowhere, not even having the users wallet.dat would help. if someone would have the privkeys he could still steal your BTC as your TX would be a double spend (thats why the thing with the temporary address). Nobody knows the privkey of the temporary address so the bitcoins are "lost" until you publish your signed raw TX

how about this?

Yes, I think that's basically it. Your bitcoins would be stored in a wallet that had no form of existence (other than for the short time it took to receive the coins and generate the transaction).

[FCTaiChi]

Sounds like there is some promise here

[dserrano5]

Store
1) Software generates wallet. RAM only if possible. Displays public address.
2) You send funds to public address.
3) Software generates transaction for sending funds to your target public address, does all necessary signing, converts to QR code (or whatever your preference is) and saves/prints/whatever.
4) Software wipes & deletes wallet

5) You don't send any more funds to the public address because the resulting unspent outputs aren't picked up in the pre-generated transaction.

[K1773R]

Good idea Richy!

Suggestion: send the coins to a new temporary Address, wait for 6 confirmations, now create a tx for an address you want the coins go to and save it (or create QR code, saving is better). Why? Since the "actual location" of the coins would be a temporary address which is imported nowhere, not even having the users wallet.dat would help. if someone would have the privkeys he could still steal your BTC as your TX would be a double spend (thats why the thing with the temporary address). Nobody knows the privkey of the temporary address so the bitcoins are "lost" until you publish your signed raw TX

how about this?

Yes, I think that's basically it. Your bitcoins would be stored in a wallet that had no form of existence (other than for the short time it took to receive the coins and generate the transaction).

thats a really good idea, gonna do this in the future for sure

[jl2012]

You still need to keep the private key of your target address safe. So why don't you simply send you coins to the target address directly?

[Abdussamad]

I christen this the "Coins in limbo" version of paper wallets. Clever idea but I think a little too complicated. Traditional paper wallets are easier IMO.

[Razick]

So you create a paper wallet. On the way to the bank, a super-government-spy-satellite reads your code. Or your bank's security is compromised or you just get lazy and leave the paper wallet on your desk and you have a break-in and it gets stolen. All your precious bitcoins are now gone.

So how about instead of creating a wallet, you create a transaction which can later be put onto the blockchain and will send the coins to a specific Bitcoin address? The transaction is signed so cannot be altered or redirected to another address. You don't have to worry about the security of your bitcoins so much because any potential thief not only has to compromise the security of your bitcoin storage but also of your target wallet (which could be a paper wallet, of course). I'd imagine the process something like this...


Store
1) Software generates wallet. RAM only if possible. Displays public address.
2) You send funds to public address.
3) Software generates transaction for sending funds to your target public address, does all necessary signing, converts to QR code (or whatever your preference is) and saves/prints/whatever.
4) Software wipes & deletes wallet

Redeem
1) Scan/convert QR code.
2) Paste here http://blockchain.info/pushtx .
3) Wait for confirmations.

Thoughts? Has this been done before?

Genius. Tow-factor, only way better. I love this idea.

[mprep]

The whole idea seems like the "back to the basics" kind. Interesting though.

[Razick]

So do you mean to have a signed, valid, but not transmitted emergency transaction sending all of your funds to a new address not in your wallet (For which you have a private key stored elsewhere)?

This would set up a race condition where whoever gets their transaction into a block first wins.  Since change addresses are precomputed and stored in the wallet, you would need to create an address outside of your wallet carefully.

Alternatively, what if they stole the target address private key? Then you would have no way to spend your funds safely.

The Bitcoin protocol does have a method of sending funds to an IP address and the computer at the IP address will supply the recipient address... So, in theory, the private/public key pair of the destination address need not be created yet.

You could register an account with a large mining pool (who could get your send to IP address transaction in a block quickly) to create the recipient address and store the private key for you and handover the funds when the incoming coins from the addresses you had told them they would come from arrived.

If I understand correctly, the wallet that actually holds the funds would not be stored. Basically, make an address like you would for a paper wallet, send some coins to it and sign a transaction to another paper wallet (or regular wallet). Then, delete the private key of the first wallet.

I mean no offense, but what you described would be pointless since (assuming a fee was included) it would be very difficult to beat the other transaction, and that would require the address to be monitored so you can act quickly in the event of an unauthorized transaction.

[Razick]

I christen this the "Coins in limbo" version of paper wallets. Clever idea but I think a little too complicated. Traditional paper wallets are easier IMO.

Ideally, we'll have software to do the first part automatically. Of course, the software would have to be inspected and isolated on a disconnected machine.

[Richy_T]

I christen this the "Coins in limbo" version of paper wallets. Clever idea but I think a little too complicated. Traditional paper wallets are easier IMO.

Ideally, we'll have software to do the first part automatically. Of course, the software would have to be inspected and isolated on a disconnected machine.

Ideally. But since the private key exists for such a short amount of time, it may actually not be much of an issue.

The one issue is that the machine would probably need to have some kind of internet connection to be able to verify that the temporary wallet has become funded. It would be possible to do it manually and disconnected, I think, somehow pasting in the tx id of the funding transaction but I'm not quite sure of that and it would definitely add complexity.