Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY

From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: Dmitry Petukhov <dp@simplexum•com>,
	Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
Date: Sat, 15 Feb 2020 00:24:37 +0000	[thread overview]
Message-ID: <gXEzmtRxbi3CsDzhsaNe5KZ-yMuGoi6UMvsi1JThl1fQB2zLQoM4Z3N_qnkwY7iqFF9TCJzwN8e7kGqvCVgi3suMEp3nDGFaE5DVFDhJNEk=@protonmail.com> (raw)
In-Reply-To: <20200214161826.5d334196@simplexum.com>

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 exception 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 implemented as a double-spend of a precommitted `OP_CTV`, so that also is exempted from the principle.

As Jeremy notes as well, the *actual* principle is that "a script that is valid now remains valid in the future" (as this is required by the script cache implementation of Bitcoin Core), and this principle does not mention UTXOs, only scripts; the existence or non-existence of a required UTXO is separate here.
Thus, an "automatic inverse timelock" is not possible to implement with **only** script (it implies that a script that is valid now will become invalid in the future), but requires some action on the blockchain (notice that HTLCs effectively implement an "inverse timelock" on the hash-branch participant, 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.
>
> В 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)
> > > В Fri, 13 Dec 2019 15:06:59 -0800
> > > Jeremy via bitcoin-dev bitcoin-dev@lists•linuxfoundation.org
> > > пишет:
> > >
> > > > 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