From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from whitealder.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 323C6C0051 for ; Thu, 3 Sep 2020 17:47:52 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by whitealder.osuosl.org (Postfix) with ESMTP id 1F29586C7F for ; Thu, 3 Sep 2020 17:47:52 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from whitealder.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DWcADFrpLYM8 for ; Thu, 3 Sep 2020 17:47:51 +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 whitealder.osuosl.org (Postfix) with ESMTPS id 1545286C7C for ; Thu, 3 Sep 2020 17:47:50 +0000 (UTC) Received: from mail-ej1-f52.google.com (mail-ej1-f52.google.com [209.85.218.52]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 083Hlmor020774 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NOT) for ; Thu, 3 Sep 2020 13:47:49 -0400 Received: by mail-ej1-f52.google.com with SMTP id p9so5036079ejf.6 for ; Thu, 03 Sep 2020 10:47:49 -0700 (PDT) X-Gm-Message-State: AOAM531cV/a8gQTfKdzxbmD+AdDf/0ojeyO2a5jBsNvVGjf+4FMDiF9v dWd2x+p5IT48UGvXVBOPMYlMaJjNvTGcC6iKsvo= X-Google-Smtp-Source: ABdhPJwCwll8rB1FfbaaKYDKtNHxVGK9SMLF03N8glhO3o01NSS+NIDoquaCmyKhP5vM+V6smIfyXBKq67iwx6WWZwU= X-Received: by 2002:a17:907:728e:: with SMTP id dt14mr3383610ejc.4.1599155268308; Thu, 03 Sep 2020 10:47:48 -0700 (PDT) MIME-Version: 1.0 References: <20191214122546.5e72eb93@simplexum.com> <20200214161826.5d334196@simplexum.com> <20200903194223.7e763393@simplexum.com> In-Reply-To: From: Jeremy Date: Thu, 3 Sep 2020 10:47:35 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Jeremy Content-Type: multipart/alternative; boundary="000000000000b5585505ae6c5985" 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:47:52 -0000 --000000000000b5585505ae6c5985 Content-Type: text/plain; charset="UTF-8" It's also not something that's trivial to set up in any scheme because you have to have an ordering around when you set up the tx intended to be the inverse lock before you create the tx using it. -- @JeremyRubin On Thu, Sep 3, 2020 at 10:34 AM Jeremy wrote: > 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". >> >> >> --000000000000b5585505ae6c5985 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
It's= also not something that's trivial to set up in any scheme because you = have to have an ordering around when you set up the tx intended to be the i= nverse lock before you create the tx using it.




On Thu, Sep 3, 2020 at 10:= 34 AM Jeremy <jlrubin@mit.edu>= wrote:
CTV does not enable this afaiu becaus= e it does not commit to the inputs (otherwise there's a hash cycle for = predicting the output's TXID.

<= /div>

On Thu, Sep 3, 2020 at 7:39 AM Dmitry Petukhov <dp@simplexum.com> wrote:
<= /div>
Just had an idea tha= t 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".


--000000000000b5585505ae6c5985--