From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D97BEC0051 for ; 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 ; 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 ; 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 ; 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 ; Thu, 3 Sep 2020 13:34:28 -0400 Received: by mail-ed1-f41.google.com with SMTP id q21so3527549edv.1 for ; 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: <20191214122546.5e72eb93@simplexum.com> <20200214161826.5d334196@simplexum.com> <20200903194223.7e763393@simplexum.com> In-Reply-To: <20200903194223.7e763393@simplexum.com> From: Jeremy Date: Thu, 3 Sep 2020 10:34:15 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Dmitry Petukhov Content-Type: multipart/alternative; boundary="000000000000f0ecd305ae6c297c" Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov 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
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.




=
On Thu, Se= p 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--