From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 8D3CCC002A for ; Tue, 9 May 2023 15:21:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 6F16F4038D for ; Tue, 9 May 2023 15:21:51 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 6F16F4038D Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=thinlink-com.20221208.gappssmtp.com header.i=@thinlink-com.20221208.gappssmtp.com header.a=rsa-sha256 header.s=20221208 header.b=Rqatk45J X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-J-TYF7fc1B for ; Tue, 9 May 2023 15:21:50 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org A64054012D Received: from mail-yw1-x112b.google.com (mail-yw1-x112b.google.com [IPv6:2607:f8b0:4864:20::112b]) by smtp2.osuosl.org (Postfix) with ESMTPS id A64054012D for ; Tue, 9 May 2023 15:21:49 +0000 (UTC) Received: by mail-yw1-x112b.google.com with SMTP id 00721157ae682-559e317eef1so88655877b3.0 for ; Tue, 09 May 2023 08:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=thinlink-com.20221208.gappssmtp.com; s=20221208; t=1683645708; x=1686237708; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:from:to:cc:subject:date:message-id :reply-to; bh=hqezPSCE3u6zFx/VuWZA4uRoxtNqz7a/vDY35s0e9HE=; b=Rqatk45Jtd9w8qYRrmlonXgarPOFjGV86oftrEKwhawQbLg/taFPbFnJiqv3ivSNl6 Fc6qKlI4eBJunBFcvLgKQkH6wyyIiD9okk8J2AGwhaNiggJuKemvyM8s7ZUtJnjV5hAM PgOf/DxQdZ4iSXz/tsGFLNAg4ViIFmgLLW0kaGLze0L774fAKeb+sUVV6UngVti4N+9w z+r5cVD7iMbG8Mq73pvrAr/73vBn1n4ugZC0YUpZBYqzN8/AxGB8HTb4uPzbHB4SHM67 3V1Odv/Ws/P5qg5FF++K131quUEg4QG4pCYzxZWdUxqNKn22INcxnilt1KV3yLknQGm+ BdDg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683645708; x=1686237708; h=in-reply-to:from:references:to:content-language:subject:user-agent :mime-version:date:message-id:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to; bh=hqezPSCE3u6zFx/VuWZA4uRoxtNqz7a/vDY35s0e9HE=; b=PJvf/9xkQOx54I37w1nIOVwVhuL+xnH9MNBm9UWb0j8sn1gB1LkiTtUDjrse81zrnK 1ouZkGfzPwvhTVqTFU/OPEy0d9QN8YQjy7cEHUHCda/+WkEu3bAEZQrDsn09oZ0Yit3H Qt6oOaP8bPKClHGKxRTSeks96J9SIrF6XIQo6DrjdOKngBrwJ2GT8/Gffn/t35TCpPMv tIG8yLbQiOO6nw4QBCCs+4DxmA+RWROhTxMFuTuuSuY43E4mqUUWYrSzApDJM+dgwa9p XUsEviT1efXWZzH7rMeZtoNsTF6irLSKcAmK+Xa6SnvJjKxyO9idAlVQWFGau8SoMoi7 42aQ== X-Gm-Message-State: AC+VfDx1XtwbJN49wf7FSX75hHK+41Q35TyDx9F84KtghY4FexSDtil6 ds1MrihWfByZUNsHyEyd70AaLZJ9lKOy6aztxR8= X-Google-Smtp-Source: ACHHUZ4EfnwFUaRyL4C1T55XXCqHKaTpKdYS6sbaP009SoRzfllweLnm6M461AqijVXipWTXXmhrcg== X-Received: by 2002:a25:3297:0:b0:b8c:49c:85cf with SMTP id y145-20020a253297000000b00b8c049c85cfmr15241122yby.3.1683645708282; Tue, 09 May 2023 08:21:48 -0700 (PDT) Received: from ?IPV6:2600:1700:b950:d740:32f:2eb8:4f17:b8fe? ([2600:1700:b950:d740:32f:2eb8:4f17:b8fe]) by smtp.gmail.com with ESMTPSA id 2-20020a251202000000b00b9db62abff3sm3090803ybs.58.2023.05.09.08.21.47 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 09 May 2023 08:21:47 -0700 (PDT) Content-Type: multipart/alternative; boundary="------------98CjMHj6Df9j6M4rcHr2hFZj" Message-ID: <1b4db941-4c64-979e-9b3b-ea112aab9080@thinlink.com> Date: Tue, 9 May 2023 08:21:46 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.10.0 Content-Language: en-US To: bitcoin-dev@lists.linuxfoundation.org References: <-2tdTjN6WfQI-CTPM49DiMOC2X5El1vJdlWTQvpalXAHKVLdFd_7ADpYN7Cz57v0fJSkaiG75fHJzcBtvJgn7Pj-RZrEk6hXk6Rp_1Y7SrE=@protonmail.com> From: Tom Harding In-Reply-To: <-2tdTjN6WfQI-CTPM49DiMOC2X5El1vJdlWTQvpalXAHKVLdFd_7ADpYN7Cz57v0fJSkaiG75fHJzcBtvJgn7Pj-RZrEk6hXk6Rp_1Y7SrE=@protonmail.com> X-Mailman-Approved-At: Tue, 09 May 2023 16:18:39 +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: Tue, 09 May 2023 15:21:51 -0000 This is a multi-part message in MIME format. --------------98CjMHj6Df9j6M4rcHr2hFZj Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit > And prevent perfectly reasonable transfers of value Such a transfer can only be reasonable when off-chain value is attached to the coins.  A rule like this is the embodiment of the philosophy that the Bitcoin network is for onchain-economic transactions. Parties could get around the rule by paying miners off-network, and that would be an appropriate penalty for using non-onchain-economic transactions. On 5/8/23 10:13, Michael Folkson via bitcoin-dev wrote: > > probably easier just to reject any transaction where the fee is > higher than the sum of the outputs > > And prevent perfectly reasonable transfers of value and attempted > Lightning channel closes during fee spikes? If I *want*​ to close my > Lightning channel during a protracted fee spike where I have to pay an > onchain transaction fee greater than the amount I am receiving you > want to stop me doing that? You are impinging on a valid use case as > well as requiring a consensus rule change. > > -- Michael Folkson > Email: michaelfolkson at protonmail.com > GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F > Learn about Bitcoin: https://www.youtube.com/@portofbitcoin > > ------- Original Message ------- > On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev > wrote: > >> probably easier just to reject any transaction where the fee is >> higher than the sum of the outputs >> >> >> >> On Mon, May 8, 2023, 7:55 AM Ali Sherief via bitcoin-dev >> wrote: >> >> Hi guys, >> >> I think everyone on this list knows what has happened to the >> Bitcoin mempool during the past 96 hours. Due to side projects >> such as BRC-20 having such a high volume, real bitcoin >> transactions are being priced out and that is what is causing the >> massive congestion that has arguable not been seen since December >> 2017. I do not count the March 2021 congestion because that was >> only with 1-5sat/vbyte. >> >> Such justifiably worthless ("worthless" is not even my word - >> that's how its creator described them[1]) tokens threaten the >> smooth and normal use of the Bitcoin network as a peer-to-pear >> digital currency, as it was intended to be used as. >> >> If the volume does not die down over the next few weeks, should >> we take an action? The bitcoin network is a triumvirate of >> developers, miners, and users. Considering that miners are >> largely the entities at fault for allowing the system to be >> abused like this, the harmony of Bitcoin transactions is being >> disrupted right now. Although this community has a strong history >> of not putting its fingers into pies unless absolutely necessary >> - an example being during the block size wars and Segwit - should >> similar action be taken now, in the form of i) BIPs and/or ii) >> commits into the Bitcoin Core codebase, to curtail the loophole >> in BIP 342 (which defines the validation rules for Taproot >> scripts) which has allowed these unintended consequences? >> >> An alternative would be to enforce this "censorship" at the node >> level and introduce a run-time option to instantly prune all >> non-standard Taproot transactions. This will be easier to >> implement, but won't hit the road until minimum next release. >> >> I know that some people will have their criticisms about this, >> absolutists/libertarians/maximum-freedom advocates, which is >> fine, but we need to find a solution for this that fits >> everyone's common ground. We indirectly allowed this to happen, >> which previously wasn't possible before. So we also have a >> responsibility to do something to ensure that this kind of >> congestion can never happen again using Taproot. >> >> -Ali >> >> --- >> >> [1]: >> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/ >> >> _______________________________________________ >> bitcoin-dev mailing list >> bitcoin-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >> > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev --------------98CjMHj6Df9j6M4rcHr2hFZj Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

And prevent perfectly reasonable transfers of value


Such a transfer can only be reasonable when off-chain value is attached to the coins.=C2=A0 A rule like this is the embodiment of = the philosophy that the Bitcoin network is for onchain-economic transactions.

Parties could get around the rule by paying miners off-network, and that would be an appropriate penalty for using non-onchain-economic transactions.



On 5/8/23 10:13, Michael Folkson via bitcoin-dev wrote:
>= ;=C2=A0probably easier just to reject any transaction where the fee is higher than the sum of the outputs

And prevent perfectly reasonable transfers of value and attempted Lightning channel closes during fee spikes? If I want=E2=80=8B to close my Lightning channel= during a protracted fee spike where I have to pay an onchain transaction fee greater than the amount I am receiving you want to stop me doing that? You are impinging on a valid use case as well as requiring a consensus rule change.
=

-- Michael Folkson
Email: michaelfolkson at protonmail.com
GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F<= /span>
------- Original Message ------- On Monday, May 8th, 2023 at 13:58, Erik Aronesty via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>= wrote:

probably easier just to reject any transactio= n where the fee is higher than the sum of the outputs



On Mon, May 8, 2023, 7:= 55 AM Ali Sherief via bitcoin-dev <= bitcoin-dev@lists.linuxfoundation.org> wrote:
= Hi guys,
=
= I think everyone on this list knows what has happened to the Bitcoin mempool during the past 96 hours. Due to side projects such as BRC-20 having such a high volume, real bitcoin transactions are being priced out and that is what is causing the massive congestion that has arguable not been seen since December 2017. I do not count the March 2021 congestion because that was only with 1-5sat/vbyte.
=
= Such justifiably worthless ("worthless" is not even my word - that's how its creator described them[1]) tokens threaten the smooth and normal use of the Bitcoin network as a peer-to-pear digital currency, as it was intended to be used as.
=
= If the volume does not die down over the next few weeks, should we take an action? The bitcoin network is a triumvirate of developers, miners, and users. Considering that miners are largely the entities at fault for allowing the system to be abused like this, the harmony of Bitcoin transactions is being disrupted right now. Although this community has a strong history of not putting its fingers into pies unless absolutely necessary - an example being during the block size wars and Segwit - should similar action be taken now, in the form of i) BIPs and/or ii) commits into the Bitcoin Core codebase, to curtail the loophole in BIP 342 (which defines the validation rules for Taproot scripts) which has allowed these unintended consequences?
=
= An alternative would be to enforce this "censorship" at the node level and introduce a run-time option to instantly prune all non-standard Taproot transactions. This will be easier to implement, but won't hit the road until minimum next release.
=
= I know that some people will have their criticisms about this, absolutists/libertarians/maximum-freedom advocates, which is fine, but we need to find a solution for this that fits everyone's common ground. We indirectly allowed this to happen, which previously wasn't possible before. So we also have a responsibility to do something to ensure that this kind of congestion can never happen again using Taproot.
=
= -Ali
=
= ---
=
=
_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
= https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


____________________________=
___________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailm=
an/listinfo/bitcoin-dev
--------------98CjMHj6Df9j6M4rcHr2hFZj--