From: jk_14@op•pl
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minimum fees
Date: Thu, 02 Mar 2023 23:27:40 +0100 [thread overview]
Message-ID: <178815707-0d716bbc84bb687bd2bf6f87ab557532@pmq3v.m5r2.onet> (raw)
> to bring the equilibrium
The important thing to highlight is that's not equilibrium between active users and miners.
This needed in the future equilibrium is between:
Active Users (transactional tax) vs Passive Users (i.e. stakeholders: inflation tax)
And miners will only earn as much as these two parties above will pay in "taxes".
> to benefit the network security in the long term
The solution to benefit the network security in the long term should be simple enough to understand by Average Joe, in my opinion.
Delay of halving in case of network global hashrate regression - is simple enough mechanism that cannot be played.
(more here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021362.html )
Summarizing:
1. There are two parties in Bitcoin with opposite interests from network security point of view: passive stakeholders and active users.
2. There is (still) no mechanism of achieving equilibrium regarding costs of network security between these two parties.
3a. A system in which all users participate in ensuring its long-term security - is honest.
3b. A system in which only active of them participate, and passive stakeholders are de facto long-term dishonest free riders - is not honest.
Every statement above is unfortunately true.
There are only two serious issues in Bitcoin in fact: weak long-term security budget and quantum threat.
According to IBM roadmap regarding quantum computing - they may have 4k qubit system starting from 2025.
If quantum emergency fork (only several years ahead!) will require not soft, but hard version
- that's the one and only chance for fixing simultaneously this serious flaw of Bitcoin design, in simplest and most conservative way.
And we need to talk about it now - to be mentally prepared :)
Best Regards
Jaroslaw
W dniu 2023-03-01 21:25:08 użytkownik Giuseppe B via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> napisał:
Hello everyone,
I'm relatively new here so what I'm proposing could have already been discussed, or may be flawed or inapplicable. I apologize for that.
I was picturing a situation where block rewards are almost zero, and the base layer is mainly used as a settlement layer for relatively few large transactions, since the majority of smaller ones goes through LN.
In such a case it may very well be that even if transaction amounts are very consistent, transaction fees end up being very small since there is enough space for everyone in a block. Users wouldn't mind paying higher fees as they know that that would increase the network security, however nobody wants to be the only one doing that. Miners would of course like being paid more. So everyone involved would prefer higher fees but they just stay low because that's the only rational individual choice.
Therefore I was imagining the introduction of a new protocol rule, min_fees, that would work like this:
- the miner that gets to mine a block appends a min_fee field to the block, specifying the minimum fees that need to be contained in the following block in order for it to be valid.
- one can also mine an empty block and reset the min_fee, to avoid the chain getting stuck.
min_fees could either represent the total fees of the following block, or the minimal fee for each single transaction, as a percentage of the value transacted. Both seem to have some merits and some potential drawbacks. Of course min_fees=0 would correspond to the current situation.
It looks to me that this could have the potential to bring the equilibrium closer to a socially optimal one (as opposed to individually optimal), and to benefit the network security in the long term. Of course it's just a rough sketch and it would deserve a much deeper analysis. I was just interested in knowing if you think that the principle has some merit or if it's not even worth discussing it for some reason that I'm not considering.
Cheers,
Giuseppe.
next reply other threads:[~2023-03-02 22:37 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-03-02 22:27 jk_14 [this message]
-- strict thread matches above, loose matches on Subject: below --
2023-03-05 21:58 vjudeu
2023-03-01 20:18 Giuseppe B
2023-03-02 0:39 ` Nadav Ivgi
2023-03-03 5:07 ` Giuseppe B
2023-03-03 2:45 ` WMOURA
2023-03-03 5:19 ` Giuseppe B
2023-03-04 6:21 ` Andrew Melnychuk Oseen
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=178815707-0d716bbc84bb687bd2bf6f87ab557532@pmq3v.m5r2.onet \
--to=jk_14@op$(echo .)pl \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/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