I did hear mechanic out, but I also listened to other people too and worst of all thought for myself.

Information theory is very clear. No matter what Mechanic or anyone else does someone will find a way to sneak data he and Luke don't like onto the chain.

It is a foundational concept of encryption that a good encryption algorithm output is indistinguishable from the output of /dev/urand unless you know the type of encryption and have the key. They only way they can win is to eventually transition to a whitelist of pre-approved plaintext transactions. Want 11 of 17 multi sig but they didn't whitelist it? Too bad. Want privacy on chain? Too bad. This is not a hypothetical, knots blocks whirlpool transactions.

On top of that, remember that this is all about mempool. They are not and were never going to not store the exact same data in the chain on their node. They can't or they'll fork and suffer the same fate as bcash and other minority forks.

What exactly are they trying to accomplish? They want every bitcoin TX to be something they can read and approve of or deny based on their personal rules. That is some CBDC shit. If I wanted a CBDC I would use one.

Reply to this note

Please Login to reply.

Discussion

I find hope in Moore's law for storage and memory space and the mempool and block chain size

I'm more concerned with mempool size

Y'all devs be careful put there. Humanity depends on your stewardship! ๐Ÿงก๐Ÿ“ˆโšกโ›๏ธ

Mempool already has a hard cap total size limit.

Indeed. 4MB/block max, and usually much less. Mempool size is already growing much more slowly than the capacity of storage devices. Not to mention, you can do just about everything you could possibly need to with a pruned node running on a 20GB drive.

Chat GPT-4:

## Bitcoin Core Mempool Maximum Limit

Bitcoin Core does not have a fixed upper limit for the mempool size in the traditional sense. However, significant changes are coming with the release of **Bitcoin Core v30**, scheduled for **October 2025**. This version will alter how the mempool handles data, particularly regarding the **OP_RETURN** outputs.

### Key Changes in Bitcoin Core v30

1. **Removal of the 80-byte Limit**: The previous default limit of **80 bytes** for OP_RETURN data will be eliminated. Instead, nodes will be able to accept up to **4MB** of arbitrary data per output. This change is expected to significantly increase the amount of data that can be included in transactions.

2. **New Configurability Settings**: The setting known as **datacarriersize** will be redefined. Previously, this setting controlled the amount of data allowed in a single OP_RETURN output. In v30, the same numerical value will now permit **nine times more data** than before, effectively allowing for **830 bytes** of arbitrary data if the user specifies **83**.

3. **Default Behavior Change**: The default mempool policy will no longer filter out large OP_RETURN transactions, which means that the network will be more permissive regarding the types of data included in transactions.

### Implications of These Changes

- **Increased Mempool Size**: While there isn't a strict upper limit on the mempool itself, the changes will allow for a much larger volume of data to be processed and stored temporarily. This could lead to increased congestion if many large transactions are submitted simultaneously.

- **Community Reactions**: The changes have sparked debate within the Bitcoin community. Supporters argue that this modernization is necessary for Bitcoin's evolution, while critics warn that it could lead to network bloat and detract from Bitcoin's primary function as a currency.

In summary, while Bitcoin Core does not impose a strict upper limit on the mempool, the upcoming changes in version 30 will significantly alter how data is handled, potentially leading to a much larger effective mempool size.

Not sure what you're trying to tell me with a page AI slop paste. Care to tell me in your own words what I should be focusing on?

a node's mempool is configurable as a portion of the machines RAM. there's no hard limit except infrastructure a node is running on

Indeed. I recall mempool.space had to increase their official node's mempool limit since transactions weren't showing up with the default limit.

so which "indeed" is it? your two seem mutually exclusive to me. is there a hard limit or is it configurable?

https://bitcoincore.org/en/doc/29.0.0/rpc/blockchain/getmempoolinfo/

I think our wires are getting crossed. When Bill said "mempool already has a hard cap", he meant the size of blocks is limited, by consensus. The size of the mempool (the *entire* mempool, including the backlog) is configurable per-node.

you can just config things...

Oddly, I didn't get a notification for your reply, but did see it at the top of a client that I wasn't logged in with. Or whatever we call it, since everything gets new words for nostr. Mysterious.

You're one of the most knowledgeable people I know on nostr. If you disagree, you probably have good reasons. What material do I need to take a look at?

I'm sure you won't be surprised to learn that the people arguing on the internet, both sides, are spreading misinformation.

For me I was back and forth on the issue until I made the outside connection to information theory. Information theory is the study of encoding data. That means everything from 1s and 0s on a drive to human language. Claude Shannon is the big name if you want to do a little digging, but it is too large a field to expect to master all of it.

Encryption relies on information theory. Data transmission and storage as well. Language evolved before the concept was invented but basically everything electronic was developed with information theory in mind.

A simple concept is that man, 1 syllable, is the word for man and oxyacetalene, 6 syllables, is the word for oxyacetalene because of the relative frequency that we use those words. Language would be quite cumbersome if you switched their meanings.

Steganography is a great example of an application of information theory that proves any attempt to filter data sharing is guaranteed to fail.

I like that way of thinking of words.

Isn't the point of filters just to make spam more difficult? I don't think anyone has the idea that they'll stop it forever. A filter that works now won't work in the future, so new filters will be required, and that rolls on forever. The point is to not just throw open the gates and give up.

Every new filter adds complexity and risk of unintended consequences that has to be maintained forever.

You can fight against people you don't like using bitcoin in a way you don't like if you choose to spend your time frustrated on a guaranteed failure.

Or, you can remember that one of the main points from the beginning is that people can't be stopped from using bitcoin. Saves a ton of time and frustration and you haven't helped turn Bitcoin into a CBDC.

The same could be said the other way - 100kb ostensibly so more complex things can be built (like what?) opens the door to a lot of unintended consequences, and IMO directly facilitates turning btc into a cbdc.

I'm more comfortable with the unintended consequences of freedom than the unintended consequences of more rules.

๐ŸŽฏ