1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
|
Return-Path: <freedom@reardencode.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 27774C0037
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <freedom@reardencode.com>
To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <ZbSipq2QQx904Ofo@console>
Mail-Followup-To: Peter Todd <pete@petertodd.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <ZbFle6n0Zu3yUV8o@petertodd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ZbFle6n0Zu3yUV8o@petertodd.org>
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 <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: 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
|
