path: root/2a/59506ecf1699f6adddfe9967e2dc18fc5f8825

Return-Path: <jlrubin@mit.edu>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 8F78DC0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 19:16:42 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 85F3C8733F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 19:16:42 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id BdRB-7Hb980K
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 19:16:40 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 1875586DDB
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 19:16:39 +0000 (UTC)
Received: from mail-io1-f42.google.com (mail-io1-f42.google.com
 [209.85.166.42]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 01EJGc2t017404
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 14 Feb 2020 14:16:38 -0500
Received: by mail-io1-f42.google.com with SMTP id z193so11742128iof.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 11:16:38 -0800 (PST)
X-Gm-Message-State: APjAAAWSulYhx/o5tO8zoboTJOGwtzpGlfH2btKJ2kXcLD0o39azqDHb
 UjrtbVY/TlwXMslvRA1conjRSaZCqQPslLooFVU=
X-Google-Smtp-Source: APXvYqx7+a8cvsNlXMOuS9YHawPu2JXQ18xTIjC/ve7semqpONpnlYYdTzWP4eidT0pAsmz28MVRXj51OYMPylKtgMQ=
X-Received: by 2002:a6b:6103:: with SMTP id v3mr3604682iob.49.1581707797861;
 Fri, 14 Feb 2020 11:16:37 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhjXidpeLLUr4TO30t7U3z_zUxTpU9GBpLxu3MWX3ZFeTA@mail.gmail.com>
 <CAMZUoKkS77GwTW0B+cbh5BE5koB5oR4zbvEFmufAH7rN+CkR+w@mail.gmail.com>
 <CAD5xwhi115pHK4J4=WDX=xbusxG_qP-oOWYNsD4z1Hh7JZ1yzQ@mail.gmail.com>
 <CAD5xwhiQiCZJ18fqJKsW8Z5g2x4TxSyQeNf0+qEkr-UcLat-1A@mail.gmail.com>
 <CAD5xwhj-WGBLGCi4nKE_5D+cYL134Xn4iux03co+s_iHtHhGZw@mail.gmail.com>
 <20191214122546.5e72eb93@simplexum.com>
 <CAD5xwhgwhOwuPjKz-0_y7HP=jTi=6wJo8uH6HqCvOndr6wo0+Q@mail.gmail.com>
 <20200214161826.5d334196@simplexum.com>
In-Reply-To: <20200214161826.5d334196@simplexum.com>
From: Jeremy <jlrubin@mit.edu>
Date: Fri, 14 Feb 2020 11:16:26 -0800
X-Gmail-Original-Message-ID: <CAD5xwhg9xx780i8e=Y9jpj4GBfcjEf+MQ_ap9osi2n6ZQMTN3Q@mail.gmail.com>
Message-ID: <CAD5xwhg9xx780i8e=Y9jpj4GBfcjEf+MQ_ap9osi2n6ZQMTN3Q@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="0000000000006e187b059e8e0b07"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 14 Feb 2020 19:16:42 -0000

--0000000000006e187b059e8e0b07
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi Dmitry,

I don't think that this is fundamentally introducing new behavior, but
let's take a closer look.

We can talk about the issue you bring up purely in terms of a hypothetical
"OP_CHECKINPUTOUTPOINTVERIFY" and "OP_CHECKINPUTSCRIPTVERIFY" (CIOV, CISV)
with obvious implied by name semantics, as a separate construct from CTV
itself. Such opcodes would be strictly more powerful/flexible than what CTV
is enabling.

Using these opcodes I can make an output that can *only* be spent with
another output -- e.g.,

<s> <n> OP_CISV OP_DROP <pk> OP_CHECKSIGVERIFY
<h, i> <n> OP_CIOV OP_DROP <pk> OP_CHECKSIGVERIFY

Let's look at CISV first:

1) Assume that <s> is from the same owner as PK
2) Assume that <s> is from a different owner than PK

In case 1, the wallet can create or recreate the appropriate output as
needed if it gets spent/stuck

In case 2, the wallet can get "frozen" in a reorg until a signer on <s>
re-spends.


For CIOV:

1) Assume that <h, i> exists in the chain somewhere
2) Assume that <h, i> exists in the mempool somewhere
3) Assume that <h, i> does not exist (or, is provably non-creatable -- h =
=3D
txid(x) | x.IsValid() =3D=3D false)

In case 2, this is just a fancy op-return.

Case 1 degrades into case 2 in the event of a reorg.

In Case 2, if the output <h, i> is spent in another transaction, our script
becomes provably unspendable (unless a second reorg).

Otherwise, it is possible to mine a block with our transaction.


Compare the above to normal transactions:

1) If a reorg occurs, and someone double-spends, your transaction gets
cancelled.
2) You can re-sign your UTXO onto a different transaction

However, if you have deleted your key (e.g. using a pre-signing HSM), or
your transaction was using a multi-sig with an uncooperating party, you
will have an output that may be effectively burned.

These issues are -- as with CTV -- not present in the single input use case=
.

Thus I argue that CTV -- whose semantics are less powerful/flexible than
CISV/CIOV -- aren't introducing something that's not already present when
doing protocols involving more than one input.

Further, on CTV "monotonic authorization":

Generally we want Bitcoin Scripts to have the property that once a
condition is reached, it is 'permanently' a true case. E.g., showing a hash
preimage to C x, H(x) =3D=3D C. This can't change with the weather or anyth=
ing
else. Even things like timelocks -- although not obvious at first glance --
have this property. They express logic that says "given the chain is at
this height, ...". This means that on any chain at such a height the txn is
valid. CISV/CIOV semantics also fall in line with this description. It
says, "given such an input U, ...". If that input is realizable one time,
it is provably realizable across reorgs. However, that doesn't mean someone
couldn't interrupt U from being created. But generally, with Reorg + Double
spend, or Reorg > 100 blocks (potentially destroying CB reward), all bets
are off as to the replay-ability of transactions.

I want to also point out that this "revocation" property -- to the extent
it is something new that can't already be emulated with pre-signeds or RBF
-- is entirely opt-in as far as CTV is concerned. You have to specify that
an output can only be spent with another, most wallets shouldn't do that,
and it can't "infect" other wallets to an extent more than spending from
any recently confirmed output exposes you to more reorg risk.

*In sum, we do not need to worry about this for CTV.*


Lastly, I want to note that revocation is part of what CTV is designed to
do (absent reorgs). It allows us to prune spending conditions by playing a
transaction forward.

E.g., spending conditions {Alice & Bob, Preimage(H(X)) + Eve, CTV({Alice &
Bob}, 1 day)}

Expresses that Eve has 1 day to reveal the preimage to H(X), otherwise
Alice and Bob can take the coin back by removing Eve's HTLC path. What's
cool about this revocation v.s. just {Alice & Bob, Preimage(H(X)) + Eve} is
that Alice and Bob don't need to coordinate a multisig to revoke Eve.



--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>


On Fri, Feb 14, 2020 at 3:17 AM Dmitry Petukhov <dp@simplexum.com> wrote:

> I decided to take this thread back on-list because I beleive that the
> 'revocation utxo' feature enabled by OP_CTV commiting to scriptSig may
> have wider implications that can slightly change the behavior of Bitcoin
> as a system, and some might not expect such changes or might not find
> them desireable (although there is already a case for such behaviour
> with RBF).
>
> There is a principle that some find valuable: "During reorgs of depth
> less than 100, it is always possible to eventually replay transactions
> from the old branch into the new branch as long as no double spends are
> attempted" (quoted from Russel O'Connor from the discussion about
> 'revocation utxo' on Elements Slack channel).
>
> As far as I can tell, this principle can be violated with the use of
> RBF: "(tx) that was included in branch A and then RBF-ed (tx') in branch
> B and then branch A wins -> children of (tx') can't be replayed"
>
> Some may hold an opinion that introducing new rules that violate that
> principle should be done with caution.
>
> The 'revocation utxo' feature enabled by OP_CTV essentially introduces
> a manually triggered 'inverse timelock' -  normal timelocks make tx
> invalid until certain point in time, and inverse timelock make tx
> invalid _after_ certain point in time, in this case by spending an
> unrelated UTXO.
>
> In a reorg, one branch can have that UTXO spent before the OP_CTV
> transaction that depends on it is included in the block, and the OP_CTV
> transaction and its children can't be replayed.
>
> This is the same issue as an 'automatic inverse timelock' that could
> be enforced by the structure of the transaction itself, if there was
> appropriate mechanism, with the difference that 'revocation utxo' is
> manually triggered.
>
> The absense of 'automatic inverse timelock' mechanism in Bitcoin hints
> that it was not seen as desireable historically. I was not able to find
> the relevant discussions, though.
>
> I would like to add that the behaviour enabled by inverse timelocks
> could be useable in various schemes with covenants, like the vaults
> with access revocable by spending the 'revocation utxo', or in the
> trustless lending schemes where the covenant scripts can enforce
> different amounts of interest paid to lender based on the point in time
> when the loan is returned - the obsolete script paths (with smaller
> interest paid) can be disabled by inverse timelock.
>
> =D0=92 Fri, 13 Dec 2019 23:37:19 -0800
> Jeremy <jlrubin@mit.edu> wrote:
>
> > That's a cool use case. I've thought previously about an
> > OP_CHECKINPUT, as a separate extension. Will need to think about if
> > your construction introduces a hash cycle (unless
> > SIGHASH_ALL|SIGHASH_ANYONECANPAY is used it seems likely).
> >
> > Also re signatures I think it's definitely possible to pick a
> > (signature, message) pair and generate a pk from it, but in general
> > the Bitcoin message commits to the pk so forging isn't possible.
> >
> > On Fri, Dec 13, 2019, 11:25 PM Dmitry Petukhov <dp@simplexum.com>
> > wrote:
> >
> > > Another idea for smart vaults:
> > >
> > > The ability to commit to scriptSig of a non-segwit input could be
> > > used for on-chain control of spending authorization (revoking the
> > > spending authorization), where CTV ensures that certain input is
> > > present in the transaction.
> > >
> > > scriptSig of that input can contain a signature that commits to
> > > certain prevout. Unless it is possible to forge an identical
> > > signature (and I don't know how strong are guarantees of that),
> > > such an input can only be valid if that prevout was not spent.
> > >
> > > Thus spending such prevout makes it impossible to spend the input
> > > with CTV that commits to such scriptSig, in effect revoking an
> > > ability to spend this input via CTV path, and alternate spending
> > > paths should be used (like, another taproot branch)
> > >
> > >
> > > =D0=92 Fri, 13 Dec 2019 15:06:59 -0800
> > > Jeremy via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
> > > =D0=BF=D0=B8=D1=88=D0=B5=D1=82:
> > > > I've prepared a draft of the changes noted above (some small
> > > > additional modifications on the StandardTemplateHash described in
> > > > the BIP), but have not yet updated the main branches for the BIP
> > > > to leave time for any further feedback.
> > > >
> > > > See below:
> > > >
> > > > BIP:
> > > > https://github.com/JeremyRubin/bips/blob/ctv-v2/bip-ctv.mediawiki
> > > > Implementation:
> > > > https://github.com/JeremyRubin/bitcoin/tree/checktemplateverify-v2
> > > >
> > > > Thank you for your feedback,
> > > >
> > > > Jeremy
> > > > --
> > > > @JeremyRubin <https://twitter.com/JeremyRubin>
> > > > <https://twitter.com/JeremyRubin>
> > >
> > >
>
>

--0000000000006e187b059e8e0b07
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:#000000">Hi Dmitry,</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">I don&#3=
9;t think that this is fundamentally introducing new behavior, but let&#39;=
s take a closer look.<br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:#000000"><br></div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:#000000">We can talk about the issue you bring up pu=
rely in terms of a hypothetical &quot;OP_CHECKINPUTOUTPOINTVERIFY&quot; and=
 &quot;OP_CHECKINPUTSCRIPTVERIFY&quot; (CIOV, CISV) with obvious implied by=
 name semantics, as a separate construct from CTV itself. Such opcodes woul=
d be strictly more powerful/flexible than what CTV is enabling.<br></div><d=
iv><div dir=3D"ltr" class=3D"gmail_signature" data-smartmail=3D"gmail_signa=
ture"><div dir=3D"ltr"><br></div><div dir=3D"ltr"><div style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmai=
l_default">Using these opcodes I can make an output that can *only* be spen=
t with another output -- e.g.,</div><div style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br=
></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)" class=3D"gmail_default">&lt;s&gt; &lt;n&gt; OP_CISV OP_D=
ROP &lt;pk&gt; OP_CHECKSIGVERIFY</div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">&=
lt;h, i&gt; &lt;n&gt; OP_CIOV OP_DROP &lt;pk&gt; OP_CHECKSIGVERIFY</div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)" class=3D"gmail_default"></div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">=
<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)" class=3D"gmail_default">Let&#39;s look at CISV first:=
</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gm=
ail_default">1) Assume that &lt;s&gt; is from the same owner as PK</div><di=
v style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)" class=3D"gmail_default">2) Assume that &lt;s&gt; is from a differe=
nt owner than PK</div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div st=
yle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0=
,0)" class=3D"gmail_default">In case 1, the wallet can create or recreate t=
he appropriate output as needed if it gets spent/stuck</div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvetica,sa=
ns-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">In case =
2, the wallet can get &quot;frozen&quot; in a reorg until a signer on &lt;s=
&gt; re-spends.</div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">F=
or CIOV:</div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default">1) Assume that &lt;h, i&gt; exists in the chain somewh=
ere</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default">2) Assume that &lt;h, i&gt; ex=
ists in the mempool somewhere<br></div><div style=3D"font-family:arial,helv=
etica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">=
3) Assume that &lt;h, i&gt; does not exist (or, is provably non-creatable -=
- h =3D txid(x) | x.IsValid() =3D=3D false)</div><div style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail=
_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default">In case 2, this is =
just a fancy op-return.</div><div style=3D"font-family:arial,helvetica,sans=
-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div>=
<div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)" class=3D"gmail_default">Case 1 degrades into case 2 in the even=
t of a reorg.</div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">In Case 2, if the output &lt;h, i&gt; is spent in=
 another transaction, our script becomes provably unspendable (unless a sec=
ond reorg).</div><div style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">Otherwise, it is possible to mine a block with ou=
r transaction.</div><div style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">Co=
mpare the above to normal transactions:</div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_def=
ault"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default">1) If a reorg occurs, a=
nd someone double-spends, your transaction gets cancelled.</div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">2) You can re-sign your UTXO onto a different tra=
nsaction</div><div style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" cla=
ss=3D"gmail_default">However, if you have deleted your key (e.g. using a pr=
e-signing HSM), or your transaction was using a multi-sig with an uncoopera=
ting party, you will have an output that may be effectively burned.</div><d=
iv style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:arial=
,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_defa=
ult">These issues are -- as with CTV -- not present in the single input use=
 case.<br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D=
"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" c=
lass=3D"gmail_default">Thus I argue that CTV -- whose semantics are less po=
werful/flexible than CISV/CIOV -- aren&#39;t introducing something that&#39=
;s not already present when doing protocols involving more than one input.<=
br></div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D=
"gmail_default">Further, on CTV &quot;monotonic authorization&quot;:</div><=
div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_def=
ault">Generally we want Bitcoin Scripts to have the property that once a co=
ndition is reached, it is &#39;permanently&#39; a true case. E.g., showing =
a hash preimage to C x, H(x) =3D=3D C. This can&#39;t change with the weath=
er or anything else. Even things like timelocks -- although not obvious at =
first glance -- have this property. They express logic that says &quot;give=
n the chain is at this height, ...&quot;. This means that on any chain at s=
uch a height the txn is valid. CISV/CIOV semantics also fall in line with t=
his description. It says, &quot;given such an input U, ...&quot;. If that i=
nput is realizable one time, it is provably realizable across reorgs. Howev=
er, that doesn&#39;t mean someone couldn&#39;t interrupt U from being creat=
ed. But generally, with Reorg + Double spend, or Reorg &gt; 100 blocks (pot=
entially destroying CB reward), all bets are off as to the replay-ability o=
f transactions.</div><div style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div sty=
le=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,=
0)" class=3D"gmail_default">I want to also point out that this &quot;revoca=
tion&quot; property -- to the extent it is something new that can&#39;t alr=
eady be emulated with pre-signeds or RBF -- is entirely opt-in as far as CT=
V is concerned. You have to specify that an output can only be spent with a=
nother, most wallets shouldn&#39;t do that, and it can&#39;t &quot;infect&q=
uot; other wallets to an extent more than spending from any recently confir=
med output exposes you to more reorg risk.</div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_=
default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><b>In sum, we do not=
 need to worry about this for CTV.</b><br></div><div style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_=
default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
" class=3D"gmail_default">Lastly, I want to note that revocation is part of=
 what CTV is designed to do (absent reorgs). It allows us to prune spending=
 conditions by playing a transaction forward.</div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default"><br></div><div style=3D"font-family:arial,helvetica,sans-serif;=
font-size:small;color:rgb(0,0,0)" class=3D"gmail_default">E.g., spending co=
nditions {Alice &amp; Bob, Preimage(H(X)) + Eve, CTV({Alice &amp; Bob}, 1 d=
ay)}</div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-=
family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=
=3D"gmail_default">Expresses that Eve has 1 day to reveal the preimage to H=
(X), otherwise Alice and Bob can take the coin back by removing Eve&#39;s H=
TLC path. What&#39;s cool about this revocation v.s. just {Alice &amp; Bob,=
 Preimage(H(X)) + Eve} is that Alice and Bob don&#39;t need to coordinate a=
 multisig to revoke Eve.<br></div><div style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gmail_default"><br><=
/div><div style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)" class=3D"gmail_default"><br></div><div style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)" class=3D"gma=
il_default"><br></div></div><div dir=3D"ltr">--<br><a href=3D"https://twitt=
er.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://tw=
itter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><b=
r><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, =
Feb 14, 2020 at 3:17 AM Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.=
com">dp@simplexum.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,20=
4);padding-left:1ex">I decided to take this thread back on-list because I b=
eleive that the<br>
&#39;revocation utxo&#39; feature enabled by OP_CTV commiting to scriptSig =
may<br>
have wider implications that can slightly change the behavior of Bitcoin<br=
>
as a system, and some might not expect such changes or might not find<br>
them desireable (although there is already a case for such behaviour<br>
with RBF).<br>
<br>
There is a principle that some find valuable: &quot;During reorgs of depth<=
br>
less than 100, it is always possible to eventually replay transactions<br>
from the old branch into the new branch as long as no double spends are<br>
attempted&quot; (quoted from Russel O&#39;Connor from the discussion about<=
br>
&#39;revocation utxo&#39; on Elements Slack channel).<br>
<br>
As far as I can tell, this principle can be violated with the use of<br>
RBF: &quot;(tx) that was included in branch A and then RBF-ed (tx&#39;) in =
branch<br>
B and then branch A wins -&gt; children of (tx&#39;) can&#39;t be replayed&=
quot;<br>
<br>
Some may hold an opinion that introducing new rules that violate that<br>
principle should be done with caution.<br>
<br>
The &#39;revocation utxo&#39; feature enabled by OP_CTV essentially introdu=
ces<br>
a manually triggered &#39;inverse timelock&#39; -=C2=A0 normal timelocks ma=
ke tx<br>
invalid until certain point in time, and inverse timelock make tx<br>
invalid _after_ certain point in time, in this case by spending an<br>
unrelated UTXO.<br>
<br>
In a reorg, one branch can have that UTXO spent before the OP_CTV<br>
transaction that depends on it is included in the block, and the OP_CTV<br>
transaction and its children can&#39;t be replayed.<br>
<br>
This is the same issue as an &#39;automatic inverse timelock&#39; that coul=
d<br>
be enforced by the structure of the transaction itself, if there was<br>
appropriate mechanism, with the difference that &#39;revocation utxo&#39; i=
s<br>
manually triggered.<br>
<br>
The absense of &#39;automatic inverse timelock&#39; mechanism in Bitcoin hi=
nts<br>
that it was not seen as desireable historically. I was not able to find<br>
the relevant discussions, though.<br>
<br>
I would like to add that the behaviour enabled by inverse timelocks<br>
could be useable in various schemes with covenants, like the vaults<br>
with access revocable by spending the &#39;revocation utxo&#39;, or in the<=
br>
trustless lending schemes where the covenant scripts can enforce<br>
different amounts of interest paid to lender based on the point in time<br>
when the loan is returned - the obsolete script paths (with smaller<br>
interest paid) can be disabled by inverse timelock.<br>
<br>
=D0=92 Fri, 13 Dec 2019 23:37:19 -0800<br>
Jeremy &lt;<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit=
.edu</a>&gt; wrote:<br>
<br>
&gt; That&#39;s a cool use case. I&#39;ve thought previously about an<br>
&gt; OP_CHECKINPUT, as a separate extension. Will need to think about if<br=
>
&gt; your construction introduces a hash cycle (unless<br>
&gt; SIGHASH_ALL|SIGHASH_ANYONECANPAY is used it seems likely).<br>
&gt; <br>
&gt; Also re signatures I think it&#39;s definitely possible to pick a<br>
&gt; (signature, message) pair and generate a pk from it, but in general<br=
>
&gt; the Bitcoin message commits to the pk so forging isn&#39;t possible.<b=
r>
&gt; <br>
&gt; On Fri, Dec 13, 2019, 11:25 PM Dmitry Petukhov &lt;<a href=3D"mailto:d=
p@simplexum.com" target=3D"_blank">dp@simplexum.com</a>&gt;<br>
&gt; wrote:<br>
&gt; <br>
&gt; &gt; Another idea for smart vaults:<br>
&gt; &gt;<br>
&gt; &gt; The ability to commit to scriptSig of a non-segwit input could be=
<br>
&gt; &gt; used for on-chain control of spending authorization (revoking the=
<br>
&gt; &gt; spending authorization), where CTV ensures that certain input is<=
br>
&gt; &gt; present in the transaction.<br>
&gt; &gt;<br>
&gt; &gt; scriptSig of that input can contain a signature that commits to<b=
r>
&gt; &gt; certain prevout. Unless it is possible to forge an identical<br>
&gt; &gt; signature (and I don&#39;t know how strong are guarantees of that=
),<br>
&gt; &gt; such an input can only be valid if that prevout was not spent.<br=
>
&gt; &gt;<br>
&gt; &gt; Thus spending such prevout makes it impossible to spend the input=
<br>
&gt; &gt; with CTV that commits to such scriptSig, in effect revoking an<br=
>
&gt; &gt; ability to spend this input via CTV path, and alternate spending<=
br>
&gt; &gt; paths should be used (like, another taproot branch)<br>
&gt; &gt;<br>
&gt; &gt;<br>
&gt; &gt; =D0=92 Fri, 13 Dec 2019 15:06:59 -0800<br>
&gt; &gt; Jeremy via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.li=
nuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org<=
/a>&gt;<br>
&gt; &gt; =D0=BF=D0=B8=D1=88=D0=B5=D1=82: <br>
&gt; &gt; &gt; I&#39;ve prepared a draft of the changes noted above (some s=
mall<br>
&gt; &gt; &gt; additional modifications on the StandardTemplateHash describ=
ed in<br>
&gt; &gt; &gt; the BIP), but have not yet updated the main branches for the=
 BIP<br>
&gt; &gt; &gt; to leave time for any further feedback.<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; See below:<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; BIP:<br>
&gt; &gt; &gt; <a href=3D"https://github.com/JeremyRubin/bips/blob/ctv-v2/b=
ip-ctv.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/J=
eremyRubin/bips/blob/ctv-v2/bip-ctv.mediawiki</a><br>
&gt; &gt; &gt; Implementation:<br>
&gt; &gt; &gt; <a href=3D"https://github.com/JeremyRubin/bitcoin/tree/check=
templateverify-v2" rel=3D"noreferrer" target=3D"_blank">https://github.com/=
JeremyRubin/bitcoin/tree/checktemplateverify-v2</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Thank you for your feedback,<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; Jeremy<br>
&gt; &gt; &gt; --<br>
&gt; &gt; &gt; @JeremyRubin &lt;<a href=3D"https://twitter.com/JeremyRubin"=
 rel=3D"noreferrer" target=3D"_blank">https://twitter.com/JeremyRubin</a>&g=
t;<br>
&gt; &gt; &gt; &lt;<a href=3D"https://twitter.com/JeremyRubin" rel=3D"noref=
errer" target=3D"_blank">https://twitter.com/JeremyRubin</a>&gt;=C2=A0 <br>
&gt; &gt;<br>
&gt; &gt;=C2=A0 <br>
<br>
</blockquote></div>

--0000000000006e187b059e8e0b07--