Giuseppe B [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 required in the following block for network security and stability. The author disagrees with the idea that people will always coordinate for the optimal outcome.
📝 Original message: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 at 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 at 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 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/20230303/e25eabe3/attachment-0001.html>;
🗒️ Summary of this message: Proposal for a new protocol rule, min_fees, to specify the minimum fees required in the following block for network security and stability. The author disagrees with the idea that people will always coordinate for the optimal outcome.
📝 Original message: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 at 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 at 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 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/20230303/e25eabe3/attachment-0001.html>;