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's a hash cycle for predicting the output'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 <<a href=3D"mailto:dp@simplexum.com= ">dp@simplexum.com</a>> 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 "inverse timelock" = 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 'main' 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 "inverse timelock".<br> <br><br> </blockquote></div></div> --000000000000f0ecd305ae6c297c--