From: vjudeu@gazeta•pl
To: JK <jk_14@op•pl>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>,
Erik Aronesty <erik@q32•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] ossification and misaligned incentive concerns
Date: Tue, 07 Nov 2023 09:58:44 +0100 [thread overview]
Message-ID: <194638433-36890bea95b2ebab3a168daf3c806e8f@pmq7v.m5r2.onet> (raw)
[-- Attachment #1: Type: text/plain, Size: 2104 bytes --]
> 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.
[-- Attachment #2: Type: text/html, Size: 2201 bytes --]
next reply other threads:[~2023-11-07 8:58 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-07 8:58 vjudeu [this message]
2023-11-07 12:24 ` JK
-- 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=194638433-36890bea95b2ebab3a168daf3c806e8f@pmq7v.m5r2.onet \
--to=vjudeu@gazeta$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=erik@q32$(echo .)com \
--cc=jk_14@op$(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