> 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.



_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Reply via email to