path: root/48/cdb494ae33ff00bdeedbae0e33c020b78d8844

Return-Path: <dp@simplexum.com>
Received: from fraxinus.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id D2967C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 11:17:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by fraxinus.osuosl.org (Postfix) with ESMTP id C1B6F86521
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 11:17:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from fraxinus.osuosl.org ([127.0.0.1])
 by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id AF3S6o8RApwE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 11:17:03 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from mail.ruggedbytes.com (mail.ruggedbytes.com [88.99.30.248])
 by fraxinus.osuosl.org (Postfix) with ESMTPS id D415D86511
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 14 Feb 2020 11:17:02 +0000 (UTC)
Received: from mail.ruggedbytes.com (localhost [127.0.0.1])
 by mail.ruggedbytes.com (Postfix) with ESMTPS id 1277126001C3;
 Fri, 14 Feb 2020 11:17:00 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simplexum.com;
 s=mail; t=1581679020;
 bh=P23hl28csI7TU24JoJiqPdb2bxgMVUf5hlX7yfkfsos=;
 h=Date:From:To:Subject:In-Reply-To:References;
 b=Eq48bz/bmMGWIog6Z/8vU2ZySX49R00wvZkgiIzN6NabO3DnpuKjlZAGlPSpUL5Db
 b0JzgN9umVmLuZDHsGiR0fAWZsa36rLAO0dFLTU2++Z20wFeqsmW7XdNKVlCMJw7Lb
 kptYTa+MVPoEOGXP90tJemiBO6i2YQ1gf0zKmY6E=
Date: Fri, 14 Feb 2020 16:18:26 +0500
From: Dmitry Petukhov <dp@simplexum.com>
To: Jeremy <jlrubin@mit.edu>, Bitcoin Protocol Discussion
 <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200214161826.5d334196@simplexum.com>
In-Reply-To: <CAD5xwhgwhOwuPjKz-0_y7HP=jTi=6wJo8uH6HqCvOndr6wo0+Q@mail.gmail.com>
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>
Organization: simplexum.com
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 14 Feb 2020 12:33:24 +0000
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 11:17:04 -0000

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).
>=20
> 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.
>=20
> On Fri, Dec 13, 2019, 11:25 PM Dmitry Petukhov <dp@simplexum.com>
> wrote:
>=20
> > 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:=20
> > > 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> =20
> >
> > =20