From: JK <jk_14@op•pl>
To: vjudeu@gazeta•pl,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Erik Aronesty <erik@q32•com>
Subject: Re: [bitcoin-dev] ossification and misaligned incentive concerns
Date: Tue, 7 Nov 2023 13:24:39 +0100 [thread overview]
Message-ID: <8f1e37e0-a6cd-47fc-a274-486e67853293@op.pl> (raw)
In-Reply-To: <194638433-36890bea95b2ebab3a168daf3c806e8f@pmq7v.m5r2.onet>
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.
next prev parent reply other threads:[~2023-11-07 12:24 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 8:58 vjudeu
2023-11-07 12:24 ` JK [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-11-03 18:24 Erik Aronesty
2023-11-05 14:39 ` JK
2023-11-05 14:59 ` Erik Aronesty
2023-11-05 17:25 ` JK
2023-11-05 18:43 ` alicexbt
2023-11-05 21:00 ` Ryan Grant
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8f1e37e0-a6cd-47fc-a274-486e67853293@op.pl \
--to=jk_14@op$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
--cc=vjudeu@gazeta$(echo .)pl \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox