From: Erik Aronesty <erik@q32.com>
To: Ali Sherief <ali@notatether.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Mon, 8 May 2023 08:58:28 -0400 [thread overview]
Message-ID: <CAJowKgJaG8ZnZMuVTSmyhMxZKb4pcMF1XM+WH8j64Gasoy1kcw@mail.gmail.com> (raw)
In-Reply-To: <Lm_5F74G9G21ydrFPovvmtHWpNXcbVzZibmU80oNqFRehJjcll89-t7OXqS5Fooe0cTNxGreIREMql3Li2xUCe2T5NVyss3-CrLzISO09HY=@notatether.com>
[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]
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 <
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
>
> ---
>
> [1]:
> https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/
> <https://www.coindesk.com/consensus-magazine/2023/05/05/pump-the-brcs-the-promise-and-peril-of-bitcoin-backed-tokens/?outputType=amp>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 4615 bytes --]
next prev parent reply other threads:[~2023-05-08 12:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-07 17:22 [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes? Ali Sherief
2023-05-08 12:33 ` Michael Folkson
2023-05-08 12:58 ` Erik Aronesty [this message]
2023-05-08 17:13 ` Michael Folkson
2023-05-08 19:31 ` Ali Sherief
2023-05-08 19:47 ` Erik Aronesty
2023-05-08 20:36 ` Michael Folkson
2023-05-08 20:59 ` Erik Aronesty
2023-05-08 21:01 ` Erik Aronesty
2023-05-09 15:21 ` Tom Harding
2023-05-08 16:37 ` Melvin Carvalho
2023-11-03 10:15 ` Brad Morrison
2023-11-03 10:39 ` Melvin Carvalho
2023-11-04 9:58 ` ArmchairCryptologist
2023-05-08 22:37 ` Luke Dashjr
2023-05-09 0:02 ` Peter Todd
2023-05-09 1:43 ` Ali Sherief
2023-05-09 16:32 ` Erik Aronesty
2023-05-09 21:06 ` Tom Harding
2023-05-10 20:44 ` Keagan McClelland
2023-05-09 8:41 jk_14
2023-05-09 12:50 ` Erik Aronesty
2023-05-10 3:08 ` Weiji Guo
2023-05-11 13:12 Aleksandr Kwaskoff
2023-05-12 9:36 jk_14
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CAJowKgJaG8ZnZMuVTSmyhMxZKb4pcMF1XM+WH8j64Gasoy1kcw@mail.gmail.com \
--to=erik@q32.com \
--cc=ali@notatether.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox