No reply? That's a bit disappointing. Is there another sub-forum that would be better suited for this post?
Maybe project development board. Defiantly a cool idea though.
Thanks!
No reply? That's a bit disappointing. Is there another sub-forum that would be better suited for this post?
Maybe project development board. Defiantly a cool idea though.
- snip -
B creates TX1: "Pay 4 BTC to (<A's public key> if x and y known for H(x) and H(y) AND H(x+y) < MAX_HASH * 0.25) OR (signed by A and B)"
B creates TX2: "Pay 4 BTC from TX1 to <B's public key>, locked 6 hours in the future, signed by B"
- snip -
While it might be possible to accomplish what you are wanting to do, it won't work the way you describe it.
Scripts don't "pay to" anything.
Scripts are evaluated based on the input (ScriptSig) that is provided when the output from the transaction is spent. The output script encumbers the output value with some condition that must be met by the ScriptSig before that value can be re-assigned elsewhere. Anyone that can provide the necessary ScriptSig can "spend" that output.
The bitcoin protocol just checks to see what value is remaining on top of the stack after the script is evaluated. A transaction is valid if nothing in the combined script triggers failure and the top stack item is true (non-zero). If the transaction is valid, then the value is reassigned to the new unspent outputs and the previous outputs that were used as inputs outputs are now "spent".
Yes I know that, it was just pseudocode. "pay to X's public key" was a shortcut for the standard "OP_DUP OP_HASH160 <X's pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG" script. I understand that this kind of language should not be used with noobs because it is indeed misleading but I think someone familiar enough with Bitcoin will understand what I meant. Other than that, do you see any critical problems? Maybe I should make the pseudocode a little more concrete? I thought it was quite clear and didn't want spend too much time writing the actual script in case there was a logical flaw in the scheme.