Re: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY

[kim juan <kimjuan.chan@gmail.com>]

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