What would be the practical applications of such an interesting transaction?
Like, I create a transaction that can be redeemed by either myself or you? I could even see a thing where you release such a transaction, and an nlocked one for the 2nd next block that spends it back to yourself in a 1 of 1 tx?
Topic: Can I send to an output that can only be spent to one of two addresses? (Read 728 times)
March 25, 2014, 08:07:01 PM
March 25, 2014, 07:32:19 PM
it would be a useful facility. As you say it would reduce the motive/rewards for theft. Unless the thief also controls one of the output addresses, the key to the input could not be used to directly get the money for herself.
Also it would be a useful escrow-ish ability, along with outputs spendable only after a certain date.
Also it would be a useful escrow-ish ability, along with outputs spendable only after a certain date.
March 25, 2014, 07:11:21 PM
As I thought.
Quote
And it wouldn't help you at all if it could be done. What you should do is make a 1-of-2 multisig address and send to it now instead of later. If these other keys are more secure than the key that is receiving the money (like on a webserver), you should move the funds out quickly.
It would help. It means the network would verify that the money can only be sent to one of two addresses. A third-party would have no interest in hacking the keys because they still wouldn't be able to send the outputs to their wallet. They would have to hack the keys for the transaction and the keys for one of the destination wallets, at least, and the latter can be cold wallets. 
March 22, 2014, 08:12:17 AM
Not the way you are thinking, no. The script checker only looks at two things, the output script that is being redeemed, and the arbitrary data provided by the redeemer. It has no view of the transaction amount, and it has no view of the upcoming output.
And it wouldn't help you at all if it could be done. What you should do is make a 1-of-2 multisig address and send to it now instead of later. If these other keys are more secure than the key that is receiving the money (like on a webserver), you should move the funds out quickly.
And it wouldn't help you at all if it could be done. What you should do is make a 1-of-2 multisig address and send to it now instead of later. If these other keys are more secure than the key that is receiving the money (like on a webserver), you should move the funds out quickly.
March 21, 2014, 06:38:53 PM
A 2-of-2 address, where the oracle only signs if it's address A or B.. But enforcing it in the script would be better. I wonder if script could do it - I've been playing with them recently, I might try see if I can produce a funky transaction that would achieve this.
March 21, 2014, 05:11:24 PM
Is the following scenario possible?
I want to send money to a script. This script will require knowing a private key to spend, as usual, but the script is only valid if the money is being sent to one of two addresses. That is, if the transaction has more than one output, it is invalid. If the transaction's output is a standard script to address A or to address B then it is valid. If the transaction output value is any less than x, it is invalid.
In other words, it seems the scripts serve to validate that you can spend the output, but then the output can be spent however the claimant(s) want. Is there any way to limit how the outputs are spent? All this without requiring a trusted third party of course.
I want to send money to a script. This script will require knowing a private key to spend, as usual, but the script is only valid if the money is being sent to one of two addresses. That is, if the transaction has more than one output, it is invalid. If the transaction's output is a standard script to address A or to address B then it is valid. If the transaction output value is any less than x, it is invalid.
In other words, it seems the scripts serve to validate that you can spend the output, but then the output can be spent however the claimant(s) want. Is there any way to limit how the outputs are spent? All this without requiring a trusted third party of course.
Jump to: