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
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
|
Return-Path: <vjudeu@gazeta.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id B68CDC002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 11:03:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 7759960E61
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 11:03:10 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 7759960E61
Authentication-Results: smtp3.osuosl.org;
dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl
header.a=rsa-sha256 header.s=2013 header.b=oeni8/Dg
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.1
X-Spam-Level:
X-Spam-Status: No, score=-2.1 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_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-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 8UP2XYRrG3Ea
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 11:03:08 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 3E28F60AE5
Received: from smtpa40.poczta.onet.pl (smtpa40.poczta.onet.pl [213.180.142.40])
by smtp3.osuosl.org (Postfix) with ESMTPS id 3E28F60AE5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 11 May 2023 11:03:07 +0000 (UTC)
Received: from pmq2v.m5r2.onet (pmq2v.m5r2.onet [10.174.32.68])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4QH8BV62WjzlgPxj;
Thu, 11 May 2023 13:02:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013;
t=1683802978; bh=YetZSZ+FXsrPokdBdwB5KLtgmfR8ex8z54Z2mBX0KmE=;
h=From:Cc:To:In-Reply-To:Date:Subject:From;
b=oeni8/Dg142uU0Ffka40RwGNNrs/gyravT1Ry/t7SR/2qdf7+hUrckfUZeWbgiUaA
Tz3noRIcOLbhGowKNdllVYjySiT2aseVnpFY+2j27DDsA7FmNqLCvXY4cYWhyhqfJP
5+XQPp9SY1yKRRXCFIFoAm79LL6XYI6Y5f2CQcSc=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [5.173.232.218] by pmq2v.m5r2.onet via HTTP id ;
Thu, 11 May 2023 13:02:58 +0200
From: vjudeu@gazeta.pl
X-Priority: 3
To: Erik Aronesty <erik@q32.com>
In-Reply-To: <CAJowKgLx796AWaZAMOGVWFsT2LK8zvCvxiY-sv110gv1cewCwg@mail.gmail.com>
Date: Thu, 11 May 2023 13:02:57 +0200
Message-Id: <171698970-6184d5f773dee0589bf3373c44b9f21f@pmq2v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <vjudeu@gazeta.pl>;5.173.232.218;PL;2
X-Mailman-Approved-At: Thu, 11 May 2023 11:54:39 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] tx max fee
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: Thu, 11 May 2023 11:03:10 -0000
> confused. the rule was "cannot pay a fee > sum of outputs with consider=
ation of cpfp in the mempool"
> your example is of someone paying a fee "< sum" which wouldn't be blocked
Every transaction paying "fee > sum" can be replaced by N transactions payi=
ng "fee <=3D sum", where the sum of all fees will be the same. That means, =
someone will still do the same thing, but it will be just expanded into N t=
ransactions, so you will reach the same outcome, but splitted into more tra=
nsactions. That means, mempool will be even more congested, because for exa=
mple instead of 1kB transaction with huge fee, you will see 100 such transa=
ctions with smaller fees, that will add to the same amount, but will just c=
onsume more space.
> show me how someone could move 1 btc and pay 2 btc as fees...
In the previous example, I explained how someone could move 1k sats and pay=
almost 1 BTC as fees. But again, assuming that you have 3 BTC, and you mov=
e 1 BTC with 2 BTC fee, that will be rejected by your rules if and only if =
that will be done in a single transaction. But hey, the same owner can prep=
are N transactions upfront, and release them all at the same time, Segwit m=
akes it possible without worrying about malleability.
So, instead of:
3 BTC -> 1 BTC
You can see this:
3 BTC -> 2 BTC -> 1 BTC
If that second transaction will not pass CPFP, more outputs could be used:
+--------------------+--------------------+--------------------+
| 3.0 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC | 0.5 BTC -> 0.5 BTC |
| 0.5 BTC | 0.5 BTC 0.5 BTC | 0.5 BTC |
| 0.5 BTC | 0.5 BTC +--------------------+
| +--------------------+
| 0.5 BTC | 0.5 BTC -> 0.5 BTC |
| 0.5 BTC | 0.5 BTC |
+--------------------+--------------------+
As you can see, there are four transactions, each paying 0.5 BTC fee, so th=
e total fee is 2 BTC. However, even if you count it as CPFP, you will get 1=
.5 BTC in fees for the third transaction in the chain. Note that more outpu=
ts could be used, or they could be wired a bit differently, and then if you=
will look at the last transaction, the sum of all fees from 10 or 15 trans=
actions in that chain, could still pass your limits, but the whole tree wil=
l exceed that. If you have 1.5 BTC limit for that 3 BTC, then you could hav=
e 20 separate chains of transactions, each paying 0.1 BTC in fees, and it w=
ill still sum up to 2 BTC.
> the only way around it is to maintain balances and use change addresses. =
which would force nft and timestamp users to maintain these balances and =
would be a deterrent
Not really, because you can prepare all of those transactions upfront, as t=
he part of your protocol, and release all of them at once. You don't have t=
o maintain all UTXOs in between, you can create the whole transaction tree =
first, sign it, and broadcast everything at once. More than that: if you ha=
ve HD wallet, you only need to store a single key, and generate all address=
es in-between on-the-fly, as needed. Or even use some algorithm to determin=
istically recreate the whole transaction tree.
On 2023-05-10 19:42:49 user Erik Aronesty <erik@q32.com> wrote:
confused.=C2=A0 =C2=A0the rule was "cannot pay a fee > sum of outputs with =
consideration of cpfp in the mempool"
your example is of someone paying a fee "< sum"=C2=A0 which wouldn't be blo=
cked
note: again, i'm not a fan of this, i like the discussion=C2=A0of "bitcoin =
as money only" and using fee as a lever to do that
show me how someone could move 1 btc and pay 2 btc as fees... i think we ca=
n block it at the network or even the consensus layer, and leave anything b=
ut "non-monetary use cases" intact.=C2=A0 =C2=A0the only way around it is t=
o maintain balances and use change addresses.=C2=A0 =C2=A0which would force=
nft and timestamp users to maintain these balances and would be a deterrent
im am much more in favor of=C2=A0doing=C2=A0something like op_ctv which all=
ows many users to pool fees and essentially "share" a single utxo.
.
=C2=A0=C2=A0
On Wed, May 10, 2023 at 12:19=E2=80=AFPM <vjudeu@gazeta.pl> wrote:
> possible to change tx "max fee"=C2=A0 to output amounts?
Is it possible? Yes. Should we do that? My first thought was "maybe", but a=
fter thinking more about it, I would say "no", here is why:
Starting point: 1 BTC on some output.
Current situation: A single transaction moving 0.99999000 BTC as fees, and =
creating 1000 satoshis as some output (I know, allowed dust values are lowe=
r and depend on address type, but let's say it is 1k sats to make things si=
mpler).
And then, there is a room for other solutions, for example your rule, menti=
oned in other posts, like this one: https://lists.linuxfoundation.org/piper=
mail/bitcoin-dev/2023-May/021626.html
> probably easier just to reject any transaction where the fee is higher th=
an the sum of the outputs
Possible situation after introducing your proposal, step-by-step:
1) Someone wants to move 1 BTC, and someone wants to pay 0.99999000 BTC as =
fees. Assuming your rules are on consensus level, the first transaction cre=
ates 0.5 BTC output and 0.5 BTC fee.
2) That person still wants to move 0.5 remaining BTC, and still is willing =
to pay 0.49999000 BTC as fees. Guess what will happen: you will see another=
transaction, creating 0.25 BTC output, and paying 0.25 BTC fee.
...
N) Your proposal replaced one transaction, consuming maybe one kilobyte, wi=
th a lot of transactions, doing exactly the same, but where fees are distri=
buted between many transactions.
Before thinking about improving that system, consider one simple thing: is =
it possible to avoid "max fee rule", no matter in what way it will be defin=
ed? Because as shown above, the answer seems to be "yes", because you can a=
lways replace a single transaction moving 1 BTC as fees with multiple trans=
actions, each paying one satoshi per virtual byte, and then instead of cons=
uming around one kilobyte, it would consume around 1 MvB per 0.01 BTC, so 1=
00 MvB per 1 BTC mentioned in the example above.
On 2023-05-08 13:55:18 user Erik Aronesty via bitcoin-dev <bitcoin-dev@list=
s.linuxfoundation.org> wrote:
possible to change tx "max fee"=C2=A0 to output amounts?
seems like the only use case that would support such a tx is spam/dos type =
stuff that satoshi warned about
its not a fix for everything, but it seems could help a bit with certain at=
tacks=C2=A0
|
