MIME-Version: 1.0
References: <183080646-e0c2bb9eaf62640f6c5d6c34f66db1d9@pmq7v.m5r2.onet>
In-Reply-To: <183080646-e0c2bb9eaf62640f6c5d6c34f66db1d9@pmq7v.m5r2.onet>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 9 May 2023 08:50:03 -0400
Message-ID: <CAJowKgJVAfDiwUEy+6f1Ln45=mua=R7c=KxV5XZOJHvgEHsQhg@mail.gmail.com>
To: jk_14@op.pl, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000005a4eaf05fb423276"
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject
 non-standard Taproot transactions from full nodes?
Precedence: list

--0000000000005a4eaf05fb423276
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

I would like to point out that I'm not an advocate for doing anything at
this point aside from working on l2

just to make it inconvenient for people

I just think the discussion of outputs and fees is interesting and related
to the game theory portion of Bitcoin


On Tue, May 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> Ok, I need to highlight one important thing well proven by this discussio=
n
> (like it or not)...
>
> Not the spam itself is the real reason of feeling: "something must be don=
e"
> The reason is: $30 fee per transaction (I hope you all agree)
>
>
> Let me paraphrase some quotes used in this discussion, then:
>
> 1. Lack of block subsidy long term and necessity of $40 tx fee to
> compensate it - "threaten the smooth and normal use of the Bitcoin networ=
k
> as a peer-to-pear digital currency, as it was intended to be used as."
>
> 2. "the harmony of Bitcoin transactions is being disrupted right now" due
> to lack of block subsidy and due to exorbitant $40 tx fees as an effect
> necessary to keep the network security untouched
>
> 3. "Fee spikes aren't fun" and it's obvious that keeping the network
> security only on enormous tx fees of active users and having passive user=
s
> as free-riders - isn't fun, too
>
> 4. by ignoring Bitcoin long-term security budget problem - "we indirectly
> allowed this to happen, which previously wasn't possible before. So we al=
so
> have a responsibility to do something to ensure that this kind of
> tremendous $40 tx fees can never happen again"
>
> 5. "Action against exorbitant fees should have been taken months ago.
> (...) It's a mistake that the" tail emission or other necessary solution =
-
> weren't implemented on time
>
> 6. "we need to find a solution for long-term horrible fees problem - that
> fits everyone's common ground."
>
>
> Yes, we need - instead of being still in a heavy denial state.
>
> No additional comment then, except this little one:
> Delay of halving in case of 4 years long network difficulty regression
> situation.
>
>
> Regards,
> Jaroslaw
>
>
>
>
>
> W dniu 2023-05-09 00:37:57 u=C5=BCytkownik Luke Dashjr via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> napisa=C5=82:
>
> Action should have been taken months ago. Spam filtration has been a
> standard part of Bitcoin Core since day 1. It's a mistake that the existi=
ng
> filters weren't extended to Taproot transactions. We can address that, or
> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does=
).
> Since this is a bugfix, it doesn't really even need to wait for a major
> release.
>
> (We already have pruning. It's not an alternative to spam filtering.)
>
> Luke
>
>
>
>
> On 5/7/23 13:22, 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 intende=
d
> to be used as.
>
>
> If the volume does not die down over the next few weeks, should we take a=
n
> 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 - shou=
ld
> similar action be taken now, in the form of i) BIPs and/or ii) commits in=
to
> 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 an=
d
> 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 befor=
e.
> 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
>

--0000000000005a4eaf05fb423276
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">I would like to point out that I&#39;m not an advocate fo=
r doing anything at this point aside from working on l2<div dir=3D"auto"><b=
r></div><div dir=3D"auto">just to make it inconvenient for people</div><div=
 dir=3D"auto"><br></div><div dir=3D"auto">I just think the discussion of ou=
tputs and fees is interesting and related to the game theory portion of Bit=
coin</div><div dir=3D"auto"><br></div><div dir=3D"auto"><br></div></div><br=
><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, M=
ay 9, 2023, 8:23 AM Jaroslaw via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-=
dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt=
; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .=
8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
<br>
Ok, I need to highlight one important thing well proven by this discussion =
(like it or not)...<br>
<br>
Not the spam itself is the real reason of feeling: &quot;something must be =
done&quot;<br>
The reason is: $30 fee per transaction (I hope you all agree)<br>
<br>
<br>
Let me paraphrase some quotes used in this discussion, then:<br>
<br>
1. Lack of block subsidy long term and necessity of $40 tx fee to compensat=
e it - &quot;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.&quot;<br>
<br>
2. &quot;the harmony of Bitcoin transactions is being disrupted right now&q=
uot; due to lack of block subsidy and due to exorbitant $40 tx fees as an e=
ffect necessary to keep the network security untouched<br>
<br>
3. &quot;Fee spikes aren&#39;t fun&quot; and it&#39;s obvious that keeping =
the network security only on enormous tx fees of active users and having pa=
ssive users as free-riders - isn&#39;t fun, too<br>
<br>
4. by ignoring Bitcoin long-term security budget problem - &quot;we indirec=
tly allowed this to happen, which previously wasn&#39;t possible before. So=
 we also have a responsibility to do something to ensure that this kind of =
tremendous $40 tx fees can never happen again&quot;<br>
<br>
5. &quot;Action against exorbitant fees should have been taken months ago. =
(...) It&#39;s a mistake that the&quot; tail emission or other necessary so=
lution - weren&#39;t implemented on time<br>
<br>
6. &quot;we need to find a solution for long-term horrible fees problem - t=
hat fits everyone&#39;s common ground.&quot;<br>
<br>
<br>
Yes, we need - instead of being still in a heavy denial state.<br>
<br>
No additional comment then, except this little one:<br>
Delay of halving in case of 4 years long network difficulty regression situ=
ation.<br>
<br>
<br>
Regards,<br>
Jaroslaw<br>
<br>
<br>
<br>
<br>
<br>
W dniu 2023-05-09 00:37:57 u=C5=BCytkownik Luke Dashjr via bitcoin-dev &lt;=
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; napisa=C5=
=82:<br>
<br>
Action should have been taken months ago. Spam filtration has been a standa=
rd part of Bitcoin Core since day 1. It&#39;s a mistake that the existing f=
ilters weren&#39;t extended to Taproot transactions. We can address that, o=
r try a more narrow approach like OP_RETURN (ie, what &quot;Ordisrespector&=
quot; does). Since this is a bugfix, it doesn&#39;t really even need to wai=
t for a major release.<br>
<br>
(We already have pruning. It&#39;s not an alternative to spam filtering.)<b=
r>
<br>
Luke<br>
<br>
<br>
<br>
<br>
On 5/7/23 13:22, Ali Sherief via bitcoin-dev wrote:<br>
Hi guys,<br>
<br>
<br>
I think everyone on this list knows what has happened to the Bitcoin mempoo=
l 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 sinc=
e December 2017. I do not count the March 2021 congestion because that was =
only with 1-5sat/vbyte.<br>
<br>
<br>
Such justifiably worthless (&quot;worthless&quot; is not even my word - tha=
t&#39;s how its creator described them[1]) tokens threaten the smooth and n=
ormal use of the Bitcoin network as a peer-to-pear digital currency, as it =
was intended to be used as.<br>
<br>
<br>
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 use=
rs. Considering that miners are largely the entities at fault for allowing =
the system to be abused like this, the harmony of Bitcoin transactions is b=
eing disrupted right now. Although this community has a strong history of n=
ot putting its fingers into pies unless absolutely necessary - an example b=
eing 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 codeb=
ase, to curtail the loophole in BIP 342 (which defines the validation rules=
 for Taproot scripts) which has allowed these unintended consequences?<br>
<br>
<br>
An alternative would be to enforce this &quot;censorship&quot; at the node =
level and introduce a run-time option to instantly prune all non-standard T=
aproot transactions. This will be easier to implement, but won&#39;t hit th=
e road until minimum next release.<br>
<br>
<br>
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&#39;s common ground. We indirectly a=
llowed this to happen, which previously wasn&#39;t possible before. So we a=
lso have a responsibility to do something to ensure that this kind of conge=
stion can never happen again using Taproot.<br>
<br>
<br>
-Ali<br>
<br>
<br>
---<br>
<br>
<br>
[1]:=C2=A0<a href=3D"https://www.coindesk.com/consensus-magazine/2023/05/05=
/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/" rel=3D"nore=
ferrer noreferrer" target=3D"_blank">https://www.coindesk.com/consensus-mag=
azine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-toke=
ns/</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--0000000000005a4eaf05fb423276--