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 BA3CA2F0C for ; Wed, 17 Oct 2018 06:58:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 344A87C for ; Wed, 17 Oct 2018 06:58:23 +0000 (UTC) Received: by mail-wm1-f48.google.com with SMTP id e187-v6so926820wmf.0 for ; Tue, 16 Oct 2018 23:58:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=HpcI2YtCt1jrEBxwFWNoe9sIfu5uo9VhT+dcCUdgypg=; b=jFjrRyLN4H4bT51rYeoKxkK4YtjF4rSQHBe+8Eb9vL8QK67CYLhECH1rW7OLEPPFIT 34DtC/Dcn84xIwA+fWE1/CIk+KrIKjbqrKqjSwQP6LVk/LvPct8nUznwRFr5PRTHi8rM NQjN+KG1+NCMIKmam7Sk3UhjyS+W0WwU3kFUkJnZ3GbyAj9R4LnPWs8HcCOg29KyvS/2 w8xkWT6H1wiZb62F05dkG8L+W5l/+umlS/yFrlEpYrPVAhVUoho4gQdfMoic0MBRC44T IO8RuNLFKgWoxnxjoMlhlbNE9TLIUYVLLgjfSqsHFgyZqCfkIEOhMijhmdwa5XCTFc3N Gq4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=HpcI2YtCt1jrEBxwFWNoe9sIfu5uo9VhT+dcCUdgypg=; b=PEBQYzfsiDiY4YAy5JtGNqRlMmf69eIo0YjEZ8mriBBFSyn/sJv8aGsTRY/TKUR0B/ DUj6aVe9vETbCZcDV8kji/K6P/A5HEnCx482zZnNCOKpQrxDkJ07lHpERNiVLZsvRrat lT3POLtKtNgObGL52KQG4Mg4+m5viFi9huJunZal8YW3aK+OnRyr0VLkCYOPyc3XvXgm 9FMyW5PiNyQOKJkXwVjvFVlpV/9FNjJQpzNrGEFuIrjZEOBpGCqtOEuZUDb4CeiiI2AD q7cshhh25fBZISbdIy7DlOVR84AjvRkiQkN++uWrZJmw/XklsxjrmxhiQnYGTfIFwj2s STkg== X-Gm-Message-State: ABuFfogi7vZs/RX7ZXw74jSsoIyZwmuzr9sEEHLCbuw+D1YVYNziw3c0 bEEJLxZJMlLteG5BrZdbNXjrjIXXD3YjsTs6K60= X-Google-Smtp-Source: ACcGV612dJf4Fm3V3dulukQ8NmtgU6iXKEpO+u83/E0041QBNzcESGHDF60OlSP1UJhT0IKdYS18Yt/uVli2NakNpLg= X-Received: by 2002:a1c:1804:: with SMTP id 4-v6mr1394007wmy.29.1539759501730; Tue, 16 Oct 2018 23:58:21 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: kim juan Date: Wed, 17 Oct 2018 14:58:10 +0800 Message-ID: To: ZmnSCPxj@protonmail.com Content-Type: multipart/alternative; boundary="00000000000023e91d0578673246" 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 07:01:01 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org Subject: Re: [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 06:58:24 -0000 --00000000000023e91d0578673246 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 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 wou= ld > allow covenants much more generally, but with more complex (clever) SCRIP= T. > > 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 SCRI= PT > 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 outpu= t > being spent. > > Otherwise, if any output does not match either of the above, this > operation will fail. > > Regards, > ZmnSCPxj > > > Sent with ProtonMail Secure Email. > > =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original = Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 > 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=3DHash160(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 m= ay > 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 scri= pt > hash cause of some cyclic reference. Not sure if cyclic 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. 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 nee= ds > 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 compromi= sed, > the attacker can only spend it this way and has to publish the transactio= n. > > 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 immediatel= y > 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 improveme= nt > 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 i= f > transactions have value smaller quantity than total, that limits loss to > only the transaction's value. At the same time, that reveals the fact tha= t > 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 bac= k > 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, exchang= es. > > > --00000000000023e91d0578673246 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi ZmnSCPxj,

Thanks for the heads up and suggestion= s.

Found my way to the bitcoin-covenant article. That is indeed gene= ralized and flexible, hence more powerful than this dumbed-down plain compa= rison of output bytes-to-bytes.

Interestingly, the vault described i= n 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".= =C2=A0 I believe, that there are vague plans to possibly include OP_CHECKSI= GFROMSTACK, 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 invo= lve only future SegWit versions).

The specific= ation could be improved as below:

The OP_CHECK= TXOUTSCRIPTHASHVERIFY will succeed if either of the below are true for all = outputs of the transaction that is spending this SCRIPT:

=
1.=C2=A0 It is a P2WSH whose SegWit version and hash, when conca= tenated together, are equal to the stack top.
2.=C2=A0 It is = a P2WSH or P2SH-P2WSH that is the same as the transaction output being spen= t.

Otherwise, if any output does not match eit= her of the above, this operation will fail.

Re= gards,
ZmnSCPxj


Sent with ProtonMail Secure Email.

=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original M= essage =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
<= /div>
On Wednesday, October 17, 2018 12:26 PM, kim juan via bitcoin-de= v <bitcoin-dev@lists.linuxfoundation.org> wrote:
<= br>

Discussing the possibility of a new opcode (<= span style=3D"font-family:monospace,monospace" class=3D"m_-7856430591641183= 749font">OP_CHECKTXOUTSCRIPTHASHVERIFY) for the Bitcoin scripting system = that allows a transaction output to be only spendable in a predefined manne= r.
Brief Description

Bit= coin transactions have a=C2=A0txoutScript=C2=A0(<= span style=3D"font-family:monospace,monospace" class=3D"m_-7856430591641183= 749font">scriptPubKey) field for each output.
= txoutScriptHash=3DHash16= 0(txoutScript)

Word:=C2=A0OP_CHECKTXOUTSCRIPTHASHVERIFY
Opcode:= =C2=A0184 (OP_NOP9)
Input:=C2=A0x
Output:=C2=A0x / fail*
Description:
Marks= transaction as invalid if=C2=A0t= xoutScriptHash=C2=A0is not = equal to top stack item and value of=C2=A0txoutScript=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 b= e implemented. As a result,=C2=A0the item may also has to be dropped explicitl= y.
* So that change can be sent ba= ck 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 corre= ct term, ie: A =3D hash (B's hash) and B =3D hash (A's hash) is imp= ossible.

Sample use case

Acme has an ordinary= key pair and a secure key pair.=C2=A0The ordinary key pair is assum= ed to be in a less secure environment.=C2=A0=C2=A0The private key of= the secure key pair will never ever expose itself until the moment it need= s to revoke transaction of the ordinary key pair.

redeemS= cript:
=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=A0CHECKTXOUTSCRIPTHASHVERIFY=C2=A0DROP <Acme's pubkey>=C2=A0CHECKSIG
=C2=A0 ENDIF

The only ways to spend i= ts outputs from this=C2=A0ThisRedeemScript=C2=A0is to forw= ard it to=C2=A0NextRedeemScript.=C2=A0Even if the= original key pair is=C2=A0compromised, the attacker can only spend = it this way and has to publish the transaction.

tx1:
<= span style=3D"background-color:rgb(248,249,250)" class=3D"m_-78564305916411= 83749highlight">=C2=A0 scriptSig: <sig> <pubKey> 0
<= span style=3D"font-family:monospace,monospace" class=3D"m_-7856430591641183= 749font">=C2=A0 scriptPubKey:=C2=A0HASH160 <Hash= 160(NextRedeemScript)> EQUAL

tx2: //if th= ere is change
=C2=A0 scriptSig: <sig> <Acme= 9;s pubKey>
=C2=A0 scriptPubKey:=C2=A0HASH160=C2=A0ThisRedeemScriptHash= =C2=A0EQUAL

<= span style=3D"font-family:monospace,monospace" class=3D"m_-7856430591641183= 749font">NextRedeemScript=C2=A0is time locked. Acme is able to mon= itor for=C2=A0unauthorized transactions=C2=A0and react within= the sequence-defined duration. The combination of 2 key pair as one multis= ig can spend the output immediately regardless of the timelock.

<= p style=3D"box-sizing:border-box;margin-top:0px;margin-bottom:16px">NextRedeemScript:
=C2=A0 IF=
=C2=A0 =C2=A0 2=C2=A0&= lt;Acme's pubkey>=C2=A0<securePubkey> = 2=C2=A0CHECKMULTISIG
=C2=A0 ELSE
=C2=A0 =C2=A0= =C2=A0"12h" CHECKSEQUENCEVERIFY DROP=C2=A0<Acme's pubkey>=C2=A0CHECKSIG
=C2=A0 ENDIF

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

tx:
=C2=A0 scr= iptSig: <sig> <pubkey> 0
=C2=A0 scriptPubK= ey:=C2=A0DUP HASH160 <recipient's pubke= yHash> EQUALVERIFY CHECKSIG

Descri= ption

CSV and CTLV already laid the groundwork for r<= /span>etroactive invalidation, showcased in innov= ative protocols such as HTLC of lightning network.

As illustrated fr= om the sample use case, there are other clas= ses of problems that may requires retroactive invalidation in different=C2=A0and less-interactive way from channels. Mo= st of those problems require a primitive opcode to influence how the output= can be spent.

If the use case works as expected, attack= s will be=C2=A0less=C2=A0rewarding. There are still other attack vec= tors if Acme's original key pair is compromised, i.e;

> The a= ttacker 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 a= dditional depth of defense is an improvement to deter attacks especially if= an attack is costly to pull.

> After 12 hours, it may be still p= ossible for attacker to submit transactions in concurrent or ahead of Acme.=
Acme should submit the transaction before the 12 hours and leave it=C2= =A0in mempool, waiting for nSeq= uence to elapse.=C2=A0Attacker's transaction submitted af= ter it=C2=A0should be(?)= =C2=A0rejected 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 small= er quantity than total, that limits loss to only the transaction's valu= e. 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 demonstrate= d change to be sent back to self (there may be related concern such as wron= gly configured digital signature). The use case assumed P2SH is exceptional= case, kind of like multisignature wallets, for custodians like e-commerce = merchants, exchanges.


--00000000000023e91d0578673246--