Content-Type: text/plain; charset="utf-8"
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable
From: jk_14@op.pl
To: "bitcoin-dev@lists.linuxfoundation.org"
 <bitcoin-dev@lists.linuxfoundation.org>
Date: Tue, 09 May 2023 10:41:13 +0200
Message-Id: <183080646-e0c2bb9eaf62640f6c5d6c34f66db1d9@pmq7v.m5r2.onet>
X-ONET_PL-MDA-SEGREGATION: 0
X-Mailman-Approved-At: Tue, 09 May 2023 12:23:30 +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: Tue, 09 May 2023 08:51:19 -0000


Ok, I need to highlight one important thing well proven by this discussion =
(like it or not)...

Not the spam itself is the real reason of feeling: "something must be done"
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 compensat=
e it - "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."

2. "the harmony of Bitcoin transactions is being disrupted right now" due t=
o lack of block subsidy and due to exorbitant $40 tx fees as an effect nece=
ssary to keep the network security untouched

3. "Fee spikes aren't fun" and it's obvious that keeping the network securi=
ty only on enormous tx fees of active users and having passive users as fre=
e-riders - isn't fun, too

4. by ignoring Bitcoin long-term security budget problem - "we indirectly a=
llowed this to happen, which previously wasn't possible before. So we also =
have a responsibility to do something to ensure that this kind of tremendou=
s $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 f=
its 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 situ=
ation.


Regards,
Jaroslaw


W dniu 2023-05-09 00:37:57 u=C5=BCytkownik Luke Dashjr via bitcoin-dev <bit=
coin-dev@lists.linuxfoundation.org> napisa=C5=82:

Action should have been taken months ago. Spam filtration has been a standa=
rd part of Bitcoin Core since day 1. It's a mistake that the existing filte=
rs 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 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.


Such justifiably worthless ("worthless" is not even my word - that's how it=
s creator described them[1]) tokens threaten the smooth and normal use of t=
he Bitcoin network as a peer-to-pear digital currency, as it was intended t=
o 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 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?


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 tra=
nsactions. This will be easier to implement, but won't hit the road until m=
inimum 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 allow=
ed 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 ca=
n never happen again using Taproot.


-Ali


---


[1]:=C2=A0https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-b=
rcs-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