Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id AF0AAC0032 for ; Fri, 3 Mar 2023 02:45:42 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 83A89820DA for ; Fri, 3 Mar 2023 02:45:42 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 83A89820DA 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=bHoCsXYb X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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_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 r2NaOromhkY6 for ; Fri, 3 Mar 2023 02:45:41 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 5DFF0820D4 Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) by smtp1.osuosl.org (Postfix) with ESMTPS id 5DFF0820D4 for ; Fri, 3 Mar 2023 02:45:41 +0000 (UTC) Received: by mail-ed1-x532.google.com with SMTP id cw28so4962184edb.5 for ; Thu, 02 Mar 2023 18:45:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=EESu+MT7OuUzOosW5easFgGIlguGokBnEzwJdk/cYT4=; b=bHoCsXYbjhXvn2ImiZrcUYuZhEkKg14yWSkOm2eORFFMaE3PNQP8tCLxpRlUiXjnWm Ys8F6v7wmSpm0bqncUxK+Zi8yeOACRP67yRF2DuzSw4JWpbypgaxJKyMxGYql5LJ+ntZ CFuHANcmm+EGKj1pqyJF8gkW5fU8AWlY8d39V3y6rQ+wqowcvpiQWi2y8YnBpbTp+zvf /MwdbHJe8E0DKrzaJAYq5pxKbiYiLwd0WaH+vii4lanF8tVwxbfNF4NfsI52oEIRq6In RVhZEXr5xVcamcqqY5xAVOgjIR9TTTb2c5C6JvrXzSxGvK1tnYkPHCOn7usB9xq7cx7R IFtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=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=EESu+MT7OuUzOosW5easFgGIlguGokBnEzwJdk/cYT4=; b=IQZfsHp2uSsbNXfz86uZxh+oceeQPPhIqz7JWG1OPDJZF8Suyd7/CcWMGkW5TZ700I zGh/Zx82vk6EZyP0stkcd9j5t8skZgZyNtf7Mps58wAxk+aMuuQgziS+z+31J1dCox1h T9TgDG7anpGn55ktcMmMvL/w67+hKZGFRYHnz1dooGNxRNyRjJW23X66d3S9IfaadDQz gaYxc7eIWGY373MQkV0xH8E6edKajXRXsyA8xJ+Cj5uZm75gS318SRMfd5ZDqnVglBJr u2UF5CubrCOfwc2UjLJ+9sQqYFnsZziSgqMuBEHbOuQgWt8WFm4rJn8sBrrls1IRW5ZP G57Q== X-Gm-Message-State: AO0yUKV1LJh3+/foFeb2Zvg6ZL391zGwNoK0/GwYrz7vZuA0+yy2Lqbm KuXqfvdqkJhjRz/ZZ3rq3UlBSQrr7hh/TwR3XN1TgdpTfOQ= X-Google-Smtp-Source: AK7set97cE36FWM42Wqur1gVu77gCB2oTh6XeAbrfAwcjgQHRAPzKl/tRV9OPmqK1uhHXIKSFaemIubzDsNJgYJyv7Y= X-Received: by 2002:a50:c05b:0:b0:4c0:2126:ac34 with SMTP id u27-20020a50c05b000000b004c02126ac34mr228672edd.6.1677811539244; Thu, 02 Mar 2023 18:45:39 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: WMOURA Date: Thu, 2 Mar 2023 23:45:02 -0300 Message-ID: To: Giuseppe B , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000cbfa6405f5f5f095" X-Mailman-Approved-At: Fri, 03 Mar 2023 14:36:54 +0000 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 02:45:42 -0000 --000000000000cbfa6405f5f5f095 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 absurdly high minimum rate intentionally or not, this would cause a serious problem, 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, 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. O= f > course min_fees=3D0 would correspond to the current situation. > > It looks to me that this could have the potential to bring the equilibriu= m > closer to a socially optimal one (as opposed to individually optimal), an= d > 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 i= f > it's not even worth discussing it for some reason that I'm not considerin= g. > > Cheers, > > Giuseppe. > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --000000000000cbfa6405f5f5f095 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

In my amateur opinion, I imagine that th= is would give excessive power to the miner, introducing a bug in the system= , because if the miner put an absurdly high minimum rate intentionally or n= ot, this would cause a serious problem, or not.
Em qua., = 1 de mar. de 2023 =C3=A0s 17:25, Giuseppe B via bitcoin-dev <bitcoin-dev@lists.linuxfounda= tion.org> escreveu:
Hello everyone,

I'm rela= tively 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, an= d the base layer is mainly used as a settlement layer for relatively few la= rge transactions, since the majority of smaller ones goes through LN.
=

In such a case it may very well be that even if transac= tion amounts are very consistent, transaction fees end up being very small = since there is enough space for everyone in a block. Users wouldn't min= d paying higher fees as they know that that would increase the network secu= rity, however nobody wants to be the only one doing that. Miners would of c= ourse like being paid more. So everyone involved would prefer higher fees b= ut they just stay low because that's the only rational individual choic= e.

Therefore I was imagining the introduction of a= new protocol rule, min_fees, that would work like this:=C2=A0
- = the miner that gets to mine a block appends a min_fee field to the block, s= pecifying 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 bloc= k, or the minimal fee for each single transaction, as a percentage of the v= alue 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 brin= g the equilibrium closer to a socially optimal one (as opposed to individua= lly optimal), and to benefit the network security in the long=C2=A0term. Of= course it's just a rough sketch and it would deserve a much deeper ana= lysis. 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 reaso= n that=C2=A0I'm=C2=A0not considering.

Cheers,<= /div>

Giuseppe.

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--000000000000cbfa6405f5f5f095--