Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6DC5FC0032 for ; 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 ; 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 ; 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 ; Fri, 3 Mar 2023 05:07:41 +0000 (UTC) Received: by mail-yb1-xb2c.google.com with SMTP id x12so936363ybt.7 for ; 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: In-Reply-To: From: Giuseppe B Date: Fri, 3 Mar 2023 06:07:29 +0100 Message-ID: To: Nadav Ivgi Content-Type: multipart/alternative; boundary="000000000000b694f705f5f7ece6" X-Mailman-Approved-At: Fri, 03 Mar 2023 14:36:45 +0000 Cc: Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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
Hi shesek,

<= /div>
Minimum fees may not be the right mechanism. However= I disagree with the general idea that "if it's optimal for societ= y 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 prisone= r's dilemma.=C2=A0

On Thu, Mar 2, 2023, 1:39 AM Nadav Ivgi <<= a href=3D"mailto:nadav@shesek.info">nadav@shesek.info> wrote:
Hi Giuseppe,
<= 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.

I'= ;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't really matter if it= 9;s spread out through fewer or more blocks.

shese= k

On Wed, Mar 1, 2023 at 10:25 PM Giuseppe B via bitcoin-dev <<= a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" r= el=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org> wrote:
<= /div>
Hel= lo everyone,

I'm relatively new here so what I'm= proposing could have already been discussed, or may be flawed or inapplica= ble. I apologize for that.

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.

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'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's the only rational individual choice.

The= refore I was imagining the introduction of a new protocol rule, min_fees, t= hat would work like this:=C2=A0
- 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.
- one can also mine an empty block and reset the min_fee, to avoid= the chain getting stuck.

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.

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'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's not = even worth=C2=A0discussing it for some reason that=C2=A0I'm=C2=A0not co= nsidering.

Cheers,

Giusep= pe.

_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000b694f705f5f7ece6--