summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuke Dashjr <luke@dashjr.org>2022-01-18 21:19:02 +0000
committerbitcoindev <bitcoindev@gnusha.org>2022-01-18 21:19:22 +0000
commita02ebb54348385525cf7f694f5f6222e88129180 (patch)
tree7b21490e6824ac1bac81d6a17109fd3355020cbd
parentf0a316a06f8cec50047c89228bb953fcf5545b14 (diff)
downloadpi-bitcoindev-a02ebb54348385525cf7f694f5f6222e88129180.tar.gz
pi-bitcoindev-a02ebb54348385525cf7f694f5f6222e88129180.zip
[bitcoin-dev] CTV BIP review
-rw-r--r--1d/bf475c2846020e7b4eee1b204cd8024e4ebacd180
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
+