Date: Sat, 15 Feb 2020 00:24:37 +0000
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
Precedence: list

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