[bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

[ZmnSCPxj]

Good morning kim,

An issue with covenants is that the only "good" use case so far is vaults.  Indeed, what you originally gave as a usecase in your first email is in fact a vault.

Here is gmax original bitcointalk post: https://bitcointalk.org/index.php?topic=278122.0

Since covenants typically require a complex script template, they are a bit heavy (in terms of blockspace) for a "simple" vault application.

I am uncertain if it would be more acceptable to instead target an opcode only for vaults, instead of recursive covenants.

Another issue with vaults/covenants is that they are easily visible onchain.  Recent efforts have been towards making even contract execution be done offchain, guarded only by the contract participants agreeing that the contract has been executed correctly (taproot, also contracts over Lightning).

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Wednesday, October 17, 2018 2:58 PM, kim juan <kimjuan.chan at gmail.com> wrote:

> Hi ZmnSCPxj,
>
> Thanks for the heads up and suggestions.
>
> Found my way to the bitcoin-covenant article. That is indeed generalized and flexible, hence more powerful than this dumbed-down plain comparison of output bytes-to-bytes.
>
> Interestingly, the vault described in bitcoin covenant, which can mitigate risk of even losing the secured (or both) key, can also be achieved using this naive CheckTxoutscriptVerify.
>
> I wish bitcoin-covenant can be materialized, private key management is something to lose sleep for.
>
> On Wed, Oct 17, 2018 at 1:17 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> Good morning kim,
>>
>> This seems to be a specific instance of "covenants".  I believe, that there are vague plans to possibly include OP_CHECKSIGFROMSTACK, which would allow covenants much more generally, but with more complex (clever) SCRIPT.
>>
>> The specification of the behavior of the opcode is P2SH-focused and is unuseable for SegWit, but possibly it can instead be made a SegWit-only opcode instead (especially, since, by my knowledge, future plans for SCRIPT updates will generally involve only future SegWit versions).
>>
>> The specification could be improved as below:
>>
>> The OP_CHECKTXOUTSCRIPTHASHVERIFY will succeed if either of the below are true for all outputs of the transaction that is spending this SCRIPT:
>>
>> 1.  It is a P2WSH whose SegWit version and hash, when concatenated together, are equal to the stack top.
>> 2.  It is a P2WSH or P2SH-P2WSH that is the same as the transaction output being spent.
>>
>> Otherwise, if any output does not match either of the above, this operation will fail.
>>
>> Regards,
>> ZmnSCPxj
>>
>> Sent with [ProtonMail](https://protonmail.com) Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> On Wednesday, October 17, 2018 12:26 PM, kim juan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> Discussing the possibility of a new opcode (OP_CHECKTXOUTSCRIPTHASHVERIFY) for the Bitcoin scripting system that allows a transaction output to be only spendable in a predefined manner.
>>> Brief Description
>>>
>>> Bitcoin transactions have a txoutScript (scriptPubKey) field for each output.txoutScriptHash=Hash160(txoutScript)
>>>
>>> Word: OP_CHECKTXOUTSCRIPTHASHVERIFY
>>> Opcode: 184 (OP_NOP9)
>>> Input: x
>>> Output: x / fail*
>>> Description:
>>> Marks transaction as invalid if txoutScriptHash is not equal to top stack item and value of txoutScript is not equal to OP_HASH160 ThisRedeemScriptHash OP_EQUAL*.
>>>
>>> * Not entirely certain here, always have this impression new opcode has to "NOP or fail" to ensure it can be implemented. As a result, the item may also has to be dropped explicitly.* So that change can be sent back to the this redeem script. There are challenges to generalize this as a script hash cause of some cyclic reference. Not sure if cyclic is the correct term, ie: A = hash (B's hash) and B = hash (A's hash) is impossible.
>>>
>>> Sample use case
>>>
>>> Acme has an ordinary key pair and a secure key pair. The ordinary key pair is assumed to be in a less secure environment.  The private key of the secure key pair will never ever expose itself until the moment it needs to revoke transaction of the ordinary key pair.
>>>
>>> redeemScript:
>>>   IF    2 <Acme's pubkey> <securePubkey> 2 CHECKMULTISIG  ELSE
>>>     <txoutScriptHash> CHECKTXOUTSCRIPTHASHVERIFY DROP <Acme's pubkey> CHECKSIG
>>>   ENDIF
>>>
>>> The only ways to spend its outputs from this ThisRedeemScript is to forward it to NextRedeemScript. Even if the original key pair is compromised, the attacker can only spend it this way and has to publish the transaction.
>>>
>>> tx1:
>>>   scriptSig: <sig> <pubKey> 0  scriptPubKey: HASH160 <Hash160(NextRedeemScript)> EQUAL
>>>
>>> tx2: //if there is change
>>>   scriptSig: <sig> <Acme's pubKey>  scriptPubKey: HASH160 ThisRedeemScriptHash EQUAL
>>> NextRedeemScript is time locked. Acme is able to monitor for unauthorized transactions and react within the sequence-defined duration. The combination of 2 key pair as one multisig can spend the output immediately regardless of the timelock.
>>>
>>> NextRedeemScript:  IF    2 <Acme's pubkey> <securePubkey> 2 CHECKMULTISIG  ELSE    "12h" CHECKSEQUENCEVERIFY DROP <Acme's pubkey> CHECKSIG  ENDIF
>>>
>>> After 12 hours, Acme is can spend the output as normal.
>>>
>>> tx:
>>>   scriptSig: <sig> <pubkey> 0  scriptPubKey: DUP HASH160 <recipient's pubkeyHash> EQUALVERIFY CHECKSIG
>>>
>>> Description
>>>
>>> CSV and CTLV already laid the groundwork for retroactive invalidation, showcased in innovative protocols such as HTLC of lightning network.
>>>
>>> As illustrated from the sample use case, there are other classes of problems that may requires retroactive invalidation in different and less-interactive way from channels. Most of those problems require a primitive opcode to influence how the output can be spent.
>>>
>>> If the use case works as expected, attacks will be less rewarding. There are still other attack vectors if Acme's original key pair is compromised, i.e;
>>>
>>>> The attacker can drain the output as transaction fees.
>>> There could be ways to reduce that risk, but do not intent to add complexity to a request. This additional depth of defense is an improvement to deter attacks especially if an attack is costly to pull.
>>>
>>>> After 12 hours, it may be still possible for attacker to submit transactions in concurrent or ahead of Acme.
>>> Acme should submit the transaction before the 12 hours and leave it in mempool, waiting for nSequence to elapse. Attacker's transaction submitted after it should be(?) rejected by the network. Attacker's transaction submitted before it will be caught by the monitoring function. Even if the above assumption is misguided, the use-case is still useful if transactions have value smaller quantity than total, that limits loss to only the transaction's value. At the same time, that reveals the fact that the key pair is compromised and the further preventive actions can be carried out using the secure key pair.
>>>
>>> Possible privacy concern: The use case demonstrated change to be sent back to self (there may be related concern such as wrongly configured digital signature). The use case assumed P2SH is exceptional case, kind of like multisignature wallets, for custodians like e-commerce merchants, exchanges.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20181017/ba867454/attachment-0001.html>