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
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
=
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--