[bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

From: kim juan <kimjuan.chan@gmail•com>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY
Date: Wed, 17 Oct 2018 12:26:34 +0800	[thread overview]
Message-ID: <CAAKtTCt1_MTh38Bsft6_V65cLBcxHOrvsXR8yen_Ag1AgWtxcw@mail.gmail.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 4341 bytes --]

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.

[-- Attachment #2: Type: text/html, Size: 12637 bytes --]