diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2020-02-15 00:24:37 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2020-02-15 00:24:47 +0000 |
| commit | 6c2074bc4d9f7edae1abc01919272d7d4ae2c8eb (patch) | |
| tree | 73e243c94125d0bcc4624446caf86a97adb0e3ff | |
| parent | 50adfefca415b5db94e39df88e71b65e665d8b70 (diff) | |
| download | pi-bitcoindev-6c2074bc4d9f7edae1abc01919272d7d4ae2c8eb.tar.gz pi-bitcoindev-6c2074bc4d9f7edae1abc01919272d7d4ae2c8eb.zip | |
Re: [bitcoin-dev] BIP OP_CHECKTEMPLATEVERIFY
| -rw-r--r-- | 1a/d038d262a35babe108c80c74989d085001de53 | 185 |
1 files changed, 185 insertions, 0 deletions
diff --git a/1a/d038d262a35babe108c80c74989d085001de53 b/1a/d038d262a35babe108c80c74989d085001de53 new file mode 100644 index 000000000..51d654957 --- /dev/null +++ b/1a/d038d262a35babe108c80c74989d085001de53 @@ -0,0 +1,185 @@ +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 + + + |