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@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 Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, October 17, 2018 12:26 PM, kim juan via bitcoin-dev <bitcoin-dev@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.