diff options
| author | jk_14 <jk_14@op.pl> | 2023-05-12 11:36:57 +0200 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2023-05-12 09:37:09 +0000 |
| commit | 3ac61c7031df3d691e67fa377c6cca1e34cde8d8 (patch) | |
| tree | 25c1fd30ab7008723423b82fbc38a8b5dd492440 | |
| parent | 5b65e40089d698792e47b9919f1dac1849d6a05b (diff) | |
| download | pi-bitcoindev-3ac61c7031df3d691e67fa377c6cca1e34cde8d8.tar.gz pi-bitcoindev-3ac61c7031df3d691e67fa377c6cca1e34cde8d8.zip | |
Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
| -rw-r--r-- | c1/7921d059ba4e3a510964d4bfeb07400676a88e | 141 |
1 files changed, 141 insertions, 0 deletions
diff --git a/c1/7921d059ba4e3a510964d4bfeb07400676a88e b/c1/7921d059ba4e3a510964d4bfeb07400676a88e new file mode 100644 index 000000000..3d5b64d63 --- /dev/null +++ b/c1/7921d059ba4e3a510964d4bfeb07400676a88e @@ -0,0 +1,141 @@ +Return-Path: <jk_14@op.pl> +Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 787EEC002A + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <keagan.mcclelland@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +Date: Fri, 12 May 2023 11:36:57 +0200 +Message-Id: <183521277-1292801d11e64541f46cb8f24e3e7829@pmq5v.m5r2.onet> +X-Mailer: onet.poczta +X-Onet-PMQ: <jk_144@onet.pl>;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 <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, 12 May 2023 09:37:09 -0000 + + +W dniu 2023-05-11 13:57:11 u=C5=BCytkownik Keagan McClelland via bitcoin-de= +v <bitcoin-dev@lists.linuxfoundation.org> 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 + + |