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
|
Return-Path: <jk_14@op.pl>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 6E295C0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 22:37:53 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 4954380D44
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 22:37:53 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4954380D44
Authentication-Results: smtp1.osuosl.org;
dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
header.s=2011 header.b=SpUh5IE6
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, 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 z51Tu4sCZv0Y
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 22:37:52 +0000 (UTC)
X-Greylist: delayed 00:10:03 by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8DB8B80D3D
Received: from smtpo78.poczta.onet.pl (smtpo78.poczta.onet.pl [141.105.16.28])
by smtp1.osuosl.org (Postfix) with ESMTPS id 8DB8B80D3D
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 2 Mar 2023 22:37:51 +0000 (UTC)
Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4PSQhr6QJwzlg9Yn;
Thu, 2 Mar 2023 23:27:40 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
t=1677796060; bh=l7xxs25ojRAB4Lclx+LMjrDT3onthpwgMsBJ+/3tKBM=;
h=From:Cc:To:Date:Subject:From;
b=SpUh5IE6UfNSBbs2EBX51yqU8Y9/LHz8P/C3MIsoWTPLWJBgRg9G8an8VKmHxm8wd
JOFot9KzcDekMV57uL/aoRr/BNBOPl/gokcLTLFA1rS1AdXX/9f9mgu5Lxr40gW6Fr
xZJZe8brbTrwT7ZrE1ViX7kv7N8peiHlMQFXwoxM=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.64.71] by pmq3v.m5r2.onet via HTTP id ;
Thu, 02 Mar 2023 23:27:40 +0100
From: jk_14@op.pl
X-Priority: 3
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Thu, 02 Mar 2023 23:27:40 +0100
Message-Id: <178815707-0d716bbc84bb687bd2bf6f87ab557532@pmq3v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <jk_144@onet.pl>;89.64.64.71;PL;2
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Thu, 02 Mar 2023 23:20:08 +0000
Subject: Re: [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: Thu, 02 Mar 2023 22:37:53 -0000
> to bring the equilibrium
The important thing to highlight is that's not equilibrium between active u=
sers and miners.
This needed in the future equilibrium is between:
Active Users (transactional tax) vs Passive Users (i.e. stakeholders: infla=
tion tax)
And miners will only earn as much as these two parties above will pay in "t=
axes".
> to benefit the network security in the long=C2=A0term
The solution to benefit the network security in the long term should be sim=
ple enough to understand by Average Joe, in my opinion.
Delay of halving in case of network global hashrate regression - is simple =
enough mechanism that cannot be played.
(more here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Ja=
nuary/021362.html )
Summarizing:
1. There are two parties in Bitcoin with opposite interests from network se=
curity point of view: passive stakeholders and active users.
2. There is (still) no mechanism of achieving equilibrium regarding costs o=
f network security between these two parties.
3a. A system in which all users participate in ensuring its long-term secur=
ity - is honest.
3b. A system in which only active of them participate, and passive stakehol=
ders are de facto long-term dishonest free riders - is not honest.
Every statement above is unfortunately true.
There are only two serious issues in Bitcoin in fact: weak long-term securi=
ty budget and quantum threat.
According to IBM roadmap regarding quantum computing - they may have 4k qub=
it system starting from 2025.
If quantum emergency fork (only several years ahead!) will require not soft=
, but hard version
- that's the one and only chance for fixing simultaneously this serious fla=
w of Bitcoin design, in simplest and most conservative way.
And we need to talk about it now - to be mentally prepared :)
Best Regards
Jaroslaw
W dniu 2023-03-01 21:25:08 u=C5=BCytkownik Giuseppe B via bitcoin-dev <bitc=
oin-dev@lists.linuxfoundation.org> napisa=C5=82:
Hello everyone,
I'm relatively new here so what I'm proposing could have already been discu=
ssed, or may be flawed or inapplicable. I apologize for that.
I was picturing a situation where block rewards are almost zero, and the ba=
se layer is mainly used as a settlement layer for relatively few large tran=
sactions, since the majority of smaller ones goes through LN.
In such a case it may very well be that even if transaction amounts are ver=
y consistent, transaction fees end up being very small since there is enoug=
h 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 wan=
ts to be the only one doing that. Miners would of course like being paid mo=
re. So everyone involved would prefer higher fees but they just stay low be=
cause 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:=C2=A0
- 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 blo=
ck in order for it to be valid.
- one can also mine an empty block and reset the min_fee, to avoid the chai=
n getting stuck.
min_fees could either represent the total fees of the following block, or t=
he minimal fee for each single transaction, as a percentage of the value tr=
ansacted. Both seem to have some merits and some potential drawbacks. Of co=
urse min_fees=3D0 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=C2=A0term. Of course it's just =
a rough sketch and it would deserve a much deeper analysis. I was just inte=
rested 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 c=
onsidering.
Cheers,
Giuseppe.
|
