Tier Nolan [ARCHIVE] on Nostr: š Original date posted:2016-08-03 š Original message:On Wed, Aug 3, 2016 at ...
š
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>
š 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>