WMOURA [ARCHIVE] on Nostr: đ Original date posted:2023-03-03 đď¸ Summary of this message: Proposal for a ...
đ
Original date posted:2023-03-03
đď¸ Summary of this message: Proposal for a new protocol rule, min_fees, to specify the minimum fees needed in the following block for it to be valid, potentially benefiting network security.
đ Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230302/64195ad5/attachment.html>;
đď¸ Summary of this message: Proposal for a new protocol rule, min_fees, to specify the minimum fees needed in the following block for it to be valid, potentially benefiting network security.
đ Original message: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 at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230302/64195ad5/attachment.html>;