public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Nadav Ivgi <nadav@shesek•info>
To: Giuseppe B <beppeben2030@gmail•com>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minimum fees
Date: Thu, 2 Mar 2023 02:39:13 +0200	[thread overview]
Message-ID: <CAGXD5f2zQcS6rCEraNG9_h5E-9ZhFVf3iK_0Mbq7cdn6o6C1jA@mail.gmail.com> (raw)
In-Reply-To: <CABrXkXoq4x9aRuk0ZnfPmqE-TXZfROMuAMTwCO9VCcTnJ+snNA@mail.gmail.com>

[-- 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 --]

  reply	other threads:[~2023-03-02  0:39 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-01 20:18 Giuseppe B
2023-03-02  0:39 ` Nadav Ivgi [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAGXD5f2zQcS6rCEraNG9_h5E-9ZhFVf3iK_0Mbq7cdn6o6C1jA@mail.gmail.com \
    --to=nadav@shesek$(echo .)info \
    --cc=beppeben2030@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox