MIME-Version: 1.0
References: <CABrXkXoq4x9aRuk0ZnfPmqE-TXZfROMuAMTwCO9VCcTnJ+snNA@mail.gmail.com>
 <CAJ12oL1UmUJjRhircdxWH7znSCH5bmnqsgabUS74Ns4EU_VLzA@mail.gmail.com>
In-Reply-To: <CAJ12oL1UmUJjRhircdxWH7znSCH5bmnqsgabUS74Ns4EU_VLzA@mail.gmail.com>
From: Giuseppe B <beppeben2030@gmail.com>
Date: Fri, 3 Mar 2023 06:19:44 +0100
Message-ID: <CABrXkXo+j3e9fRS_3MPWVYk83WRJVnC2bv1OSBaY-Dek5W8y0g@mail.gmail.com>
To: WMOURA <neo.m.revolutions@gmail.com>
Content-Type: multipart/alternative; boundary="00000000000091b76e05f5f81894"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minimum fees
Precedence: list

--00000000000091b76e05f5f81894
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

This will indeed give some power to the miners. But they have no incentives
in posting super high numbers as that means they won't get paid or they
will with a lot of delay.
This is not simply like setting the price for a product that has a fixed
quality. In the case of the mining services, setting the price also means
setting the quality of the product you offer (as higher price =3D higher
security). This is simply a way to let miners have have a say about the
quality of the product that they offer. They can always set 0 min fees and
settle for the lowest quality/ low price service, or maybe find out that
offering a better product for a higher price actually makes them more
money.


On Fri, Mar 3, 2023, 3:45 AM WMOURA <neo.m.revolutions@gmail.com> wrote:

> 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 abs=
urdly high minimum rate intentionally or not, this would cause a serious pr=
oblem, or not.
>
>
> Em qua., 1 de mar. de 2023 =C3=A0s 17:25, Giuseppe B via bitcoin-dev <
> bitcoin-dev@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, o=
r
>> the minimal fee for each single transaction, as a percentage of the valu=
e
>> transacted. Both seem to have some merits and some potential drawbacks. =
Of
>> course min_fees=3D0 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 cours=
e
>> 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 meri=
t
>> 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
>>
>

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

<div dir=3D"auto"><div dir=3D"auto">This will indeed give some power to the=
 miners. But they have no incentives in posting super high numbers as that =
means they won&#39;t get paid or they will with a lot of delay.=C2=A0</div>=
<div dir=3D"auto">This is not simply like setting the price for a product t=
hat has a fixed quality. In the case of the mining services, setting the pr=
ice also means setting the quality of the product you offer (as higher pric=
e =3D higher security). This is simply a way to let miners have have a say =
about the quality of the product that they offer. They can always set 0 min=
 fees and settle for the lowest quality/ low price service, or maybe find o=
ut that offering a better product for a higher price actually makes them mo=
re money.=C2=A0</div><div dir=3D"auto"><br></div><div><br><br><div class=3D=
"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Mar 3, 2023, 3:=
45 AM WMOURA &lt;<a href=3D"mailto:neo.m.revolutions@gmail.com">neo.m.revol=
utions@gmail.com</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" =
style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><di=
v dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-size:large"><pre i=
d=3D"m_-5369322285001124280gmail-tw-target-text" style=3D"text-align:left" =
dir=3D"ltr"><span lang=3D"en">Hello, <br><br>In my amateur opinion, I imagi=
ne 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 intentio=
nally or not, this would cause a serious problem, or not.</span></pre></div=
></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr"=
>Em qua., 1 de mar. de 2023 =C3=A0s 17:25, 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; escreveu:<b=
r></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex=
;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr">=
Hello everyone,<div><br></div><div>I&#39;m relatively new here so what I=
9;m proposing could have already been discussed, or may be flawed or inappl=
icable. I apologize for that.</div><div><br></div><div>I was picturing a si=
tuation where block rewards are almost zero, and the base layer is mainly u=
sed as a settlement layer for relatively few large transactions, since the =
majority of smaller ones goes through LN.</div><div><br></div><div>In such =
a case it may very well be that even if transaction amounts are very consis=
tent, 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=
 know that that would increase the network security, however nobody wants t=
o 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 becaus=
e that&#39;s the only rational individual choice.</div><div><br></div><div>=
Therefore I was imagining the introduction of a new protocol rule, min_fees=
, that would work like this:=C2=A0</div><div>- the miner that gets to mine =
a block appends a min_fee field to the block, specifying the minimum fees t=
hat 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 av=
oid the chain getting stuck.</div><div><br></div><div>min_fees could either=
 represent the total fees of the following block, or the minimal fee for ea=
ch single transaction, as a percentage of the value transacted. Both seem t=
o have some merits and some potential drawbacks. Of course min_fees=3D0 wou=
ld correspond to the current situation.</div><div><br></div><div>It looks t=
o 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=C2=A0term. Of course it&#39;s just a roug=
h 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&#39;s n=
ot even worth=C2=A0discussing it for some reason that=C2=A0I&#39;m=C2=A0not=
 considering.</div><div><br></div><div>Cheers,</div><div><br></div><div>Giu=
seppe.</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></div></div>

--00000000000091b76e05f5f81894--