path: root/1a/d038d262a35babe108c80c74989d085001de53

Return-Path: <ZmnSCPxj@protonmail.com>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 6EED7C0177
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Feb 2020 00:24:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by hemlock.osuosl.org (Postfix) with ESMTP id 5D0E28822B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Feb 2020 00:24:47 +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 dwBtpJgC933n
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Feb 2020 00:24:45 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch
 [185.70.40.135])
 by hemlock.osuosl.org (Postfix) with ESMTPS id 085E288216
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 15 Feb 2020 00:24:44 +0000 (UTC)
Date: Sat, 15 Feb 2020 00:24:37 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=default; t=1581726282;
 bh=52n3QyCJ/hisgHx6MQHr2h0EcuULMPjbJssD20wMqPo=;
 h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:
 Feedback-ID:From;
 b=L5RCqXv1mM4cF9BNjizg1il41XN5gHbRyPJjHLI/4LKJtfjwwIAmqTI3nA9NNk6Pa
 r8FV3iTvX3uGgF/7IOh5GmVHWQA9XsdF4ql7LyWinnvXBDcW34ckPuaF3pDiuUDs+A
 bbtlqlLIk8mQ3r2EQ5/HCjH1aFErL/1ooDC4/h7Q=
To: Dmitry Petukhov <dp@simplexum.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Message-ID: <gXEzmtRxbi3CsDzhsaNe5KZ-yMuGoi6UMvsi1JThl1fQB2zLQoM4Z3N_qnkwY7iqFF9TCJzwN8e7kGqvCVgi3suMEp3nDGFaE5DVFDhJNEk=@protonmail.com>
In-Reply-To: <20200214161826.5d334196@simplexum.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>
 <20200214161826.5d334196@simplexum.com>
Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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: Sat, 15 Feb 2020 00:24:47 -0000

Good morning Dmitry, and Jeremy,


> 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"

But an RBF-ed transaction *is* a double-spend, and the principle makes an e=
xception specifically for double-spends.
Thus RBF, and other double-spends, are exempt from this principle.

My vague understanding of the "revocation UTXO" feature is that it is imple=
mented as a double-spend of a precommitted `OP_CTV`, so that also is exempt=
ed from the principle.

As Jeremy notes as well, the *actual* principle is that "a script that is v=
alid now remains valid in the future" (as this is required by the script ca=
che implementation of Bitcoin Core), and this principle does not mention UT=
XOs, only scripts; the existence or non-existence of a required UTXO is sep=
arate here.
Thus, an "automatic inverse timelock" is not possible to implement with **o=
nly** script (it implies that a script that is valid now will become invali=
d in the future), but requires some action on the blockchain (notice that H=
TLCs effectively implement an "inverse timelock" on the hash-branch partici=
pant, by threatening a spend (i.e. blockchain activity) by the counterparty=
 if does not comply).

Regards,
ZmnSCPxj



>
> 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).
> > 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.
> > On Fri, Dec 13, 2019, 11:25 PM Dmitry Petukhov dp@simplexum.com
> > wrote:
> >
> > > 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:
> > >
> > > > 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
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev