Could we theoretically create an output that could only be spent after some proof-of-work?
stringtoconcatenate OP_CAT OP_SHA256 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 OP_LESSTHAN OP_VERIFY OP_DROP OP_DUP OP_HASH160 e6ee700d3b22c43b4ad5d4144ae16d35a0013bc0 OP_EQUALVERIFY OP_CHECKSIG
Our scriptsig would have first the signature and then the nonce.
The nonce and a string in the script - perhaps a recent headline, to prove work wasn't done prior to the transaction - would be concatenated (if OP_CAT wasn't disabled) and then we'd get the SHA-256 hash of the combined string. If that hash is less than a target, then yes, we can check the signature.
I think this could be useful (if not fun) for a trust fund, or proof-of-illiquidity, if our target has enough leading zeroes to make it (on average) take a few days to find a working nonce, and therefore make the output spendable. Perhaps the target could take years with a GPU farm.
Any comments? Would this be a good/bad idea? (assuming of course OP_CAT was enabled?)
stringtoconcatenate OP_CAT OP_SHA256 00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048 OP_LESSTHAN OP_VERIFY OP_DROP OP_DUP OP_HASH160 e6ee700d3b22c43b4ad5d4144ae16d35a0013bc0 OP_EQUALVERIFY OP_CHECKSIG
Our scriptsig would have first the signature and then the nonce.
The nonce and a string in the script - perhaps a recent headline, to prove work wasn't done prior to the transaction - would be concatenated (if OP_CAT wasn't disabled) and then we'd get the SHA-256 hash of the combined string. If that hash is less than a target, then yes, we can check the signature.
I think this could be useful (if not fun) for a trust fund, or proof-of-illiquidity, if our target has enough leading zeroes to make it (on average) take a few days to find a working nonce, and therefore make the output spendable. Perhaps the target could take years with a GPU farm.
Any comments? Would this be a good/bad idea? (assuming of course OP_CAT was enabled?)
Your example won't work even if OP_CAT is enabled because OP_LESSTHAN could only handle 32-bit integers. You need OP_SUBSTR (which is also disabled) to split the string first and use multiple OP_LESSTHAN to make the comparison.
Anyway, I can't see how a probabilistic proof of illiquidity could be useful in any scenario.
