Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 6E295C0032 for ; Thu, 2 Mar 2023 22:37:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 4954380D44 for ; Thu, 2 Mar 2023 22:37:53 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 4954380D44 Authentication-Results: smtp1.osuosl.org; dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256 header.s=2011 header.b=SpUh5IE6 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, 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 z51Tu4sCZv0Y for ; Thu, 2 Mar 2023 22:37:52 +0000 (UTC) X-Greylist: delayed 00:10:03 by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 8DB8B80D3D Received: from smtpo78.poczta.onet.pl (smtpo78.poczta.onet.pl [141.105.16.28]) by smtp1.osuosl.org (Postfix) with ESMTPS id 8DB8B80D3D for ; Thu, 2 Mar 2023 22:37:51 +0000 (UTC) Received: from pmq3v.m5r2.onet (pmq3v.m5r2.onet [10.174.32.69]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4PSQhr6QJwzlg9Yn; Thu, 2 Mar 2023 23:27:40 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011; t=1677796060; bh=l7xxs25ojRAB4Lclx+LMjrDT3onthpwgMsBJ+/3tKBM=; h=From:Cc:To:Date:Subject:From; b=SpUh5IE6UfNSBbs2EBX51yqU8Y9/LHz8P/C3MIsoWTPLWJBgRg9G8an8VKmHxm8wd JOFot9KzcDekMV57uL/aoRr/BNBOPl/gokcLTLFA1rS1AdXX/9f9mgu5Lxr40gW6Fr xZJZe8brbTrwT7ZrE1ViX7kv7N8peiHlMQFXwoxM= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [89.64.64.71] by pmq3v.m5r2.onet via HTTP id ; Thu, 02 Mar 2023 23:27:40 +0100 From: jk_14@op.pl X-Priority: 3 To: Bitcoin Protocol Discussion Date: Thu, 02 Mar 2023 23:27:40 +0100 Message-Id: <178815707-0d716bbc84bb687bd2bf6f87ab557532@pmq3v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;89.64.64.71;PL;2 X-ONET_PL-MDA-SEGREGATION: 0 X-Mailman-Approved-At: Thu, 02 Mar 2023 23:20:08 +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: Thu, 02 Mar 2023 22:37:53 -0000 > to bring the equilibrium The important thing to highlight is that's not equilibrium between active u= sers and miners. This needed in the future equilibrium is between: Active Users (transactional tax) vs Passive Users (i.e. stakeholders: infla= tion tax) And miners will only earn as much as these two parties above will pay in "t= axes". > to benefit the network security in the long=C2=A0term The solution to benefit the network security in the long term should be sim= ple enough to understand by Average Joe, in my opinion. Delay of halving in case of network global hashrate regression - is simple = enough mechanism that cannot be played. (more here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-Ja= nuary/021362.html ) Summarizing: 1. There are two parties in Bitcoin with opposite interests from network se= curity point of view: passive stakeholders and active users. 2. There is (still) no mechanism of achieving equilibrium regarding costs o= f network security between these two parties. 3a. A system in which all users participate in ensuring its long-term secur= ity - is honest. 3b. A system in which only active of them participate, and passive stakehol= ders are de facto long-term dishonest free riders - is not honest. Every statement above is unfortunately true. There are only two serious issues in Bitcoin in fact: weak long-term securi= ty budget and quantum threat. According to IBM roadmap regarding quantum computing - they may have 4k qub= it system starting from 2025. If quantum emergency fork (only several years ahead!) will require not soft= , but hard version - that's the one and only chance for fixing simultaneously this serious fla= w of Bitcoin design, in simplest and most conservative way. And we need to talk about it now - to be mentally prepared :) Best Regards Jaroslaw W dniu 2023-03-01 21:25:08 u=C5=BCytkownik Giuseppe B via bitcoin-dev napisa=C5=82: Hello everyone, I'm relatively new here so what I'm proposing could have already been discu= ssed, or may be flawed or inapplicable. I apologize for that. I was picturing a situation where block rewards are almost zero, and the ba= se layer is mainly used as a settlement layer for relatively few large tran= sactions, since the majority of smaller ones goes through LN. In such a case it may very well be that even if transaction amounts are ver= y consistent, transaction fees end up being very small since there is enoug= h 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 wan= ts to be the only one doing that. Miners would of course like being paid mo= re. So everyone involved would prefer higher fees but they just stay low be= cause 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:=C2=A0 - 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 blo= ck in order for it to be valid. - one can also mine an empty block and reset the min_fee, to avoid the chai= n getting stuck. min_fees could either represent the total fees of the following block, or t= he minimal fee for each single transaction, as a percentage of the value tr= ansacted. Both seem to have some merits and some potential drawbacks. Of co= urse 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=C2=A0term. Of course it's just = a rough sketch and it would deserve a much deeper analysis. I was just inte= rested 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 c= onsidering. Cheers, Giuseppe.