path: root/65/69cadcf52b9e5b7fd5ea710cc97cbb26e1d050

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 6DC5FC0032
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:07:44 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 42F2781214
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:07:44 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 42F2781214
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=UijV9mPA
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 a9oI65hKHDz1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:07:42 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org D5ACF81095
Received: from mail-yb1-xb2c.google.com (mail-yb1-xb2c.google.com
 [IPv6:2607:f8b0:4864:20::b2c])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D5ACF81095
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri,  3 Mar 2023 05:07:41 +0000 (UTC)
Received: by mail-yb1-xb2c.google.com with SMTP id x12so936363ybt.7
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 02 Mar 2023 21:07:41 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=gmail.com; s=20210112; t=1677820061;
 h=cc:to:subject:message-id:date:from:in-reply-to:references
 :mime-version:from:to:cc:subject:date:message-id:reply-to;
 bh=DclUFN9PIDXwAUHBzokcEbP/F3jWPzMyVwv71/qesLo=;
 b=UijV9mPAGVZAhq8erxcbFOG7HYl/HpOViqEr1xQGrWOMJ/iXEJlF0XZbydfx9TEJgM
 /EtXe/axIkpS0/C+2/eW0hmlY+Btvr7QALTaOt4Sfdy2+dPpQhWIOmwXyc3BEnDCXlaA
 tfAfzwPKAsq3t6Ip5X21CTu5d9gXg/kzTITHBGmI9+pVInlN74rYDIonE3ODCw7z9FiB
 5zMEHvpmPq/OA3lmx6GYtq95NW7gjzc434uDUsiL/08qnc8mL4sF36XOVsc5YKI6gEUG
 F6E8BheXHPMyuwOs5fonowDCeO/J4nIpw7/NdvtCGv4/o8ZMNOzFh8d/wInAkiXt1aQa
 6tiw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112; t=1677820061;
 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=DclUFN9PIDXwAUHBzokcEbP/F3jWPzMyVwv71/qesLo=;
 b=z1+ngh6FsmejTa4cSB+WLpqySo1mO8gd4V/uoELajY6v7tGkTXA7rVTth6uqvJf/yB
 IWZwIjYjV2vGARAlvOf2/GLBSrbRnT7Y3RbqgozQ/ClUxWe26H0tU+/76GhEQHO9Hrkg
 n6W1Eh/9IUK9SDfCWkUrpSaqcsn7grvSX/4siCcsJKMcsA50y9e8GynfoOv11RNNcdbe
 6muSCf3kPR3DM7ZqB0rpXGuwQkDUoHH17A/dBVwhOfVUMrdpDttDNmHMA2/6PXtDXWVm
 f5RfJ8zjiiArk1eOoWrbBDN8MCrW7pNn9U1CdS/ClFs+BaYA6jvXVpCm6ae5PGVkgYRH
 bdSA==
X-Gm-Message-State: AO0yUKX8G6tP+ihLzt0oODUQ80fEN5B1/qHrxKFBtEfThERCsMOQpFUn
 w4SxQcO8eYgGGpleh0ab2M3d3AtuuJkQBZwvVCE=
X-Google-Smtp-Source: AK7set9d6lKWQOL8gehHkja48XaqRWe3JF9ZktZh0Ax80Pov2a7cA6vN/bv7YlDpn7w0UHQKVXZ7PjAepZQbG2SGEFA=
X-Received: by 2002:a05:6902:524:b0:9f2:a18c:90ed with SMTP id
 y4-20020a056902052400b009f2a18c90edmr199295ybs.10.1677820060667; Thu, 02 Mar
 2023 21:07:40 -0800 (PST)
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"
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:07:44 -0000

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