From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6EED7C0177 for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <20200214161826.5d334196@simplexum.com> References: <20191214122546.5e72eb93@simplexum.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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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