diff options
author | Luke Dashjr <luke@dashjr.org> | 2022-01-18 21:19:02 +0000 |
---|---|---|
committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-18 21:19:22 +0000 |
commit | a02ebb54348385525cf7f694f5f6222e88129180 (patch) | |
tree | 7b21490e6824ac1bac81d6a17109fd3355020cbd | |
parent | f0a316a06f8cec50047c89228bb953fcf5545b14 (diff) | |
download | pi-bitcoindev-a02ebb54348385525cf7f694f5f6222e88129180.tar.gz pi-bitcoindev-a02ebb54348385525cf7f694f5f6222e88129180.zip |
[bitcoin-dev] CTV BIP review
-rw-r--r-- | 1d/bf475c2846020e7b4eee1b204cd8024e4ebacd | 180 |
1 files changed, 180 insertions, 0 deletions
diff --git a/1d/bf475c2846020e7b4eee1b204cd8024e4ebacd b/1d/bf475c2846020e7b4eee1b204cd8024e4ebacd new file mode 100644 index 000000000..eef3e6857 --- /dev/null +++ b/1d/bf475c2846020e7b4eee1b204cd8024e4ebacd @@ -0,0 +1,180 @@ +Return-Path: <luke@dashjr.org> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id DF127C002F + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jan 2022 21:19:22 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id D235E400E4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jan 2022 21:19:22 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -0.201 +X-Spam-Level: +X-Spam-Status: No, score=-0.201 tagged_above=-999 required=5 + tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, + SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no +Authentication-Results: smtp2.osuosl.org (amavisd-new); + dkim=pass (1024-bit key) header.d=dashjr.org +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id x0KxKc702QmW + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jan 2022 21:19:21 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 +Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) + by smtp2.osuosl.org (Postfix) with ESMTP id B4968400E3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jan 2022 21:19:21 +0000 (UTC) +Received: from ishibashi.lan (unknown [12.151.133.18]) + (Authenticated sender: luke-jr) + by zinan.dashjr.org (Postfix) with ESMTPSA id 7673938A1D95 + for <bitcoin-dev@lists.linuxfoundation.org>; + Tue, 18 Jan 2022 21:19:12 +0000 (UTC) +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=dashjr.org; s=zinan; + t=1642540759; bh=PvgBQ8XxJ0zJ3WXENBP8LhM2crjEp0Yo/kxD6bOpSmI=; + h=From:To:Subject:Date; + b=toDmnjwZvaz/WXhrsXzSEoVG0RXi4RH0I4acXvxudFFyg60z2Sv9oLIziE6ilzFU0 + 8WvVHxgFAmHm0ZgOa//c4Yu4dcs6MBrs8cwmZxkHyp4VLSLR6DIAbAXpYBvRKSvJNE + KDkAq9UmR2GS6RgWNyyWx2AQiXN/JEZQKNHSYi4w= +X-Hashcash: 1:25:220118:bitcoin-dev@lists.linuxfoundation.org::/TbQNSQJ1ubEFoKc:afsTu +From: Luke Dashjr <luke@dashjr.org> +To: bitcoin-dev@lists.linuxfoundation.org +Date: Tue, 18 Jan 2022 21:19:02 +0000 +User-Agent: KMail/1.9.10 +MIME-Version: 1.0 +Content-Type: Text/Plain; + charset="us-ascii" +Content-Transfer-Encoding: 7bit +Content-Disposition: inline +Message-Id: <202201182119.02687.luke@dashjr.org> +Subject: [bitcoin-dev] CTV BIP review +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: Tue, 18 Jan 2022 21:19:23 -0000 + +tl;dr: I don't think CTV is ready yet (but probably close), and in any case +definitely not worth reviving BIP 9 with its known flaws and vulnerability. + +My review here is based solely on the BIP, with no outside context (aside from +current consensus rules, of course). In particular, I have _not_ looked at +the CTV code proposed for Bitcoin Core yet. + +>Covenants are restrictions on how a coin may be spent beyond key ownership. + +nit: Poorly phrased. Even simple scripts can do that already. + +>A few examples are described below, which should be the subject of future +non-consensus standardization efforts. + +I would ideally like to see fully implemented BIPs for at least one of these +(preferably the claimed CoinJoin improvements) before we move toward +activation. + +>Congestion Controlled Transactions + +I think this use case hasn't been fully thought through yet. It seems like it +would be desirable for this purpose, to allow any of the recipients to claim +their portion of the payment without footing the fee for every other payment +included in the batch. This is still a covenant-type solution, but one that +BIP 119 cannot support as-is. + +(I realise this may be a known and accepted limitation, but I think it should +be addressed in the BIP) + +>Payment Channels + +Why batch mere channel creation? Seems like the spending transaction should +really be the channel closing. + +>CHECKTEMPLATEVERIFY makes it much easier to set up trustless CoinJoins than +previously because participants agree on a single output which pays all +participants, which will be lower fee than before. + +I don't see how. They still have to agree in advance on the outputs, and the +total fees will logically be higher than not using CTV...? + +>Further Each participant doesn't need to know the totality of the outputs +committed to by that output, they only have to verify their own sub-tree will +pay them. + +I don't see any way to do this with the provided implementation. + +>Deployment could be done via BIP 9 VersionBits deployed through Speedy Trial. + +Hard NACK on this. BIP 9 at this point represents developers attempting to +disregard and impose their will over community consensus, as well as an +attempt to force a miner veto backdoor/vulnerability on deployment. It should +never be used again. + +Speedy Trial implemented with BIP 8 made sense* as a possible neutral +compromise between LOT=True and LOT=False (which could be deployed prior to +or in parallel), but using BIP 9 would destroy this. + +As with Taproot, any future deployments should use BIP 8 again, until a better +solution is developed. Reverting back to a known flawed and vulnerable +activation method should not be done, and it would be better not to deploy +CTV at all at such an expense. + +The fact that certain developers attempted to deploy a BIP 9 alternative +activation for Taproot against community consensus, and that even managed to +get released as "Bitcoin Core", makes it all the more important that the +community firmly rejects any further action to force this regression. + +* it is my opinion a BIP 8 ST would be an okay compromise under those +circumstances; others do disagree that ST is acceptable at all + +> This ensures that for a given known input, the TXIDs can also be known ahead +of time. Otherwise, CHECKTEMPLATEVERIFY would not be usable for Batched +Channel Creation constructions as the redemption TXID could be malleated and +pre-signed transactions invalidated, unless the channels are built using an +Eltoo-like protocol. + +Why is it a problem for them to use an Eltoo-like protocol? + +Why not just commit to the txid itself if that's the goal? + +>P2SH is incompatible with CHECKTEMPLATEVERIFY + +Maybe the CTV opcode should only be defined/enforced within witness scripts? + +>nLockTime should generally be fixed to 0 (in the case of a payment tree, only +the *first* lock time is needed to prevent fee-sniping the root) + +Your "Congestion Controlled Transactions" example would only make sense with +the spending transaction much later than the "root", and so could benefit +from fee sniping malleability. (In fact, in that example, it would be better +not to commit to locktime at all.) + +>In the CHECKTEMPLATEVERIFY approach, the covenants are severely restricted to +simple templates. The structure of CHECKTEMPLATEVERIFY template is such that +the outputs must be known exactly at the time of construction. Based on a +destructuring argument, it is only possible to create templates which expand +in a finite number of steps. + +It's not clear to me that this holds if OP_CAT or OP_SHA256STREAM get added. + +>For example, a exchange's hot wallet might use an address which can +automatically be moved to a cold storage address after a relative timeout. + +Wouldn't it make more sense to just have a UTXO both cold+hot can spend, then +throw away the hot key? + +>In contrast to previous forks, OP_CHECKTEMPLATEVERIFY will not make scripts +valid for policy until the new rule is active. + +Policy isn't validity, and cannot be dictated by BIPs (or anyone/anything, for +that matter). + +Luke + |