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
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 89F82C002D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2022 01:22:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 525F3403FD
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2022 01:22:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 525F3403FD
Authentication-Results: smtp2.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=qZ9GK751
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KzHUwXA0eWsd
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2022 01:22:08 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org CAEFD40185
Received: from mail-vs1-xe2a.google.com (mail-vs1-xe2a.google.com
[IPv6:2607:f8b0:4864:20::e2a])
by smtp2.osuosl.org (Postfix) with ESMTPS id CAEFD40185
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 4 Aug 2022 01:22:07 +0000 (UTC)
Received: by mail-vs1-xe2a.google.com with SMTP id 125so19693509vsd.5
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 03 Aug 2022 18:22:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=+VHeXKBdAZAHMB81Xly/+jMREfWBswftMirjWN9SUeY=;
b=qZ9GK7513Rnr1hEzxmJQm8LYKDHtpTDt2WCAY7SufhnKETwzhfzDuR/YykMkN2Ld9p
3OPaVDb5T25Sxd4c9C+cA9Qa+TQyTRiGClHKAXpRes2CEkfX9krPi8WgnaCUmZoeVJbp
8tsFHk7ztQpjXWwMAbdX/09s4flLo3rvu6q5HcfURTNiOXMP447iTQ+o6bpcIc2mf/SA
CF3JH3QOWxRlx8M5j6ujTgUWJkuyyHwnt/DnsEHRzz8Fre4MKW8TrUVFE7oNNBnnZnE7
MlZ6spnfME7FOn8DH4QEsMXuebIn3ZxHygRLEQ2YbBqzjfBnphE3d6p2sr9CgQjx77XZ
6Svg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=+VHeXKBdAZAHMB81Xly/+jMREfWBswftMirjWN9SUeY=;
b=UHr9TVHfVMOBA+/sGWquGpQQsRCDJrGxjm99flHBfzLd7QWhE40+tGV4hAWPk+Xc2S
KZv9qce0vJNDO4gdbQ+oSa2SMNS+6GrsxSkImsLHi+0bjr1I0LeOLthfzeCOgdh7vUU6
j3XRXdOilGYFnuB87ZiIlqIRMVFLgjjQISGBdGm78ChmesQZjG6KXNNMDXfCZPlX7DUT
zx5c07K/k7J2Xb8jiLTVg6H2eWHSZQ/qzYtvVc9AKiV/WICkOc2Sdtj3vzUZ8iYV08wa
36+gICRb8j4+Y1MLFgwA2z0p1Y6T14b/KB++2gmjJ1vjk0Ron9FtvBRlVxbHZ/OHhZ0+
DGhg==
X-Gm-Message-State: ACgBeo3BAcziOUMuY7fqFyvJ3J3LZAnQBXcpO4qT/OzqvubYuvu5XuFo
hflFw86uBqVpvVoaUZ3wC5QsbSvwXQKswkCUXhkmGlGwLS1RQA==
X-Google-Smtp-Source: AA6agR6KNLXbFDdVWkkXODLYq4sIIbkkWzJ39hv0428SkfuoZupe0+6qf+KXMlncF+dtKZEX0Mp6aWpAyzy83A/h5nk=
X-Received: by 2002:a67:dd12:0:b0:384:ce1e:1e84 with SMTP id
y18-20020a67dd12000000b00384ce1e1e84mr6486781vsj.39.1659576126219; Wed, 03
Aug 2022 18:22:06 -0700 (PDT)
MIME-Version: 1.0
References: <CAGHFe1BsDnxn6nuoMwCtt56YjaXmT0mPZ6XnMJZpyC2Fa7e9aQ@mail.gmail.com>
<166123291-fe0f05975e84c5e295606d87fdddcd64@pmq3v.m5r2.onet>
<CAGHFe1BYPhewOH6o+EMuWFhkFsn4DUYtc9ziFinVw8PHVR9tJg@mail.gmail.com>
In-Reply-To: <CAGHFe1BYPhewOH6o+EMuWFhkFsn4DUYtc9ziFinVw8PHVR9tJg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 3 Aug 2022 20:21:51 -0500
Message-ID: <CAGpPWDbdCVYy7M=kv26oHJQHqi1VXd0eSpnLTceXrdWmkCq6Dw@mail.gmail.com>
To: aaradhya@technovanti.co.in, Aaradhya Chauhan <chauhanansh.me@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000007b2b1905e5602da8"
X-Mailman-Approved-At: Thu, 04 Aug 2022 10:16:54 +0000
Subject: Re: [bitcoin-dev] Regarding setting a lower minrelaytxfee
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, 04 Aug 2022 01:22:09 -0000
--0000000000007b2b1905e5602da8
Content-Type: text/plain; charset="UTF-8"
I agree with Peter, it seems like we don't need a dust limit with full
blocks. And we should expect blocks to remain full indefinitely.
However, if we were to still have a dust limit, it shouldn't be a simple
constant. It should be determined by the mempool environment. Eg one could
define the dust limit to be the 5th percentile lowest fee in the last 100
blocks. Or the 1st percentile. Etc. This way, as the value of bitcoin
fluctuates (inevitably affecting the fees people are willing to pay), the
dust limit would automatically adjust to compensate. One might worry that
in high fee environments, the dust limit calculated this way might make for
too-high dust limits. But I don't think you could really say it would be
"too high" because it would match the actual mempool. We could have a
maximum dust limit set if that's a worry tho.
On Wed, Aug 3, 2022 at 5:35 PM Aaradhya Chauhan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Thank you for answering. I'll check out the link you provided, while also
> playing around with the fee settings for my own full node, at my home
> server.
>
> On Wed, 3 Aug 2022 at 23:02, vjudeu via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> It is possible, because you can find nodes that accept low-fee
>> transactions. And on some statistics, for example
>> https://jochen-hoenicke.de/queue/#BTC,24h,weight,0 you can see that zero
>> to one satoshi per virtual byte transactions could take more space than
>> other transactions. You can be convinced that those charts are not fake by
>> running a full node and reaching some nodes with different fee settings. If
>> miners don't want to accept them, well, it is their choice to leave that
>> money on the table. As long as the basic block reward is sufficient, they
>> don't have to accept such low fee transactions, because they can wait
>> instead, to receive them in some batched form.
>>
>> Also, some miners could accept only 10 sats/vB or higher, because why
>> not. As long as your transaction will reach enough nodes to be confirmed,
>> you can safely pick lower fees. For now, de-facto standard is one satoshi
>> per virtual byte, but:
>>
>> 1) it is only declared, so you can rely only on declarations, not on hard
>> consensus rules
>> 2) there is no way to make sure if some transaction was truly rejected by
>> some miner, or maybe it was saved somewhere
>> 3) you can never be sure if some node is a miner and can enforce those
>> different fee rules or not
>>
>> So, you can really judge only by how nodes behave, you cannot make sure
>> in any way if anyone is running some additional rules. And fees are not a
>> part of the consensus, so they can be freely adjusted by each node, and
>> there is no way to make sure, what rules are really executed, you can only
>> assume that, based on what transactions are included in blocks.
>>
>>
>>
>> On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>> So, can we conclude by something, whether or not it would be possible and
>> feasible in the future?
>>
>>
>> On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail
>> wrote:
>> > > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev
>> wrote:
>> > > like a hashcash-based alternative broadcast scheme.
>> > Hi Peter,
>> > I've been mulling the idea of attaching work to low fee txns, both as a
>> compensation (e.g., in a sidechain, or an alt), and/or as a spam proof.
>> Unfortunately, both suffer from ASICs:
>> > For spam proof case, the adversary can easily buy a used/obsolete
>> device to produce lots of spam txns very cheaply, unless you put the bar
>> very high, making it almost impossible for average users to even try.
>> > The compensation scenario is pretty off-topic, still, interesting
>> enough for 1 min read:
>> > Wallets commit to the latest blockchain state in the transaction AND
>> attach work.
>> > It is considered contribution to the security (illegitimate chains
>> can't include the txn), hence isrewarded by fee discount/exemption
>> depending on the offset of the state they've committed to (the closer, the
>> better) and the amount of work attached.
>> > For this to work, block difficulty is calculated inclusive with the
>> work embedded in the txns, it contains. Sophisticated and consequential,
>> yet not infeasible per se.
>> >
>> > Unfortunately, this scheme is hard to balance with ASICs in the scene
>> too, for instance, you can't subsidize wallets for their work like with a
>> leverge, because miners can easily do it locally, seizing the subsidies for
>> themselves, long story, not relevant just ignore it.
>>
>> We're not talking about a consensus system here. Just a way to rate-limit
>> access to a broadcast network used by a small minority of nodes. It's
>> completely ok to simply change the PoW algorithm in the _highly_ unlikely
>> event
>> someone bothers to build an ASIC for it. Since this isn't a consensu
>> system,
>> it's totally ok if multiple versions of the scheme run in parallel.
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000007b2b1905e5602da8
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div id=3D"gmail-:6gh" class=3D"gmail-Am gmail-aO9 gmail-A=
l editable gmail-LW-avf gmail-tS-tW gmail-tS-tY" aria-label=3D"Message Body=
" role=3D"textbox" aria-multiline=3D"true" tabindex=3D"1" style=3D"directio=
n:ltr;min-height:85px">I agree with Peter, it seems like we don't need =
a dust limit with full blocks. And we should expect blocks to remain full i=
ndefinitely.=C2=A0<div><br></div><div>However, if we were to still have a d=
ust limit, it shouldn't be a simple constant. It should be determined b=
y the mempool environment. Eg one could define the dust limit to be the 5th=
percentile lowest fee in the last 100 blocks. Or the 1st percentile. Etc. =
This way, as the value of bitcoin fluctuates (inevitably affecting the fees=
people are willing to pay), the dust limit would automatically adjust to c=
ompensate. One might worry that in high fee environments, the dust limit ca=
lculated this way might make for too-high dust limits. But I don't thin=
k you could really say it would be "too high" because it would ma=
tch the actual mempool. We could have a maximum dust limit set if that'=
s a worry tho.</div></div></div><br><div class=3D"gmail_quote"><div dir=3D"=
ltr" class=3D"gmail_attr">On Wed, Aug 3, 2022 at 5:35 PM Aaradhya Chauhan v=
ia bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org"=
>bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote =
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px sol=
id rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Thank you for answer=
ing. I'll check out the link you provided, while also playing around wi=
th the fee settings for my own full node, at my home server.=C2=A0</div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Wed, 3=
Aug 2022 at 23:02, vjudeu via bitcoin-dev <<a href=3D"mailto:bitcoin-de=
v@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfound=
ation.org</a>> wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">It is possible, because you can find nodes that accept low-fee t=
ransactions. And on some statistics, for example <a href=3D"https://jochen-=
hoenicke.de/queue/#BTC,24h,weight,0" rel=3D"noreferrer" target=3D"_blank">h=
ttps://jochen-hoenicke.de/queue/#BTC,24h,weight,0</a> you can see that zero=
to one satoshi per virtual byte transactions could take more space than ot=
her transactions. You can be convinced that those charts are not fake by ru=
nning a full node and reaching some nodes with different fee settings. If m=
iners don't want to accept them, well, it is their choice to leave that=
money on the table. As long as the basic block reward is sufficient, they =
don't have to accept such low fee transactions, because they can wait i=
nstead, to receive them in some batched form.<br>
<br>
Also, some miners could accept only 10 sats/vB or higher, because why not. =
As long as your transaction will reach enough nodes to be confirmed, you ca=
n safely pick lower fees. For now, de-facto standard is one satoshi per vir=
tual byte, but:<br>
<br>
1) it is only declared, so you can rely only on declarations, not on hard c=
onsensus rules<br>
2) there is no way to make sure if some transaction was truly rejected by s=
ome miner, or maybe it was saved somewhere<br>
3) you can never be sure if some node is a miner and can enforce those diff=
erent fee rules or not<br>
<br>
So, you can really judge only by how nodes behave, you cannot make sure in =
any way if anyone is running some additional rules. And fees are not a part=
of the consensus, so they can be freely adjusted by each node, and there i=
s no way to make sure, what rules are really executed, you can only assume =
that, based on what transactions are included in blocks.<br>
<br>
<br>
<br>
On 2022-08-03 18:19:12 user Aaradhya Chauhan via bitcoin-dev <<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-de=
v@lists.linuxfoundation.org</a>> wrote:<br>
So, can we conclude by something, whether or not it would be possible and f=
easible in the future?<br>
<br>
<br>
On Mon, 1 Aug 2022 at 19:08, Peter Todd via bitcoin-dev <<a href=3D"mail=
to:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lis=
ts.linuxfoundation.org</a>> wrote:<br>
<br>
On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote=
:<br>
> > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-de=
v wrote:<br>
> > like a hashcash-based alternative broadcast scheme.<br>
> Hi Peter,<br>
> I've been mulling the idea of attaching work to low fee txns, both=
as a compensation (e.g., in a sidechain, or an alt), and/or as a spam proo=
f. Unfortunately, both suffer from ASICs:<br>
> For spam proof case, the adversary can easily buy a used/obsolete devi=
ce to produce lots of spam txns very cheaply, unless you put the bar very h=
igh, making it almost impossible for average users to even try.<br>
> The compensation scenario is pretty off-topic, still, interesting enou=
gh for 1 min read:<br>
> Wallets commit to the latest blockchain state in the transaction AND a=
ttach work.<br>
> It is considered contribution to the security (illegitimate chains can=
't include the txn), hence isrewarded by fee discount/exemption dependi=
ng on the offset of the state they've committed to (the closer, the bet=
ter) and the amount of work attached.<br>
> For this to work, block difficulty is calculated inclusive with the wo=
rk embedded in the txns, it contains. Sophisticated and consequential, yet =
not infeasible per se.<br>
><br>
> Unfortunately, this scheme is hard to balance with ASICs in the scene =
too, for instance, you can't subsidize wallets for their work like with=
a leverge, because miners can easily do it locally, seizing the subsidies =
for themselves, long story, not relevant just ignore it.<br>
<br>
We're not talking about a consensus system here. Just a way to rate-lim=
it<br>
access to a broadcast network used by a small minority of nodes. It's<b=
r>
completely ok to simply change the PoW algorithm in the _highly_ unlikely e=
vent<br>
someone bothers to build an ASIC for it. Since this isn't a consensu sy=
stem,<br>
it's totally ok if multiple versions of the scheme run in parallel.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000007b2b1905e5602da8--
|