From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 75594C0037; Thu, 25 Jan 2024 12:58:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 5D0C240883; Thu, 25 Jan 2024 12:58:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 5D0C240883 Authentication-Results: smtp4.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=BpTnZLZL X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.799 X-Spam-Level: X-Spam-Status: No, score=-2.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ogr5Tkhoelb9; Thu, 25 Jan 2024 12:58:06 +0000 (UTC) Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com [188.165.51.139]) by smtp4.osuosl.org (Postfix) with ESMTPS id 338A5402D2; Thu, 25 Jan 2024 12:58:06 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 338A5402D2 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1706187478; x=1706446678; bh=H2dYql4M8Nc0tk4FxcDs69dBvrpnwGSy/60IBfmBv24=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=BpTnZLZLRJaSdTy+YkyKqNuOSJJoqOqriOMhJCds4+x1I7THw9SndTgnyifE9FJiw Z1F34nDMu+sCy+lT/GrkixuqktZn8n2uLKFbB0XAHn2li8X5cjwJxWcDUm5iAH4RCg X+A4/Lpa7a6X4D3+A1rR6XEMO69BWmN2ezcxhRF6Phj2VNXhvfIdmJ+edr97pcqqBK UCubhFsevX1urTYY6Mu4ZlZAeI7mL1M2tA1qLyJDbTxnx0g2yXYmh7rRqu7FxGmigg eamoGPa+mTnjWnPzruzbDBGhKpsBt0RfDFaXLokhsobCkx0WB4Z5csEcOF4bTtwJtu q/DTFC3SaEFsQ== Date: Thu, 25 Jan 2024 12:57:52 +0000 To: Peter Todd From: Michael Folkson Message-ID: <4619vs2aZBsW1lr3ihqjM6TdRgx8CuA_wRwXetu7jZZcL8r3oWUy7xOPkT-qJ0xxT79_Ss6it2chOWAAWPJuU8YSCzjaNOd6JvnMvWTBc-c=@protonmail.com> In-Reply-To: References: Feedback-ID: 27732268:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Thu, 25 Jan 2024 16:15:04 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org, Lightning Dev Subject: Re: [bitcoin-dev] CheckTemplateVerify Does Not Scale Due to UTXO's Required For Fee Payment 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: Thu, 25 Jan 2024 12:58:07 -0000 Hi Peter Interesting post. By implicitly committing in advance to the fee paid by th= e spending transaction CTV is certainly nailing its colors to the CPFP mast= rather than operating in a RBF world. And in a future high fee environment= (ignoring whatever is driving those high fees, monetary or non-monetary us= e cases) as you state paying for an additional CPFP transaction is suboptim= al rather than just replacing an existing unconfirmed transaction.=20 I did a cursory search to look for an in depth technical comparison of CPFP= and RBF and I found this from Antoine (Poinsot) on Bitcoin StackExchange [= 0]. In that he states his view that: "If most nodes didn't enforce mandatory BIP125 signalling, RBF would be sup= erior in all aspects to CPFP from the perspective of the emitter of transac= tion. CPFP is much less efficient, and not always possible: you need the tr= ansaction to have a change output and (at least at the time of writing [0])= the parent to pass policy checks on its own, for instance if it's below th= e minimum feerate of most mempools on the network you won't be able to CPFP= it at the moment." I assume that a CTV based LN-Symmetry also has this drawback when compared = to an APO based LN-Symmetry? In theory at least an APO based LN-Symmetry co= uld change the fees in every channel update based on what the current marke= t fee rate was at the time of the update. In today's pre LN-Symmetry world = you are always going to have justice transactions for revoked states that w= ere constructed when the market fee rate was very different from the presen= t day's market fee rate. Thanks Michael [0]: https://bitcoin.stackexchange.com/questions/117703/comparison-between-= cpfp-and-bip125-for-fee-bumping -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin On Wednesday, 24 January 2024 at 19:31, Peter Todd via bitcoin-dev wrote: > CheckTemplateVerify(1) is a proposed covenant opcode that commits to the > transaction that can spend an output. Namely, # of inputs, # of outputs, > outputs hash, etc. In practice, in many if not most CTV use-cases intende= d to > allow multiple parties to share a single UTXO, it is difficult to impossi= ble to > allow for sufficient CTV variants to cover all possible fee-rates. It is > expected that CTV would be usually used with anchor outputs to pay fees; = by > creating an input of the correct size in a separate transaction and inclu= ding > it in the CTV-committed transaction; or possibly, via a transaction spons= or > soft-fork. >=20 > This poses a scalability problem: to be genuinely self-sovereign in a pro= tocol > with reactive security, such as Lightning, you must be able to get transa= ctions > mined within certain deadlines. To do that, you must pay fees. All of the > intended exogenous fee-payment mechanisms for CTV require users to have a= t > least one UTXO of suitable size to pay for those fees. >=20 > This requirement for all users to have a UTXO to pay fees negates the > efficiency of CTV-using UTXO sharing schemes, as in an effort to share a = UTXO, > CTV requires each user to have an extra UTXO. The only realistic alternat= ive is > to use a third party to pay for the UTXO, eg via a LN payment, but at tha= t > point it would be more efficient to pay an out-of-band mining fee. That o= f > course is highly undesirable from a mining centralization perspective.(2) >=20 > Recommendations: CTV in its current form be abandoned as design foot-gun.= Other > convenant schemes should be designed to work well with replace-by-fee, to= avoid > requirements for extra UTXOs, and to maximize on-chain efficiency. >=20 > 1) https://github.com/bitcoin/bips/blob/deae64bfd31f6938253c05392aa355bf6= d7e7605/bip-0119.mediawiki > 2) https://petertodd.org/2023/v3-transactions-review#anchor-outputs-are-a= -danger-to-mining-decentralization >=20 > -- > https://petertodd.org 'peter'[:-1]@petertodd.org > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev