From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 727242B6E for ; Wed, 17 Oct 2018 04:26:49 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wr1-f44.google.com (mail-wr1-f44.google.com [209.85.221.44]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 502406FB for ; Wed, 17 Oct 2018 04:26:48 +0000 (UTC) Received: by mail-wr1-f44.google.com with SMTP id l6-v6so27534735wrt.1 for ; Tue, 16 Oct 2018 21:26:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=Mb9Tk96jI7p7mNNATzoLQxeB0CH6AtB5Ujh1ppoCx3M=; b=bfcc0UbefnqTtjHcHAoeiOoJ9WqokXGn5BHMxOpttgOw2V3gmsc6DNIM5kskNQyYMX 6JXzsFNt7iFNF0Jag+R+uKHQpQFNyaGQ+ghcemAHYiJTwDxB7TXqw5IoqWbuab7WEsZd 24Y8VlW3Kpw8HqTcK6EBbA+8Lj+nMZihyEgiq4JLTpwlPqVHI4cg4Zh/Timj1PL32QcV LEvXzQ5hDftakGkPBPU6SH5kU1NofXNohQ3LPLnuU+X2uOoeDVuqGU0HlAcIuQnxK91M Deup5hqpej6cWDQhmwg74feUvQsCbqESBuxYDYQqsusSjDHRHvcLS6cDjn37GYhOs0DP 5BKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=Mb9Tk96jI7p7mNNATzoLQxeB0CH6AtB5Ujh1ppoCx3M=; b=H/r4shOf0zQKn+chTRrgfnIc7lli3bhObErdQxBsu1puV8661WVOuB0yF3OeQZzQDZ 2afpys/8JHujiucfxqu+maS4qM5b8qzxSmm/SkEzXZJkhZaW2JxY+xti5MlpU/w8Kojp JDYruiXKcYjBeAwTN4P+/fcbz3oExVDconTXAvM0+ZNu4kiolh4HADWjynSTlMAA04DN 8l/CJIDxemH7wLUo2Hd705JCaOzQru9Idsn/+jbNc22vUfaieanA6YYOAAyOtRFIGTCM wniFhwykpXgYzGwtUHGEz/ixKtstRrl58PimUS9/NCP71I3Jp6gtFKE+klgFIc+oU+sN 9/mA== X-Gm-Message-State: ABuFfogivYEmtd/3AMrWeUrC65upQwqoyx96XUaASDUGXVU3TuKA8AKi Vx/CgwJd6FIpx19t1IoWoDu/Nc7PEoUp6x9kbvaTu+Ml X-Google-Smtp-Source: ACcGV61AtnJR1LZnsxXZVv9uSysGGeLhmbm5Dafi27A/IZZEwP+SrJg455yIhOxttTNTuAo1CWaMmxZbK6Y90PhNAM0= X-Received: by 2002:adf:a387:: with SMTP id l7-v6mr23474558wrb.1.1539750406550; Tue, 16 Oct 2018 21:26:46 -0700 (PDT) MIME-Version: 1.0 From: kim juan Date: Wed, 17 Oct 2018 12:26:34 +0800 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="0000000000000678fc0578651476" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 17 Oct 2018 04:39:06 +0000 Subject: [bitcoin-dev] Request: OP_CHECKTXOUTSCRIPTHASHVERIFY X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Oct 2018 04:26:49 -0000 --0000000000000678fc0578651476 Content-Type: text/plain; charset="UTF-8" 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 2 CHECKMULTISIG ELSE CHECKTXOUTSCRIPTHASHVERIFY DROP 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: 0 scriptPubKey: HASH160 EQUAL tx2: //if there is change scriptSig: 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 2 CHECKMULTISIG ELSE "12h" CHECKSEQUENCEVERIFY DROP CHECKSIG ENDIF After 12 hours, Acme is can spend the output as normal. tx: scriptSig: 0 scriptPubKey: DUP HASH160 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. --0000000000000678fc0578651476 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

Discussing the possibility of a new opcode (OP_CHECKTXOUTSCRIPTHASHVERIFY= ) = for the Bitcoin scripting system that allows a transaction output to be onl= y spendable in a predefined manner.

Brief= Description

Bitcoin transactions have a=C2=A0txoutScript=C2=A0(scriptPubKey) fiel= d for each output.
txoutScrip= tHash=3DHash160(txoutScript)

Word:=C2=A0OP_CHECKTXOUTSCRIPTHASHVERIFY
Opcode:=C2=A0184 (OP_NOP9)
Input:=C2=A0= xOutput:=C2=A0x / fail*
Description:
Marks transaction as inval= id if=C2=A0txoutScriptHash=C2= =A0is not equal to top stack item and value of=C2=A0txout= Script=C2=A0is not equal to=C2=A0OP_HASH160= ThisRedeemScriptHash OP_EQUAL*.

* Not entirely certain here, always have this impression new opcod= e has to "NOP= or fail" to ensure it can be implemented. As a result,=C2=A0the item may also has to be dropped explicitly.
* So that change= can be sent back to the this redeem script. There are challenges to genera= lize this as a script hash cause of some cyclic reference. Not sure if cycl= ic is the correct term, ie: A =3D hash (B's hash) and B =3D hash (A'= ;s hash) is impossible.

Sample use case

Acme has an ordinary key pair and a secure key pair.=C2=A0The ordinary key pair is assumed to be in a = less secure environment.=C2=A0=C2=A0The private key of the secure key pair will never ever expose itself un= til the moment it needs to revoke transaction of the ordinary key pair.
=

re= deemScript:
=C2=A0=C2=A0IF
=C2=A0 =C2=A0 2=C2=A0<Acme's pubkey= >=C2=A0<securePubkey> 2=C2=A0CHECKMULTISIG
=C2=A0 ELSE
=C2= =A0 =C2=A0 <txoutScriptHash>=C2=A0CHECKTXOUTSCRIPTHASHV= ERIFY=C2=A0DROP <Acme's pubkey>=C2=A0CHECKSIG
=C2=A0 ENDIF

The only ways to spend its output= s from this=C2=A0ThisRedeemScript=C2=A0is to forward it to=C2=A0NextRed= eemScript.=C2=A0Even if t= he original key pair is=C2=A0com= promised, the attacker can only spend it this way and has to publish the tr= ansaction.

tx1:
=C2=A0 scriptSig: <sig> <pubKey&= gt; 0
=C2=A0 scriptPubKey:=C2=A0HASH160 <Hash160(NextRedeem= Script)> EQUAL

= tx2: //if there is change
=C2=A0 scriptSig: <sig> <Acme's pubKey>
=C2=A0 script= PubKey:=C2=A0HASH160=C2=A0ThisRedeemScriptHash=C2= =A0EQUAL

NextRedeemScript=C2=A0is time locked. Acme is able to monitor for=C2=A0unauthorized transactions=C2=A0and react within the sequence-defined= duration. The combination of 2 key pair as one multisig can spend the outp= ut immediately regardless of the timelock.

NextRedeemScript:
= =C2=A0 IF
=C2=A0 =C2=A0 2=C2=A0<Acme's pubkey>=C2=A0<secure= Pubkey> 2=C2=A0CHECKMULTISIG
=C2=A0 ELSE
=C2=A0 =C2=A0=C2=A0"12= h" CHECKSEQUENCEVERIFY DROP=C2=A0<Acme's pubkey>=C2=A0CHECKS= IG
=C2=A0 ENDIF

After 12 hours, = Acme is can spend the output as normal.

tx:
=C2=A0 sc= riptSig: <sig> <pubkey> 0
=C2=A0 scriptPubKey:=C2=A0DUP HASH160 = <recipient's pubkeyHash> EQUALVERIFY CHECKSIG

D= escription

CSV and CTLV already laid the groundwork fo= r retroactive invalidation, showcased in innovative protocols such a= s HTLC of lightning network.

As illustrated from the sample use case= , there are other classes of problems that may requires retroactive = invalidation in different=C2=A0and less-interactive way from channel= s. Most of those problems require a primitive opcode to influence how the o= utput can be spent.

If the use case works as expect= ed, attacks will be=C2=A0less=C2=A0rewarding. 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 reque= st. This additional depth of defense is an improvement to deter attacks esp= ecially if an attack is costly to pull.

> After 12 hours, it may = be still possible for attacker to submit transactions in concurrent or ahea= d of Acme.
Acme should submit the transaction before the 12 hours and le= ave it=C2=A0in mempool, waiting for nSequence to= elapse.=C2=A0Attacker's transaction submitted after it=C2=A0= should be(?)=C2=A0rejected by the network. A= ttacker's transaction submitted before it will be caught by the monitor= ing function. Even if the above assumption is misguided, the use-case is st= ill useful if transactions have value smaller quantity than total, that lim= its loss to only the transaction's value. At the same time, that reveal= s the fact that the key pair is compromised and the further preventive acti= ons can be carried out using the secure key pair.

P= ossible privacy concern: The use case demonstrated change to be sent back t= o self (there may be related concern such as wrongly configured digital sig= nature). The use case assumed P2SH is exceptional case, kind of like multis= ignature wallets, for custodians like e-commerce merchants, exchanges.

<= /div> --0000000000000678fc0578651476--