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
|
Return-Path: <jk_14@op.pl>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 787EEC002A
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 May 2023 09:37:09 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 449A141FA9
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 May 2023 09:37:09 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 449A141FA9
Authentication-Results: smtp4.osuosl.org;
dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
header.s=2011 header.b=dCMBKAc3
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.101
X-Spam-Level:
X-Spam-Status: No, score=-2.101 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_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 smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id KZ-wsDxoEsKA
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 May 2023 09:37:08 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 39F7141F8B
Received: from smtpo46.poczta.onet.pl (smtpo46.poczta.onet.pl
[213.180.142.177])
by smtp4.osuosl.org (Postfix) with ESMTPS id 39F7141F8B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 12 May 2023 09:37:07 +0000 (UTC)
Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25])
by smtp.poczta.onet.pl (Onet) with ESMTP id 4QHkDn5MHyzlgC01;
Fri, 12 May 2023 11:36:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
t=1683884217; bh=y7DP0UDy41NNvnVhbIHA740lpp+9rqVft3T78jamV7o=;
h=From:To:Date:Subject:From;
b=dCMBKAc3jdQ1tNh01zdRKGmZIoPks4VzFVIzWu+M4Z1k38pyyR6j+3UJF+mpAFvV7
z/zyiIFJo7OGWOpOI3+gASriuV24sF6TRCqLbsxlniKPrnrMPakEM0bG2Qo9y2+BFl
KSa0BHJ6f47WGeUe78871CrOSKWXqKOUGNmAvEuE=
Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
Received: from [89.64.64.233] by pmq5v.m5r2.onet via HTTP id ;
Fri, 12 May 2023 11:36:57 +0200
From: jk_14@op.pl
X-Priority: 3
To: Keagan McClelland <keagan.mcclelland@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Date: Fri, 12 May 2023 11:36:57 +0200
Message-Id: <183521277-1292801d11e64541f46cb8f24e3e7829@pmq5v.m5r2.onet>
X-Mailer: onet.poczta
X-Onet-PMQ: <jk_144@onet.pl>;89.64.64.233;PL;2
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Fri, 12 May 2023 09:47:12 +0000
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject
non-standard Taproot transactions from full nodes?
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, 12 May 2023 09:37:09 -0000
W dniu 2023-05-11 13:57:11 u=C5=BCytkownik Keagan McClelland via bitcoin-de=
v <bitcoin-dev@lists.linuxfoundation.org> napisa=C5=82:
> The current fees we are experiencing are still significantly lower than t=
hey need to be if Bitcoin is going to survive in a post-subsidy era. If our=
layered protocols can't survive the current fee environment, the answer is=
to fix the layered protocols.
I also believe that this discussion should be expanded to the problem of Bi=
tcoin's survival in the post-subsidy era, because it's very related, i.e. a=
lso directly related to the high transaction fees. The only difference is t=
hat the current $30 fee situation is probably temporary, and the future $40=
(today's price tag) fee situation in post-subsidy era will be hopeless for=
change other than to reduce the difficulty of the network and hence its se=
curity and the marketcap/price in the end of day.
Because if the current network hashrate (current level of security) would d=
rop e.g. to half of what it was in the past - the Store-of-Value feature si=
mply collapse, while it's one of the most important (if not: the most impor=
tant) long term feature of Bitcoin and as such advertised...
If you really care about SoV - you can't accept network security regression=
. Period.
I am a committed supporter of the free market. And Bitcoin is not the e-mai=
l system, where sending is free and therefore spam which costs nothing to t=
he sender - becomes a problem. In Bitcoin, every transaction costs - and in=
such a situation, distinguishing paid transactions into the good ones and =
the bad ones - would be a mistake and contradict the idea of the free marke=
t.
We should not interfere where the free market intervenes: the same way how =
small transfers are migrating to LN, the same way "non-economic", low value=
informations will migrate to Layer2 (RGB, Taro or maybe something else yet)
But, we should intervene there, where there is no free market. And I am not=
alone in alarming that there is such a place in Bitcoin.
In the post-subsidy era There Is No Free Market between: active users (over=
taxed) and pasive users (free riders).
One of possible (very conservative) option to introduce free market there -=
is to delay halving in case of 4 years network difficulty regression situa=
tion.
Such a long-term regression of network difficulty means nothing else that t=
ransaction revenue from active users is not able to fund current network se=
curity anymore for both active and passive users. Delaying of halving is si=
mply: not introducing additional more damage to the network security (reall=
y conservative approach)
Another option is: demurrage (but I'm not very sure it will work fine, at l=
east before "hyperbitcoinzation")
Again, from my almost 50yo experience:
Bitcoin network difficulty can be more-less constant or can be slightly inc=
reasing (both options are "good for Bitcoin") but we should do our best - t=
o avoid the network security regression.
I did.
Regards
Jaroslaw
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
