From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 27774C0037 for ; Sat, 27 Jan 2024 06:39:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id E3C1081442 for ; Sat, 27 Jan 2024 06:39:04 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org E3C1081442 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=reardencode.com header.i=@reardencode.com header.a=rsa-sha256 header.s=mail header.b=O7skkT5p X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.6 X-Spam-Level: X-Spam-Status: No, score=0.6 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TeIEle7VCK8J for ; Sat, 27 Jan 2024 06:39:03 +0000 (UTC) X-Greylist: delayed 598 seconds by postgrey-1.37 at util1.osuosl.org; Sat, 27 Jan 2024 06:39:03 UTC DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 419888143A Received: from mail.reardencode.com (mail.reardencode.com [206.125.169.165]) by smtp1.osuosl.org (Postfix) with ESMTPS id 419888143A for ; Sat, 27 Jan 2024 06:39:03 +0000 (UTC) Date: Fri, 26 Jan 2024 22:28:54 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=reardencode.com; s=mail; t=1706336940; bh=qONT5e9scIvEI3HPGMgA21qLYiXOAxMA1/8Dq9siO4Q=; h=Date:From:To:Subject:References:In-Reply-To; b=O7skkT5plIYlOa1OvwbODH0PMaDE8QYfm8kucvV4lgivq8kH1kHy5gLJrJgVEqmWr 4mkrZmZfRJ3jcMPJQ4DnxThEFkZPTQzFCPaRCNHcrB+O0vFM3oV1MDtyJkgs03v9AH m5J2ztpTQ8CH2uT90JnScOo7erLDZjRIO9ePA1j4= From: Brandon Black To: Peter Todd , Bitcoin Protocol Discussion Message-ID: Mail-Followup-To: Peter Todd , Bitcoin Protocol Discussion References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 6.1.74 x86_64 X-Mailman-Approved-At: Sat, 27 Jan 2024 09:25:53 +0000 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: Sat, 27 Jan 2024 06:39:05 -0000 Hi Peter, On 2024-01-24 (Wed) at 19:31:07 +0000, Peter Todd via bitcoin-dev wrote: > 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 including > it in the CTV-committed transaction; or possibly, via a transaction sponsor > soft-fork. > > This poses a scalability problem: to be genuinely self-sovereign in a protocol > with reactive security, such as Lightning, you must be able to get transactions > 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 at > least one UTXO of suitable size to pay for those fees. I understand your reservations with regard to CTV-based protocols for scaling bitcoin and lightning. Fortunately, the "user gotta have a UTXO" concern is readily answered (and you actually gave one answer to approximately the same concern from me when we discussed lightning fees): If the user's balance inside the protocol is not sufficient to pay exit fees then they aren't going to try to exit; so their in-protocol balance can be used to pay fees. With ephemeral anchors throughout the tree, an exiting user would spend their leaf UTXO, and the ephemeral anchors along the path to their leaf to create a package of the necessary fee rate to facilitate their timely exit. Alternatively, users entering into a channel tree protocol (e.g. Timeout Trees) can have their leaf include a second UTXO commitment which would create a fee-paying output exactly when they need it; without causing a scaling problem. Finally, the reality of these protocol proposals is that they are intended to enable users who may never have sufficient funds to pay the full cost to exit the protocol in on chain fees to use bitcoin in a trust-minimized way. To facilitate this, such a protocol could employ fee insurance which would accept claims for fees to pull a specific exit series on chain via any of the mechanisms you describe. This, by the way, would bring more than one user out of the protocol, so even in the worst case it does scale bitcoin by requiring only 1 fee paying UTXO for log_r(n)*(r-1) users to exit. Hope this helps, --Brandon