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.


------- 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
bitcoin-dev mailing list

Reply via email to