MIME-Version: 1.0
References: <CABrXkXoq4x9aRuk0ZnfPmqE-TXZfROMuAMTwCO9VCcTnJ+snNA@mail.gmail.com>
 <CAGXD5f2zQcS6rCEraNG9_h5E-9ZhFVf3iK_0Mbq7cdn6o6C1jA@mail.gmail.com>
In-Reply-To: <CAGXD5f2zQcS6rCEraNG9_h5E-9ZhFVf3iK_0Mbq7cdn6o6C1jA@mail.gmail.com>
From: Giuseppe B <beppeben2030@gmail.com>
Date: Fri, 3 Mar 2023 06:07:29 +0100
Message-ID: <CABrXkXrM-DG4RrqPnMMJTt4UD73hRso5exGMf-vxT2gx0VFpgQ@mail.gmail.com>
To: Nadav Ivgi <nadav@shesek.info>
Content-Type: multipart/alternative; boundary="000000000000b694f705f5f7ece6"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minimum fees
Precedence: list

--000000000000b694f705f5f7ece6
Content-Type: text/plain; charset="UTF-8"

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

--000000000000b694f705f5f7ece6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto"><div dir=3D"auto">Hi shesek,</div><div dir=3D"auto"><br><=
/div><div dir=3D"auto">Minimum fees may not be the right mechanism. However=
 I disagree with the general idea that &quot;if it&#39;s optimal for societ=
y to do X then they&#39;ll do X&quot;. There&#39;s plenty of examples where=
 people fail to coordinate in the absence of a suitable framework, see the =
&quot;free rider&quot; problem with public goods or even the simple prisone=
r&#39;s dilemma.=C2=A0</div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Thu, Mar 2, 2023, 1:39 AM Nadav Ivgi &lt;<=
a href=3D"mailto:nadav@shesek.info">nadav@shesek.info</a>&gt; wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left=
:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div>Hi Giuseppe,</div><=
div><br></div><div>One side-effect this has is that until enough fees accum=
ulate 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 late=
st 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.</div><div><br></div><div>I&#39=
;m also not sure that this would actually change much. If humanity is willi=
ng to spend X BTC/day on mining fees, it doesn&#39;t really matter if it=
9;s spread out through fewer or more blocks.</div><div><br></div><div>shese=
k<br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"g=
mail_attr">On Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev &lt;<=
a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" r=
el=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">Hel=
lo everyone,<div><br></div><div>I&#39;m relatively new here so what I&#39;m=
 proposing could have already been discussed, or may be flawed or inapplica=
ble. I apologize for that.</div><div><br></div><div>I was picturing a situa=
tion where block rewards are almost zero, and the base layer is mainly used=
 as a settlement layer for relatively few large transactions, since the maj=
ority of smaller ones goes through LN.</div><div><br></div><div>In such a c=
ase it may very well be that even if transaction amounts are very consisten=
t, transaction fees end up being very small since there is enough space for=
 everyone in a block. Users wouldn&#39;t mind paying higher fees as they kn=
ow that that would increase the network security, however nobody wants to b=
e 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 t=
hat&#39;s the only rational individual choice.</div><div><br></div><div>The=
refore I was imagining the introduction of a new protocol rule, min_fees, t=
hat would work like this:=C2=A0</div><div>- the miner that gets to mine a b=
lock 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.</=
div><div>- one can also mine an empty block and reset the min_fee, to avoid=
 the chain getting stuck.</div><div><br></div><div>min_fees could either re=
present 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 h=
ave some merits and some potential drawbacks. Of course min_fees=3D0 would =
correspond to the current situation.</div><div><br></div><div>It looks to m=
e that this could have the potential to bring the equilibrium closer to a s=
ocially optimal one (as opposed to individually optimal), and to benefit th=
e network security in the long=C2=A0term. Of course it&#39;s just a rough s=
ketch 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&#39;s not =
even worth=C2=A0discussing it for some reason that=C2=A0I&#39;m=C2=A0not co=
nsidering.</div><div><br></div><div>Cheers,</div><div><br></div><div>Giusep=
pe.</div><div><br></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>

--000000000000b694f705f5f7ece6--