Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 787EEC002A for ; Fri, 12 May 2023 09:37:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 449A141FA9 for ; Fri, 12 May 2023 09:37:09 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 449A141FA9 Authentication-Results: smtp4.osuosl.org; dkim=pass (1024-bit key) header.d=op.pl header.i=@op.pl header.a=rsa-sha256 header.s=2011 header.b=dCMBKAc3 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KZ-wsDxoEsKA for ; Fri, 12 May 2023 09:37:08 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 39F7141F8B Received: from smtpo46.poczta.onet.pl (smtpo46.poczta.onet.pl [213.180.142.177]) by smtp4.osuosl.org (Postfix) with ESMTPS id 39F7141F8B for ; Fri, 12 May 2023 09:37:07 +0000 (UTC) Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4QHkDn5MHyzlgC01; Fri, 12 May 2023 11:36:57 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=op.pl; s=2011; t=1683884217; bh=y7DP0UDy41NNvnVhbIHA740lpp+9rqVft3T78jamV7o=; h=From:To:Date:Subject:From; b=dCMBKAc3jdQ1tNh01zdRKGmZIoPks4VzFVIzWu+M4Z1k38pyyR6j+3UJF+mpAFvV7 z/zyiIFJo7OGWOpOI3+gASriuV24sF6TRCqLbsxlniKPrnrMPakEM0bG2Qo9y2+BFl KSa0BHJ6f47WGeUe78871CrOSKWXqKOUGNmAvEuE= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [89.64.64.233] by pmq5v.m5r2.onet via HTTP id ; Fri, 12 May 2023 11:36:57 +0200 From: jk_14@op.pl X-Priority: 3 To: Keagan McClelland , Bitcoin Protocol Discussion Date: Fri, 12 May 2023 11:36:57 +0200 Message-Id: <183521277-1292801d11e64541f46cb8f24e3e7829@pmq5v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;89.64.64.233;PL;2 X-ONET_PL-MDA-SEGREGATION: 0 X-Mailman-Approved-At: Fri, 12 May 2023 09:47:12 +0000 Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? 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, 12 May 2023 09:37:09 -0000 W dniu 2023-05-11 13:57:11 u=C5=BCytkownik Keagan McClelland via bitcoin-de= v napisa=C5=82: > The current fees we are experiencing are still significantly lower than t= hey need to be if Bitcoin is going to survive in a post-subsidy era. If our= layered protocols can't survive the current fee environment, the answer is= to fix the layered protocols. I also believe that this discussion should be expanded to the problem of Bi= tcoin's survival in the post-subsidy era, because it's very related, i.e. a= lso directly related to the high transaction fees. The only difference is t= hat the current $30 fee situation is probably temporary, and the future $40= (today's price tag) fee situation in post-subsidy era will be hopeless for= change other than to reduce the difficulty of the network and hence its se= curity and the marketcap/price in the end of day. Because if the current network hashrate (current level of security) would d= rop e.g. to half of what it was in the past - the Store-of-Value feature si= mply collapse, while it's one of the most important (if not: the most impor= tant) long term feature of Bitcoin and as such advertised... If you really care about SoV - you can't accept network security regression= . Period. I am a committed supporter of the free market. And Bitcoin is not the e-mai= l system, where sending is free and therefore spam which costs nothing to t= he sender - becomes a problem. In Bitcoin, every transaction costs - and in= such a situation, distinguishing paid transactions into the good ones and = the bad ones - would be a mistake and contradict the idea of the free marke= t. We should not interfere where the free market intervenes: the same way how = small transfers are migrating to LN, the same way "non-economic", low value= informations will migrate to Layer2 (RGB, Taro or maybe something else yet) But, we should intervene there, where there is no free market. And I am not= alone in alarming that there is such a place in Bitcoin. In the post-subsidy era There Is No Free Market between: active users (over= taxed) and pasive users (free riders). One of possible (very conservative) option to introduce free market there -= is to delay halving in case of 4 years network difficulty regression situa= tion. Such a long-term regression of network difficulty means nothing else that t= ransaction revenue from active users is not able to fund current network se= curity anymore for both active and passive users. Delaying of halving is si= mply: not introducing additional more damage to the network security (reall= y conservative approach) Another option is: demurrage (but I'm not very sure it will work fine, at l= east before "hyperbitcoinzation") Again, from my almost 50yo experience: Bitcoin network difficulty can be more-less constant or can be slightly inc= reasing (both options are "good for Bitcoin") but we should do our best - t= o avoid the network security regression. I did. Regards Jaroslaw _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev