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 D97BEC0051
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 17:34:30 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id D4D1E8742D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 17:34:30 +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 u0y7299fvcYd
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 17:34:29 +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 7A3A987431
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu,  3 Sep 2020 17:34:29 +0000 (UTC)
Received: from mail-ed1-f41.google.com (mail-ed1-f41.google.com
 [209.85.208.41]) (authenticated bits=0)
 (User authenticated as jlrubin@ATHENA.MIT.EDU)
 by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 083HYRqC015311
 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT)
 for <bitcoin-dev@lists.linuxfoundation.org>; Thu, 3 Sep 2020 13:34:28 -0400
Received: by mail-ed1-f41.google.com with SMTP id q21so3527549edv.1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 03 Sep 2020 10:34:27 -0700 (PDT)
X-Gm-Message-State: AOAM533eK8w953q/+ureR0XTjVw7fJXB3TBqHo+QaNZUp3j9bbq9vKT6
 ipYo32ntSpAfMousPndraWTREzJA5Xlksds26jk=
X-Google-Smtp-Source: ABdhPJzwZDgNvmXjWtLt6ttMeFLRPvHIcV6nBaBmGmW4TiY5xiYf5N5RF4XTepxeYR028q9nTYQdTKpEcuySyFzJ1qk=
X-Received: by 2002:a50:84a2:: with SMTP id 31mr4454080edq.138.1599154466907; 
 Thu, 03 Sep 2020 10:34:26 -0700 (PDT)
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>
 <CAD5xwhg9xx780i8e=Y9jpj4GBfcjEf+MQ_ap9osi2n6ZQMTN3Q@mail.gmail.com>
 <20200903194223.7e763393@simplexum.com>
In-Reply-To: <20200903194223.7e763393@simplexum.com>
From: Jeremy <jlrubin@mit.edu>
Date: Thu, 3 Sep 2020 10:34:15 -0700
X-Gmail-Original-Message-ID: <CAD5xwhgb8xoZXue=R4ktENGLffvBQOKNBUsfZS+DZXBSK4NezA@mail.gmail.com>
Message-ID: <CAD5xwhgb8xoZXue=R4ktENGLffvBQOKNBUsfZS+DZXBSK4NezA@mail.gmail.com>
To: Dmitry Petukhov <dp@simplexum.com>
Content-Type: multipart/alternative; boundary="000000000000f0ecd305ae6c297c"
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: Thu, 03 Sep 2020 17:34:31 -0000

--000000000000f0ecd305ae6c297c
Content-Type: text/plain; charset="UTF-8"

CTV does not enable this afaiu because it does not commit to the inputs
(otherwise there's a hash cycle for predicting the output's TXID.


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


On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov <dp@simplexum.com> wrote:

> Just had an idea that an an "inverse timelock" can be made
> almost-certainly automatic: a revocation UTXO shall become
> anyone-can-spend after a timeout, and bear some non-dust amount.
>
> Before the timelock expiration, it shall be spendable only along with
> the covenant-locked 'main' UTXO (via a signature or mutual covenant)
>
> This way, after a timeout expires, a multitude of entities will be
> incentivized to spend this UTXO, because this would be free money for
> them. It will probably be spend by a miner, as they can always replace
> the spending transaction with their own and claim the amount.
>
> After the revocation UTXO is spent, the covenant path that commits to
> having it in the inputs will be unspendable, and this would effectively
> constitute an "inverse timelock".
>
>
>

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

<div dir=3D"ltr"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:#000000">CTV does=
 not enable this afaiu because it does not commit to the inputs (otherwise =
there&#39;s a hash cycle for predicting the output&#39;s TXID.</div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:#000000"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:#000000"><br cl=
ear=3D"all"></div><div><div dir=3D"ltr" class=3D"gmail_signature" data-smar=
tmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D"https://twitter=
.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://twit=
ter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><br>=
<div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Se=
p 3, 2020 at 7:39 AM Dmitry Petukhov &lt;<a href=3D"mailto:dp@simplexum.com=
">dp@simplexum.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote=
" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);=
padding-left:1ex">Just had an idea that an an &quot;inverse timelock&quot; =
can be made<br>
almost-certainly automatic: a revocation UTXO shall become<br>
anyone-can-spend after a timeout, and bear some non-dust amount.<br>
<br>
Before the timelock expiration, it shall be spendable only along with<br>
the covenant-locked &#39;main&#39; UTXO (via a signature or mutual covenant=
)<br>
<br>
This way, after a timeout expires, a multitude of entities will be<br>
incentivized to spend this UTXO, because this would be free money for<br>
them. It will probably be spend by a miner, as they can always replace<br>
the spending transaction with their own and claim the amount.<br>
<br>
After the revocation UTXO is spent, the covenant path that commits to<br>
having it in the inputs will be unspendable, and this would effectively<br>
constitute an &quot;inverse timelock&quot;.<br>
<br><br>
</blockquote></div></div>

--000000000000f0ecd305ae6c297c--