Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A11ECC0032 for ; 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 ; 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 ; 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 ; 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 , Erik Aronesty References: <194638433-36890bea95b2ebab3a168daf3c806e8f@pmq7v.m5r2.onet> Content-Language: pl From: JK 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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.