📅 Original date posted:2023-03-01
🗒️ Summary of this message: Proposal for a new protocol rule, min_fees, to specify minimum fees for the following block to increase network security and prevent low fees.
📝 Original message: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/20230302/72a05fa8/attachment.html>;
Nadav Ivgi [ARCHIVE] /
npub1f2…ydpll
2023-06-07 23:20:12
in reply to nevent1q…yqyv
Author Public Key
npub1f2w9pm06c4k9ay8rst7757thahg2tfrtd0n645zxrtsqwhvaysrswydpllPublished at
2023-06-07 23:20:12Event JSON
{
"id": "0bee1b098f694528879a91918edeabe7802a0467f63bda0375f06db18695e7e1",
"pubkey": "4a9c50edfac56c5e90e382fdea7977edd0a5a46b6be7aad0461ae0075d9d2407",
"created_at": 1686180012,
"kind": 1,
"tags": [
[
"e",
"b27e7edf61efe7367c6e049a082aefe63ab86c168ba5cfa0c4b541b53626d163",
"",
"root"
],
[
"e",
"8003ddd74a6163f728cb2a93384295429bc41e9fe579e3a543bbfed603e88442",
"",
"reply"
],
[
"p",
"805a3fcd58f8fda8ccfafde06f20b70f1eea6185bf60caf764201adc9743f5cf"
]
],
"content": "📅 Original date posted:2023-03-01\n🗒️ Summary of this message: Proposal for a new protocol rule, min_fees, to specify minimum fees for the following block to increase network security and prevent low fees.\n📝 Original message:Hi Giuseppe,\n\nOne side-effect this has is that until enough fees accumulate in the\nmempool to satisfy min_fees, the rational behaviour for miners would be to\ntry and fork the chain tip, competing for the fees in the latest block\n(+whatever got into the mempool in the meanwhile and can fit in). This\ncould lead to increased reorgs/orphan rates and chain instability. It could\nalso lead to miners preferring to set their low_fee to zero, to avoid other\nminers from forking their blocks off.\n\nI'm also not sure that this would actually change much. If humanity is\nwilling to spend X BTC/day on mining fees, it doesn't really matter if it's\nspread out through fewer or more blocks.\n\nshesek\n\nOn Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Hello everyone,\n\u003e\n\u003e I'm relatively new here so what I'm proposing could have already been\n\u003e discussed, or may be flawed or inapplicable. I apologize for that.\n\u003e\n\u003e I was picturing a situation where block rewards are almost zero, and the\n\u003e base layer is mainly used as a settlement layer for relatively few large\n\u003e transactions, since the majority of smaller ones goes through LN.\n\u003e\n\u003e In such a case it may very well be that even if transaction amounts are\n\u003e very consistent, transaction fees end up being very small since there is\n\u003e enough space for everyone in a block. Users wouldn't mind paying higher\n\u003e fees as they know that that would increase the network security, however\n\u003e nobody wants to be the only one doing that. Miners would of course like\n\u003e being paid more. So everyone involved would prefer higher fees but they\n\u003e just stay low because that's the only rational individual choice.\n\u003e\n\u003e Therefore I was imagining the introduction of a new protocol rule,\n\u003e min_fees, that would work like this:\n\u003e - the miner that gets to mine a block appends a min_fee field to the\n\u003e block, specifying the minimum fees that need to be contained in the\n\u003e following block in order for it to be valid.\n\u003e - one can also mine an empty block and reset the min_fee, to avoid the\n\u003e chain getting stuck.\n\u003e\n\u003e min_fees could either represent the total fees of the following block, or\n\u003e the minimal fee for each single transaction, as a percentage of the value\n\u003e transacted. Both seem to have some merits and some potential drawbacks. Of\n\u003e course min_fees=0 would correspond to the current situation.\n\u003e\n\u003e It looks to me that this could have the potential to bring the equilibrium\n\u003e closer to a socially optimal one (as opposed to individually optimal), and\n\u003e to benefit the network security in the long term. Of course it's just a\n\u003e rough sketch and it would deserve a much deeper analysis. I was just\n\u003e interested in knowing if you think that the principle has some merit or if\n\u003e it's not even worth discussing it for some reason that I'm not considering.\n\u003e\n\u003e Cheers,\n\u003e\n\u003e Giuseppe.\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230302/72a05fa8/attachment.html\u003e",
"sig": "4f601cff91a89bdf48634499e1e2b575b40c45a24adde29bcd07fa6abec66b82ec39ec0436369ddef8119d3e21afe48a1f6eef90942fe5f91801afddb942722a"
}