path: root/bf/1d312239d56dd02134b1ffe0489156d550afa7

Return-Path: <beppeben2030@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 33A2DC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:19:59 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 0843F80E78
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:19:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 0843F80E78
Authentication-Results: smtp1.osuosl.org;
 dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com
 header.a=rsa-sha256 header.s=20210112 header.b=MTWhntlZ
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.848
X-Spam-Level: 
X-Spam-Status: No, score=-1.848 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
 by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id 7eEiIvQR_PE4
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:19:58 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org C841C80DA3
Received: from mail-yw1-x1134.google.com (mail-yw1-x1134.google.com
 [IPv6:2607:f8b0:4864:20::1134])
 by smtp1.osuosl.org (Postfix) with ESMTPS id C841C80DA3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:19:57 +0000 (UTC)
Received: by mail-yw1-x1134.google.com with SMTP id
 00721157ae682-536bf92b55cso22970807b3.12
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 02 Mar 2023 21:19:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1677820796;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=82ThEGr7k2EC64++rJhgcDQrM6oFykaZ04fPt4yR0s0=;
 b=MTWhntlZpfy1pKtarT4cKY1+K2+gw/dLX0a1j9q7ImMgJMb1pQPaWIiddqHxLRsN71
 6GMxeaJSuGKzBWmMpMWCm5FqRbap+H01rUvN4Hxj4/IkDCtIeqdJgVcBtNUjLet+jMBd
 sLPugp0AejOdzcNOgRxjdKlItSN04ckX02XJlXzSjpp1REbbsuNVqGbDE589gWVfRRi5
 zkq3QXnwXi4Ql1VM+r9tAhTNGGtGu0NRCYxbV4+fjytKpeKfI6UXODrmF9tdIP93d4j2
 +MKbbEi6OkGfBfG6uULPmyfIhRPU6Rc+KdMeYuk5HmS4Ih6vYyYCVHXg9/ke+RyxgsgF
 mgmQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1677820796;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id
 :reply-to;
 bh=82ThEGr7k2EC64++rJhgcDQrM6oFykaZ04fPt4yR0s0=;
 b=RhrsQXP79OFlSfAWdtrj0G1p2eGmt3USvHQiCgt8tarZ5ZBVQViwojZ46Ivwtm3AB7
 r+WXRCoG5uSoR/LxQXTU42ksahlL7DkdYWHAe93ib6fYLZDZI+m4MvqeWh/qR31n2xB/
 lB/ijt0gc6FX5J7l7fAYXDvTPPvYWsAvpoP+sPNyCDkS0FHq0+hT2LTy+YKg7Sh4OHKU
 9Tt0P9nA44PjCqf8HsXcT6ij/YNdJE8hzzW3C+KsJpUVlVd5qBl+5LhFeTsTk9RZWGri
 qGZ63R003gdkNxwfaFw/FPnLlVIIDNGffzbdqW9TDQ/uzHomA8IDnEsOUtHP7OoMTUQM
 DGrQ==
X-Gm-Message-State: AO0yUKVOCYV3ot6K1ph3MXJ8g2OjkAUL+bWkEMviVeT+kTC4UhGllJqy
 INO0VOPUEwvkHI3rUpA7fk2lcKrHAPJHYBuIWL/1jkLd
X-Google-Smtp-Source: AK7set81S4uiAs1AF0G8O5W6EV4orq+3PQ5XSjskioV4msx8HIgB0Hh77Eukdud/ToHCQ6MA8Aq3TbD2GpBlYr8cwHo=
X-Received: by 2002:a81:b341:0:b0:533:9252:32fa with SMTP id
 r62-20020a81b341000000b00533925232famr161289ywh.4.1677820796448; Thu, 02 Mar
 2023 21:19:56 -0800 (PST)
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"
X-Mailman-Approved-At: Fri, 03 Mar 2023 14:36:45 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Minimum fees
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Mar 2023 05:19:59 -0000

--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&#3=
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--