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
|
Return-Path: <beppeben2030@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 98A50C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Mar 2023 20:18:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 6652360D90
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Mar 2023 20:18:35 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6652360D90
Authentication-Results: smtp3.osuosl.org;
dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
header.a=rsa-sha256 header.s=20210112 header.b=OAxlERs0
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level:
X-Spam-Status: No, score=-1.848 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_ENVFROM_END_DIGIT=0.25, 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 smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 3Svnun-7fUed
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Mar 2023 20:18:34 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 64BD660BEA
Received: from mail-yw1-x1136.google.com (mail-yw1-x1136.google.com
[IPv6:2607:f8b0:4864:20::1136])
by smtp3.osuosl.org (Postfix) with ESMTPS id 64BD660BEA
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 1 Mar 2023 20:18:34 +0000 (UTC)
Received: by mail-yw1-x1136.google.com with SMTP id
00721157ae682-536af432ee5so388087087b3.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 01 Mar 2023 12:18:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20210112; t=1677701913;
h=to:subject:message-id:date:from:mime-version:from:to:cc:subject
:date:message-id:reply-to;
bh=rI434RSC9QPeW16YJQJVC4Wz1MfBKki0Kqsrygn9hS0=;
b=OAxlERs0mkAgoYBHZTe2u2v8EC/qn9MpIcTduHZyAjUBwjCCwI7lxyFaSv19G54CPM
SHEMvXUpHdhvHDmoD6HU2BLxkiqEAxdQ00r80FmiX9xfiGvr551LZw2lYQT0Fgtrxbsw
JbhjzMpWILh83zGqJ5aQDRubPd7CYnVRb+ZeiXtSyEargWRk+iw6I9rIKm7ACiGyQG7a
KNah8dqDW/A/cd2Tt7VdX/8P+jG898AnL7NL6lFRrAIlyRkc2aH2sAPDQfPYJCIheUrL
0mNPHCUlIKBO/uibKxo1Etrzt+YuAl/ngLACq+JzZSTCuDOXvz6mg/W8NlrjX3xTtYeL
DqTA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112; t=1677701913;
h=to:subject:message-id:date:from:mime-version:x-gm-message-state
:from:to:cc:subject:date:message-id:reply-to;
bh=rI434RSC9QPeW16YJQJVC4Wz1MfBKki0Kqsrygn9hS0=;
b=Rva97sidqFJahlLKlswRDjeR52W6F80kHvxr1uR6K8CvV8d+21gU8UXGcEbqTKWUpP
QuObZLRkPUJRRkxZZZGVcdnGNVOysXGuBoGZQTaMn0IzfE0k3GsKAGAEyh5bYyY6chTx
v5M+cdurTQXA/3JNAaOjMmWmy9WlS3VDx8u0F2L3w+kJCySsnm6yw1mpQHLHtbJflMbV
nAaH3huGHDKhbbuC/CoJs0Cgd5fJSTLKcbQuHH0y8PAg821w3iTrpdwv4HozTkYHB/5D
vft1xTeJ8RQsoa0D2zJggCLi9yDYNcLsZPFr2onY1NRt3qK5bK5uI39ZhEbe5TWF6Son
1oOw==
X-Gm-Message-State: AO0yUKXK5BFTsmwPFoN/vq2hMyadSQimwMkjBEwqmoOCQLiyv8c24lYl
f5Iz6vUd0k8z89q2NbDvQACMtS4hhxw2UqWV7yliGjeu
X-Google-Smtp-Source: AK7set+yaufIs4Yvzi1ofjufC+K0aczM2bGgBLPDLmeHzKcmarZ+Zma+TxNQjWMH/1JTJ5ez8MplWGB1D2U99QRZovc=
X-Received: by 2002:a81:b619:0:b0:524:5bc5:a3d5 with SMTP id
u25-20020a81b619000000b005245bc5a3d5mr4734386ywh.4.1677701913010; Wed, 01 Mar
2023 12:18:33 -0800 (PST)
MIME-Version: 1.0
From: Giuseppe B <beppeben2030@gmail.com>
Date: Wed, 1 Mar 2023 21:18:22 +0100
Message-ID: <CABrXkXoq4x9aRuk0ZnfPmqE-TXZfROMuAMTwCO9VCcTnJ+snNA@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000090658c05f5dc6af7"
X-Mailman-Approved-At: Wed, 01 Mar 2023 20:24:52 +0000
Subject: [bitcoin-dev] Minimum fees
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: Wed, 01 Mar 2023 20:18:35 -0000
--00000000000090658c05f5dc6af7
Content-Type: text/plain; charset="UTF-8"
Hello everyone,
I'm relatively new here so what I'm proposing could have already been
discussed, or may be flawed or inapplicable. I apologize for that.
I was picturing a situation where block rewards are almost zero, and the
base layer is mainly used as a settlement layer for relatively few large
transactions, since the majority of smaller ones goes through LN.
In such a case it may very well be that even if transaction amounts are
very consistent, transaction fees end up being very small since there is
enough space for everyone in a block. Users wouldn't mind paying higher
fees as they know that that would increase the network security, however
nobody wants to be the only one doing that. Miners would of course like
being paid more. So everyone involved would prefer higher fees but they
just stay low because that's the only rational individual choice.
Therefore I was imagining the introduction of a new protocol rule,
min_fees, that would work like this:
- the miner that gets to mine a block appends a min_fee field to the block,
specifying the minimum fees that need to be contained in the following
block in order for it to be valid.
- one can also mine an empty block and reset the min_fee, to avoid the
chain getting stuck.
min_fees could either represent the total fees of the following block, or
the minimal fee for each single transaction, as a percentage of the value
transacted. Both seem to have some merits and some potential drawbacks. Of
course min_fees=0 would correspond to the current situation.
It looks to me that this could have the potential to bring the equilibrium
closer to a socially optimal one (as opposed to individually optimal), and
to benefit the network security in the long term. Of course it's just a
rough sketch and it would deserve a much deeper analysis. I was just
interested in knowing if you think that the principle has some merit or if
it's not even worth discussing it for some reason that I'm not considering.
Cheers,
Giuseppe.
--00000000000090658c05f5dc6af7
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hello everyone,<div><br></div><div>I'm relatively new =
here so what I'm proposing could have already been discussed, or may be=
flawed or inapplicable. I apologize for that.</div><div><br></div><div>I w=
as picturing a situation where block rewards are almost zero, and the base =
layer is mainly used as a settlement layer for relatively few large transac=
tions, since the majority of smaller ones goes through LN.</div><div><br></=
div><div>In such a case it may very well be that even if transaction amount=
s are very consistent, transaction fees end up being very small since there=
is enough space for everyone in a block. Users wouldn't mind paying hi=
gher fees as they know that that would increase the network security, howev=
er nobody wants to be the only one doing that. Miners would of course like =
being paid more. So everyone involved would prefer higher fees but they jus=
t stay low because that's the only rational individual choice.</div><di=
v><br></div><div>Therefore I was imagining the introduction of a new protoc=
ol rule, min_fees, that would work like this:=C2=A0</div><div>- the miner t=
hat gets to mine a block appends a min_fee field to the block, specifying t=
he minimum fees that need to be contained in the following block in order f=
or it to be valid.</div><div>- one can also mine an empty block and reset t=
he min_fee, to avoid the chain getting stuck.</div><div><br></div><div>min_=
fees could either represent the total fees of the following block, or the m=
inimal fee for each single transaction, as a percentage of the value transa=
cted. Both seem to have some merits and some potential drawbacks. Of course=
min_fees=3D0 would correspond to the current situation.</div><div><br></di=
v><div>It looks to me that this could have the potential to bring the equil=
ibrium closer to a socially optimal one (as opposed to individually optimal=
), and to benefit the network security in the long=C2=A0term. Of course it&=
#39;s just a rough sketch and it would deserve a much deeper analysis. I wa=
s just interested in knowing if you think that the principle has some merit=
or if it's not even worth=C2=A0discussing it for some reason that=C2=
=A0I'm=C2=A0not considering.</div><div><br></div><div>Cheers,</div><div=
><br></div><div>Giuseppe.</div><div><br></div></div>
--00000000000090658c05f5dc6af7--
|
