* [bitcoin-dev] Minimum fees
@ 2023-03-01 20:18 Giuseppe B
2023-03-02 0:39 ` Nadav Ivgi
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Giuseppe B @ 2023-03-01 20:18 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
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.
[-- Attachment #2: Type: text/html, Size: 2278 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Minimum fees
2023-03-01 20:18 [bitcoin-dev] Minimum fees Giuseppe B
@ 2023-03-02 0:39 ` Nadav Ivgi
2023-03-03 5:07 ` Giuseppe B
2023-03-03 2:45 ` WMOURA
2023-03-04 6:21 ` Andrew Melnychuk Oseen
2 siblings, 1 reply; 8+ messages in thread
From: Nadav Ivgi @ 2023-03-02 0:39 UTC (permalink / raw)
To: Giuseppe B, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3049 bytes --]
Hi Giuseppe,
One side-effect this has is that until enough fees accumulate in the
mempool to satisfy min_fees, the rational behaviour for miners would be to
try and fork the chain tip, competing for the fees in the latest block
(+whatever got into the mempool in the meanwhile and can fit in). This
could lead to increased reorgs/orphan rates and chain instability. It could
also lead to miners preferring to set their low_fee to zero, to avoid other
miners from forking their blocks off.
I'm also not sure that this would actually change much. If humanity is
willing to spend X BTC/day on mining fees, it doesn't really matter if it's
spread out through fewer or more blocks.
shesek
On Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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
>
[-- Attachment #2: Type: text/html, Size: 3848 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Minimum fees
2023-03-01 20:18 [bitcoin-dev] Minimum fees Giuseppe B
2023-03-02 0:39 ` Nadav Ivgi
@ 2023-03-03 2:45 ` WMOURA
2023-03-03 5:19 ` Giuseppe B
2023-03-04 6:21 ` Andrew Melnychuk Oseen
2 siblings, 1 reply; 8+ messages in thread
From: WMOURA @ 2023-03-03 2:45 UTC (permalink / raw)
To: Giuseppe B, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2675 bytes --]
Hello,
In my amateur opinion, I imagine that this would give excessive power
to the miner, introducing a bug in the system, because if the miner
put an absurdly high minimum rate intentionally or not, this would
cause a serious problem, or not.
Em qua., 1 de mar. de 2023 às 17:25, Giuseppe B via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> escreveu:
> 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
>
[-- Attachment #2: Type: text/html, Size: 3555 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Minimum fees
2023-03-02 0:39 ` Nadav Ivgi
@ 2023-03-03 5:07 ` Giuseppe B
0 siblings, 0 replies; 8+ messages in thread
From: Giuseppe B @ 2023-03-03 5:07 UTC (permalink / raw)
To: Nadav Ivgi; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3547 bytes --]
Hi shesek,
Minimum fees may not be the right mechanism. However I disagree with the
general idea that "if it's optimal for society to do X then they'll do X".
There's plenty of examples where people fail to coordinate in the absence
of a suitable framework, see the "free rider" problem with public goods or
even the simple prisoner's dilemma.
On Thu, Mar 2, 2023, 1:39 AM Nadav Ivgi <nadav@shesek•info> wrote:
> Hi Giuseppe,
>
> One side-effect this has is that until enough fees accumulate in the
> mempool to satisfy min_fees, the rational behaviour for miners would be to
> try and fork the chain tip, competing for the fees in the latest block
> (+whatever got into the mempool in the meanwhile and can fit in). This
> could lead to increased reorgs/orphan rates and chain instability. It could
> also lead to miners preferring to set their low_fee to zero, to avoid other
> miners from forking their blocks off.
>
> I'm also not sure that this would actually change much. If humanity is
> willing to spend X BTC/day on mining fees, it doesn't really matter if it's
> spread out through fewer or more blocks.
>
> shesek
>
> On Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> 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
>>
>
[-- Attachment #2: Type: text/html, Size: 4688 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Minimum fees
2023-03-03 2:45 ` WMOURA
@ 2023-03-03 5:19 ` Giuseppe B
0 siblings, 0 replies; 8+ messages in thread
From: Giuseppe B @ 2023-03-03 5:19 UTC (permalink / raw)
To: WMOURA; +Cc: Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 3519 bytes --]
This will indeed give some power to the miners. But they have no incentives
in posting super high numbers as that means they won't get paid or they
will with a lot of delay.
This is not simply like setting the price for a product that has a fixed
quality. In the case of the mining services, setting the price also means
setting the quality of the product you offer (as higher price = higher
security). This is simply a way to let miners have have a say about the
quality of the product that they offer. They can always set 0 min fees and
settle for the lowest quality/ low price service, or maybe find out that
offering a better product for a higher price actually makes them more
money.
On Fri, Mar 3, 2023, 3:45 AM WMOURA <neo.m.revolutions@gmail•com> wrote:
> Hello,
>
> In my amateur opinion, I imagine that this would give excessive power to the miner, introducing a bug in the system, because if the miner put an absurdly high minimum rate intentionally or not, this would cause a serious problem, or not.
>
>
> Em qua., 1 de mar. de 2023 às 17:25, Giuseppe B via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> escreveu:
>
>> 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
>>
>
[-- Attachment #2: Type: text/html, Size: 4683 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Minimum fees
2023-03-01 20:18 [bitcoin-dev] Minimum fees Giuseppe B
2023-03-02 0:39 ` Nadav Ivgi
2023-03-03 2:45 ` WMOURA
@ 2023-03-04 6:21 ` Andrew Melnychuk Oseen
2 siblings, 0 replies; 8+ messages in thread
From: Andrew Melnychuk Oseen @ 2023-03-04 6:21 UTC (permalink / raw)
To: Giuseppe B, Bitcoin Protocol Discussion
[-- Attachment #1: Type: text/plain, Size: 2994 bytes --]
From my limited knowledge in the space, and I've taken opinions of people I respect that are far more knowledgeable than me.
I don't know of any data of what happens at the point where the coinbase drops to below the fees on any chain. I don't think there has been one where that has happened. Perhaps there is a chain out there where it is fee's only? Perhaps that can provide insight.
Opinion: I think as bitcoin's capabilities grow, demand for it will as well. There are a lot of efforts to increase the amount of transactions that can fit into a block. I think the combination of limited block space and a reduced amount of bitcoin's entering the market is the right combination for the system to self sustain. I'm looking forward to seeing the result!
Sent with [Proton Mail](https://proton.me/) secure email.
------- Original Message -------
On Wednesday, March 1st, 2023 at 12:18 PM, Giuseppe B via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> 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.
[-- Attachment #2: Type: text/html, Size: 4638 bytes --]
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Minimum fees
@ 2023-03-05 21:58 vjudeu
0 siblings, 0 replies; 8+ messages in thread
From: vjudeu @ 2023-03-05 21:58 UTC (permalink / raw)
To: Andrew Melnychuk Oseen, Bitcoin Protocol Discussion, Giuseppe B,
Bitcoin Protocol Discussion
> I don't know of any data of what happens at the point where the coinbase drops to below the fees on any chain. I don't think there has been one where that has happened. Perhaps there is a chain out there where it is fee's only? Perhaps that can provide insight.
I think federations like RSK or additional layers like LN can be a good example of what happens if there are no additional coins. In RSK, all coins are backed by BTC, so all you have is what users deposited, or what was Merge Mined, there are no more coins than that. In LN, there are nodes, and channels are formed only with existing coins, by default there is no mining, so all fees collected by nodes are based only on LN transaction fees (there are ways to reward small miners with LN coins, for example by enabling free LN transactions for those miners, or create channels directly by using outputs of the coinbase transaction, but it is not widely used).
Also note that when it comes to other chains, we still have testnet3, where there were more halvings than on the mainnet, because of blockstorms. So, if that network will not be resetted, then I guess we will see, how that network will behave, when there will be no other coins. For now, you can see some users complaining that it is hard to get enough test coins, and with each halving you can see, how that network is getting closer and closer to the case you want to observe. So, if we want to check, how potential solutions can solve that problem, using testnet3 will give better results than signet, simply because of more halvings. Also, as testnet3 has blockstorms, it is possible to also test extreme cases with huge reorgs, and see if taking fees from other blocks will still be profitable after introducing proposed changes.
Another important thing to note is that even if coins are worthless, then still, if there are some minimal fees (like one satoshi per virtual byte), then on-chain amounts simply represents, how many data can be sent by each user. It means that users can simply send zero satoshis (if there is a need to create any additional UTXOs), and place as many coins as they can in their change addresses, and then the whole game is about having any coins, to have the right to broadcast any transaction to the network. Because then, an interesting thing to note is that if there is no coins, then the chain is not going to be halted. It is still possible to create a coinbase transaction with zero coins, and it is still used in all block-based calculations, so mining such blocks can prevent other miners from reorging older blocks, and taking those fees. And then, if you look at the last miners that had some blocks with fees, then you notice that reaching 100 confirmations can encourage them to mine blocks with zero coinbase amount, just to spend their rewards.
On 2023-03-04 18:32:01 user Andrew Melnychuk Oseen via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
From my limited knowledge in the space, and I've taken opinions of people I respect that are far more knowledgeable than me.
I don't know of any data of what happens at the point where the coinbase drops to below the fees on any chain. I don't think there has been one where that has happened. Perhaps there is a chain out there where it is fee's only? Perhaps that can provide insight.
Opinion: I think as bitcoin's capabilities grow, demand for it will as well. There are a lot of efforts to increase the amount of transactions that can fit into a block. I think the combination of limited block space and a reduced amount of bitcoin's entering the market is the right combination for the system to self sustain. I'm looking forward to seeing the result!
Sent with Proton Mail secure email.
------- Original Message -------
On Wednesday, March 1st, 2023 at 12:18 PM, Giuseppe B via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [bitcoin-dev] Minimum fees
@ 2023-03-02 22:27 jk_14
0 siblings, 0 replies; 8+ messages in thread
From: jk_14 @ 2023-03-02 22:27 UTC (permalink / raw)
To: Bitcoin Protocol Discussion
> 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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2023-03-05 22:04 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-03-01 20:18 [bitcoin-dev] Minimum fees 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
2023-03-02 22:27 jk_14
2023-03-05 21:58 vjudeu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox