From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1183FC0037 for ; Thu, 25 Jan 2024 17:49:46 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id DBDF36147B for ; Thu, 25 Jan 2024 17:49:45 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DBDF36147B Authentication-Results: smtp3.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=RQIGh4sc X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pK-wWVFNusgU for ; Thu, 25 Jan 2024 17:49:45 +0000 (UTC) Received: from mail-0201.mail-europe.com (mail-0201.mail-europe.com [51.77.79.158]) by smtp3.osuosl.org (Postfix) with ESMTPS id DBD7161475 for ; Thu, 25 Jan 2024 17:49:44 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org DBD7161475 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1706204977; x=1706464177; bh=i7czRvjW8iiQxrjle2sTu/gPWGLKdXG0KLcXV19c4qA=; 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=RQIGh4scdI5W5T0Q+gPrxhagykNX4AiCA8g3/lDBZGaLqkK30ZkdINElI+WexaF13 JNTyrWZ03qboxbF3DQySZf7wwd4auiJUx69WLGa44PN5jqpW/D36GqLJ6L78iuiAf8 bUWEcIG0Yer5B5SiYSwLxJWehOOJ42HzJfUDaK8lTIXklK5x5UoziRudWHM70q86rk KKvm4Z+Vew2whlcrlUWOcYU6uk9d9ftYlhZS4CyH2bXMMpEV7OferOfjULn1E+lJal qxkGxv+3/XRL/gLDBCMKMqen2keY4amOdcRJuFFACm0ldFHRJxxa6ENLBNsqW0iGbN VMdDQ711A7HCg== Date: Thu, 25 Jan 2024 17:49:26 +0000 To: Peter Todd From: jlspc Message-ID: In-Reply-To: References: Feedback-ID: 36436663:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 26 Jan 2024 00:56:47 +0000 Cc: bitcoin-dev@lists.linuxfoundation.org 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 17:49:46 -0000 Hi Peter, If feerate-dependent timelocks (FDTs) (1) are supported, it would be possib= le to use CTV to define a transaction with a fixed fee and no anchor output= s, as long as it's racing against a transaction with an FDT. Regards, John (1) https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-December= /004254.html Sent with Proton Mail secure email. On Wednesday, January 24th, 2024 at 11:31 AM, 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