From: ArmchairCryptologist <ArmchairCryptologist@protonmail•com>
To: "bitcoin-dev@lists•linuxfoundation.org"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Mempool spam] Should we as developers reject non-standard Taproot transactions from full nodes?
Date: Sat, 04 Nov 2023 09:58:48 +0000 [thread overview]
Message-ID: <xpDas-5qF-ZRHkgqGiihf5vStfpq3Pjdk1fZeE7CifDHWnolhoRjd-wd50C1ymkVUgNxfL3NXN_XJb8lB-5I2CcdGHi8oOVmOjlA7_9F4mA=@protonmail.com> (raw)
In-Reply-To: <46e412585ce8143727c40c66edae83e0@sonic.net>
[-- Attachment #1: Type: text/plain, Size: 2149 bytes --]
While I don't necessarily disagree about the block size limit, efforts to increase it in the past has been effectively stonewalled since, as it turns out, all you have to do to not increase it is nothing.
If we are looking to address the current mempool spam in particular, it looks to me that it isn't specifically caused by exploiting taproot to add large amounts of data to the blockchain, there are just a large amount of spam transactions creating dust and moving it around. To the best of my knowledge, this type of spam could to some extent be mitigated by adding a dynamic dust limit, where in addition to today's fixed limit of 546 sats, UTXOs are considered to be dust if they cannot be economically spent at the fee rate of the transaction creating it.
Of course, it complicates matters somehow that you cannot generally know how much data is required to spend a UTXO, especially with taproot, so you'd need to calculate it by assuming that it will require the typical amount of data for a basic UTXO. With the same assumptions used to define the original dust limit, Ignoring that segwit/taproot can be somewhat cheaper, that would be 182 sats per byte.
Say if a transaction has a fee rate of 100 sat/b - the dust limit for UTXOs this transaction creates would then be increased from 546 sats to 18200 sats. So if you want to spam the blockchain with dust, the higher you push the fees, the more sats you need to leave behind in each UTXO.
There are of course pros and cons to such an approach, and you could argue the need to cap it in various ways, but it feels to me that it would be worth considering, especially considering that it is mempool policy rather than consensus critical.
--
Best,
ArmchairCryptologist
------- Original Message -------
On Friday, November 3rd, 2023 at 11:15 AM, Brad Morrison via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
> Right now, https://mempool.space/ indicates that there are about 105,000 unconfirmed transactions and that current memory usage is 795 mb of 300 mb.
> ...
> Expanding the block size is the simplest way to expand network capacity and lower transactional costs
[-- Attachment #2: Type: text/html, Size: 4363 bytes --]
next prev parent reply other threads:[~2023-11-04 9:59 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-05-07 17:22 Ali Sherief
2023-05-08 12:33 ` Michael Folkson
2023-05-08 12:58 ` Erik Aronesty
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 [this message]
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='xpDas-5qF-ZRHkgqGiihf5vStfpq3Pjdk1fZeE7CifDHWnolhoRjd-wd50C1ymkVUgNxfL3NXN_XJb8lB-5I2CcdGHi8oOVmOjlA7_9F4mA=@protonmail.com' \
--to=armchaircryptologist@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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