rich1.0npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdhttps://nostr.ae/npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdnjumphttps://nostr.ae📅 Original date posted:2016-08-03 📝 Original message:On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > The reason why I bring this up is existing OP codes and TX types don't > seem suitable for a secure clearing mechanism; > I think reversing transactions is not likely to be acceptable. You could add an opcode that requires that an output be set to something. [target script] SPENDTO This would require that [target script] is the script for the corresponding output. This is a purely local check. For example, if SPENDTO executes as part of the script for input 3, then it checks that output 3 uses the given script as its scriptPubKey. The value of input 3 and output 3 would have to be the same too. This allows check sequence verify to be used to lock the spending script for a while. This doesn't allow reversal, but would give a 24 hour window where the spenders can reverse the transaction. [IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected key> CHECKSIG] SPENDTO <live public key2> CHECKSIG Someone with the live public key can create a transaction that spends the funds to the script in the square brackets. Once that transaction hits the blockchain, then someone with the <offline protected key> has 24 hours to spend the output before the person with the live keys can send the funds onward. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/3e551535/attachment-0001.html>