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
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
|
Return-Path: <lf-lists@mattcorallo.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 5CB17C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 00:12:33 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 478A84094B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 00:12:33 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.802
X-Spam-Level:
X-Spam-Status: No, score=-2.802 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, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=mattcorallo.com
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 eFK4Y_rDkU1m
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 00:12:32 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from mail.as397444.net (mail.as397444.net [69.59.18.99])
by smtp4.osuosl.org (Postfix) with ESMTPS id F00D840218
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Feb 2022 00:12:31 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mattcorallo.com; s=1644536463; h=In-Reply-To:From:References:To:Subject:
From:Subject:To:Cc:Cc:Reply-To;
bh=rmO0ekYeLCUAaNICBYIPNG4wZeuc7DQsufu4HjWQbNY=; b=rYR73806CVdsSMK2ubDaCZOrcQ
S6kj/UZRutJaZxCdQJoLaciA0dTS0PRtTzugH8rTu0VSILMARVmOj9AzXVOcgDVh5szezBqwqfJDd
uqUc4QV/W3OnPoQRxidWwhI5DHIOQO+50otctSYiulsfrjAxtpNNKYPD+2e77WCwDYs/lWegpY06R
OT52Jb7+Hc5tT2TAR1VGHIaiy+TcQIWEt1PRwlDDWFc7foCDepSrapjkXBuwQ3DMOUOSk42e9OjVU
3hrJzJVYbfO70kbLNXytITXHP2/LXdh6VFeAQ9NrLfEivNQ+kPh95TpC7gUiunICKLgcMAcDMgUsg
nrfSC2dA==;
Received: by mail.as397444.net with esmtpsa (TLS1.3) (Exim)
(envelope-from <lf-lists@mattcorallo.com>)
id 1nIJXt-006u7v-1w; Fri, 11 Feb 2022 00:12:17 +0000
Message-ID: <8be86b19-04eb-af12-a54c-e1140ac62e3f@mattcorallo.com>
Date: Thu, 10 Feb 2022 19:12:16 -0500
MIME-Version: 1.0
Content-Language: en-US
To: James O'Beirne <james.obeirne@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
References: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
From: Matt Corallo <lf-lists@mattcorallo.com>
In-Reply-To: <CAPfvXfKrnju1fzxOKs3Fx00NOPWHjedF7e4xMSGs8buwc0O2kw@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-DKIM-Note: Keys used to sign are likely public at
https://as397444.net/dkim/mattcorallo.com
X-DKIM-Note: For more info, see https://as397444.net/dkim/
Subject: Re: [bitcoin-dev] Thoughts on fee bumping
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: Fri, 11 Feb 2022 00:12:33 -0000
This is great in theory, but I think it kinda misses *why* the complexity keeps creeping in. We
agree on (most of) the goals here, but the problem is the goals explicitly lead to the complexity,
its not some software engineering failure or imagination failure that leads to the complexity.
On 2/10/22 14:40, James O'Beirne via bitcoin-dev wrote:
-snip-
> # Purely additive feerate bumps should never be impossible
>
> Any user should always be able to add to the incentive to mine any
> transaction in a purely additive way. The countervailing force here
> ends up being spam prevention (a la min-relay-fee) to prevent someone
> from consuming bandwidth and mempool space with a long series of
> infinitesimal fee-bumps.
>
> A fee bump, naturally, should be given the same per-byte consideration
> as a normal Bitcoin transaction in terms of relay and block space,
> although it would be nice to come up with a more succinct
> representation. This leads to another design principle:
This is where *all* the complexity comes from. If our goal is to "ensure a bump increases a miner's
overall revenue" (thus not wasting relay for everyone else), then we precisely *do* need
> Special consideration for "what should be in the next
> block" and/or the caching of block templates seems like an imposing
> dependency
Whether a transaction increases a miner's revenue depends precisely on whether the transaction
(package) being replaced is in the next block - if it is, you care about the absolute fee of the
package and its replacement. If it is not in the next block (or, really, not near a block boundary
or further down in the mempool where you assume other transactions will appear around it over time),
then you care about the fee *rate*, not the fee difference.
> # The bandwidth and chain space consumed by a fee-bump should be minimal
>
> Instead of prompting a rebroadcast of the original transaction for
> replacement, which contains a lot of data not new to the network, it
> makes more sense to broadcast the "diff" which is the additive
> contribution towards some txn's feerate.
This entirely misses the network cost. Yes, sure, we can send "diffs", but if you send enough diffs
eventually you send a lot of data. We cannot simply ignore network-wide costs like total relay
bandwidth (or implementation runtime DoS issues).
> # Special transaction structure should not be required to bump fees
>
> In an ideal design, special structural foresight would not be needed
> in order for a txn's feerate to be improved after broadcast.
>
> Anchor outputs specified solely for CPFP, which amount to many bytes of
> wasted chainspace, are a hack. > It's probably uncontroversial at this
This has nothing to do with fee bumping, though, this is only solved with covenants or something in
that direction, not different relay policy.
> Coming down to earth, the "tabula rasa" thought experiment above has led
> me to favor an approach like the transaction sponsors design that Jeremy
> proposed in a prior discussion back in 2020[1].
How does this not also fail your above criteria of not wasting block space?
Further, this doesn't solve pinning attacks at all. In lightning we want to be able to *replace*
something in the mempool (or see it confirm soon, but that assumes we know exactly what transaction
is in "the" mempool). Just being able to sponsor something doesn't help if you don't know what that
thing is.
Matt
|
