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
|
Return-Path: <jk_14@op.pl>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id A11ECC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 12:24:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 6FD0C6140B
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 12:24:49 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 6FD0C6140B
Authentication-Results: smtp3.osuosl.org;
dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256
header.s=2011 header.b=OlmK3Q+H
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, RCVD_IN_DNSWL_NONE=-0.0001,
RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=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 rDTJ452-C1ym
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 12:24:48 +0000 (UTC)
Received: from smtpa39.poczta.onet.pl (smtpa39.poczta.onet.pl [213.180.142.39])
by smtp3.osuosl.org (Postfix) with ESMTPS id 433CC60FA6
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 7 Nov 2023 12:24:48 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp3.osuosl.org 433CC60FA6
Received: from [192.168.0.97] (87-206-156-181.dynamic.chello.pl
[87.206.156.181])
(using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits))
(No client certificate requested)
(Authenticated sender: jk_144@onet.pl)
by smtp.poczta.onet.pl (Onet) with ESMTPSA id 4SPnTh10JczlgN7P;
Tue, 7 Nov 2023 13:24:39 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011;
t=1699359881; bh=C+8iSivHvu/E2tJlTO6FxDaSlmeHGNhRMQ48gyd6Exw=;
h=Date:Subject:To:References:From:In-Reply-To:From;
b=OlmK3Q+HYnBzUY0fpQbJwWpdb42Cu3A41brlyjwnpp3GficEIszfejF1isK9DT3+r
eROh6AsCp00OhPrmgMts5RwTWYXleRbHAqbuDL9Y/js11+/YTjMku6w7eKKDcK6MRR
kRsaiSb6c424SH76p2NQTgfEEhHyabqgb6d9R6nk=
Message-ID: <8f1e37e0-a6cd-47fc-a274-486e67853293@op.pl>
Date: Tue, 7 Nov 2023 13:24:39 +0100
MIME-Version: 1.0
User-Agent: Mozilla Thunderbird
To: vjudeu@gazeta.pl,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Erik Aronesty <erik@q32.com>
References: <194638433-36890bea95b2ebab3a168daf3c806e8f@pmq7v.m5r2.onet>
Content-Language: pl
From: JK <jk_14@op.pl>
In-Reply-To: <194638433-36890bea95b2ebab3a168daf3c806e8f@pmq7v.m5r2.onet>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Mailman-Approved-At: Tue, 07 Nov 2023 13:35:13 +0000
Subject: Re: [bitcoin-dev] ossification and misaligned incentive concerns
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: Tue, 07 Nov 2023 12:24:49 -0000
With an enormous annual inflation rate at the beginning, stakeholders
were able to survive such a harsh for them phase only because of the
system's expansion where "numbers go up" (e.g., almost no one from
outside Turkey would like to buy and just hold the turkish lira).
Now we are in a completely different situation, without such room as
before because we are approaching the saturation of the system (and
"Change the code, not the climate" action assures us of it).
Unfortunately, noone can predict everything decades ahead, and the
system is designed in a way (incorrectly, no need to sugarcoat it) that
with each halving, we shift from one extreme (edge case) to the opposite
(from infinite inflation to zero inflation). We move along this axis
without any control, without any feedback. If anything is controversial
here, it's this fact. And that means: favoritism of one group over
another, with clear conflict of interest.
It's a truism to say that stakeholders want transacting users to pay for
Bitcoin's security, and transacting users want stakeholders to pay for
Bitcoin's security. And this has been the case for many years - yes, as
active users, we were all free-riders, paying almost nothing for
transactions, with terawatt-hours annually dedicated to the system's
operation.
And there's really no better evidence for what I've written above than
the storm that erupted due to high fees caused by Ordinals - even here,
even with ideas to censor the paid transactions...
I have to agree with Peter Todd: "21 million is a stupid meme." ;)
Yes, it's a harmful, silly meme that has turned everything upside down...
Because we realize that "Houston, we have a problem..." - but by
promoting this meme, we've created a situation where more controversial
is not the problem itself, but talking about it...
Overtaxed active users will not pay endlessly for the entire network's
security, including "free lunches" for passive free-riders - that's as
clear as crystal.
And it's impossible to build a healthy second layer if the first layer
isn't healthy.
By the way, the first layer may become doubly unhealthy at some point
due to the threat from quantum computers.
A hard fork to save Bitcoin from a future quantum threat will be
instantly accepted, without any discussion.
And this might be the only chance to fix both issues at once.
If we introduce a change involving delay of the halving by another 4
years, but only in case of a 4-years long network regression, we finally
have a free market with an unpredictable variable where passive users
won't become free riders. The new and old code will be perfectly
compatible with each other until such a critical event occurs.
And this is a critical event with no doubt, because a 4-year network
regression caused by an earlier halving, doomed yet by every next
halving - is a slippery slope, it's the end of the Store-of-Value story
(as I demonstrated you above with the fate of rai stones), and
unfortunately, probably the end of Bitcoin (at least in the form we've
been dreaming of all along...)
W dniu 07.11.2023 o 09:58, vjudeu@gazeta.pl pisze:
> > Imagine a system that tries to maintain a constant level of
> difficulty and reacts flexibly to changes in difficulty, by modulating
> the block reward level accordingly (using negative feedback).
> This is exactly what I did, when experimenting with LN-based mining. CPU
> power was too low to get a full block reward out of that. But getting
> single millisatoshis from a channel partner? This is possible, and I
> started designing my model from that assumption. Also, because channel
> partner usually don't want to explicitly pay, I created it in a form of
> "LN transaction fee discount". Which means, a CPU miner just received
> cheaper LN transactions through the channel partner, instead of getting
> paid explicitly. Which also caused better network connectivity, because
> then you have an upper bound for your mining (it won't be cheaper LN
> transaction than for free). Which means, if you mine so many shares,
> that you have free LN transactions, then you have to sell them, or open
> another channel, and then instead of having "one channel with free
> transactions", you have many.
> > The free market is more important than finite supply.
> I would say, the backward compatibility is more important than increased
> (no matter if still constant or not) supply. Which means, you can
> "increase" the supply, just by introducing millisatoshis on-chain. Or
> add any "tail supply", or anything like that, what was discussed in the
> past. The only thing that matters is: can you make it compatible with
> the current system? Hard-fork will be instantly rejected, without any
> discussion. Soft-fork will be stopped at best, exactly in the same way,
> how other soft-fork proposals were stopped, when achieving consensus was
> hard, and the topic was controversial. So, what is left? Of course
> no-forks and second layers. This is the only way, that is wide-open
> today, and which requires no support from the community. And that's why
> Ordinals are so strong: because they are a no-fork. Better or worse
> designed, it doesn't matter, but still a no-fork. Which means, they
> exist in the wild, no matter if you like them or not.
|
