[bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

[bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

[kim juan]

[-- 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 --]

Re: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

[ZmnSCPxj]

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

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

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

Re: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

[kim juan]

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

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 <https://protonmail.com> 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.
>
>
>

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

Re: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

[ZmnSCPxj]

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

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

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