Seems interesting, though complicated, compared to the 'trust me for 12 months' I proposed here:
https://bitcointalksearch.org/topic/m.2275068
Recipient knows you have reserved bitcoin for her/him/it.
You cannot claim those BTC back before the end of the contract.
Recipient cannot claim the BTC, you have to actually send them to make them her/his.
12 months can also be 2 weeks, or 2 days, depending on trust factor.
Solves the issue of exchanges being hacked.
They would only hack shadow coin, which real siblings are still safe in your wallet.
And when they ask you to validate one of your open orders to sell some shadow coins, you just have to send to coins to the required address to validate it. The one and only address you can send those bitcoins to, before the contract ends.
Topic: Forget Paper Wallets - Paper transactions? (Read 1873 times)
The goal is to keep your bitcoins secure. "Funds in a 2-of-2 address" is a better way to do it than "funds that can only be deposited to wallet X" - what these methods have in common is that they rely on two pieces of information that are both needed.
What I meant by "flexible" is that with multisig you can have other ways to secure your coins, potentially better - e.g. 2-of-3.
What I meant by "flexible" is that with multisig you can have other ways to secure your coins, potentially better - e.g. 2-of-3.
Fair enough. It's just another option I though might be interesting to consider and discuss. Multisig may be better in most or all scenarios but since this is operationally different, it is possible there are scenarios where it would be superior.
Consider, for example, that you can trust an entity to hold one of these tokens and give them full authority to be able to initiate the transfer of the funds into your wallet without actually having to trust that entity with any of your actual bitcoins.
No. That's pretty much the *only* attack vector.
Ok, "additional attack vector", singular. The attack they have in common is stealing both pieces.Slightly incorrect. You can add more funds. You'll just never be able to get them out.
That's not adding funds, that's discarding them. By "wallet" I don't mean "address", I mean "someplace that you keep bitcoins". If you can't get them out they're not "kept" and thus not in a wallet.Don't want to get into semantics, it's a distinction without a difference. So I'll let that stand.
Yes. That's kind-of the point. There is no flexibility. All you can do is initiate the deposit of the coins to wallet X
You're confusing the end with the means.The goal is to keep your bitcoins secure. "Funds in a 2-of-2 address" is a better way to do it than "funds that can only be deposited to wallet X" - what these methods have in common is that they rely on two pieces of information that are both needed.
What I meant by "flexible" is that with multisig you can have other ways to secure your coins, potentially better - e.g. 2-of-3.
No. That's pretty much the *only* attack vector.
Ok, "additional attack vector", singular. The attack they have in common is stealing both pieces.Slightly incorrect. You can add more funds. You'll just never be able to get them out.
That's not adding funds, that's discarding them. By "wallet" I don't mean "address", I mean "someplace that you keep bitcoins". If you can't get them out they're not "kept" and thus not in a wallet. - Less intuitive
- The deposit procedure is more convoluted
- Less flexible (there's no obvious way to extend to, say, 3-of-5 without involving multisig logic)
- Additional attack vectors - e.g., attacker steals just the target private key, and beats you to the tx that moves coins from it when you cash out
- Impossible to add more funds to the same wallet
- The deposit procedure is more convoluted
- Less flexible (there's no obvious way to extend to, say, 3-of-5 without involving multisig logic)
- Additional attack vectors - e.g., attacker steals just the target private key, and beats you to the tx that moves coins from it when you cash out
- Impossible to add more funds to the same wallet
Yes.
Yes.
Yes. That's kind-of the point. There is no flexibility. All you can do is initiate the deposit of the coins to wallet X
No. That's pretty much the *only* attack vector.
Slightly incorrect. You can add more funds. You'll just never be able to get them out.
Instead of having one secret i.e. a private key to your address
You now have secret 1 and secret 2
secret 1 is the encoded transaction with private key discarded
You would have to keep it secret as otherwise anyone could just initiate the transaction and we would be back to square one
Secret 2 is your private key to your address
If only secret 1 is completely stolen your coins are lost (unless thief is good enough to process transaction)
If only secret 1 is stolen but you have a copy your coins are still safe but we are back to square one.
If only secret 2 is completely stolen your coins are lost.
If only secret 2 is stolen but you have a copy then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen but you have a copy of both then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen and you have no copy of either then your coins are stolen.
If both secret 1 and secret 2 are stolen but you have a copy of secret 1 but not a copy of secret 2 then the coins are stolen
If both secret 1 and secret 2 are stolen but you have a copy of secret 2 but not a copy of secret 1 then it is a race to perform a transaction
Now we need to to assess the probability of a breach of bank security or super-spy-government-satellite attack or other such attack on each of the above scenarios in relation to the increased probability of key loss.
If we calculate the relative probabilities for each scenario and use this to calculate an overall weighted probability that should give us some idea of whether we would be better off using this system or not.
You now have secret 1 and secret 2
secret 1 is the encoded transaction with private key discarded
You would have to keep it secret as otherwise anyone could just initiate the transaction and we would be back to square one
Secret 2 is your private key to your address
If only secret 1 is completely stolen your coins are lost (unless thief is good enough to process transaction)
If only secret 1 is stolen but you have a copy your coins are still safe but we are back to square one.
If only secret 2 is completely stolen your coins are lost.
If only secret 2 is stolen but you have a copy then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen but you have a copy of both then it is a race to perform a transaction
If both secret 1 and secret 2 are stolen and you have no copy of either then your coins are stolen.
If both secret 1 and secret 2 are stolen but you have a copy of secret 1 but not a copy of secret 2 then the coins are stolen
If both secret 1 and secret 2 are stolen but you have a copy of secret 2 but not a copy of secret 1 then it is a race to perform a transaction
Now we need to to assess the probability of a breach of bank security or super-spy-government-satellite attack or other such attack on each of the above scenarios in relation to the increased probability of key loss.
If we calculate the relative probabilities for each scenario and use this to calculate an overall weighted probability that should give us some idea of whether we would be better off using this system or not.
So basically, you have two pieces of information (the tx and the private key of the target address), and spending your coins requires having both. So this is in no way better than putting the coins in a 2-of-2 multisig address. But there are several ways it's worse:
- Less intuitive
- The deposit procedure is more convoluted
- Less flexible (there's no obvious way to extend to, say, 3-of-5 without involving multisig logic)
- Additional attack vectors - e.g., attacker steals just the target private key, and beats you to the tx that moves coins from it when you cash out
- Impossible to add more funds to the same wallet
- Less intuitive
- The deposit procedure is more convoluted
- Less flexible (there's no obvious way to extend to, say, 3-of-5 without involving multisig logic)
- Additional attack vectors - e.g., attacker steals just the target private key, and beats you to the tx that moves coins from it when you cash out
- Impossible to add more funds to the same wallet
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.
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.
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.
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.
The whole idea seems like the "back to the basics" kind. Interesting though.
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?
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.
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.
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?
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?
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
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
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.
Sounds like there is some promise here
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?
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).
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...
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?
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?
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.
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.
Jump to: