pull down to refresh
I'm using bitcoin and interested in it because I want censorship resistant money (don't get hung up on this, I'm not accusing you or BIP 110 of censorship). We achieve this by having a set of block validation rules and not seeing it as our concern what someone does within that.
Now, let's accept for a moment your contention that the current block validation rules have a vulnerability in them and let's say we all run BIP 110 and correct it.
It is a targeted first step at the consensus level
Do you think it is possible that we will get to a point where there is disagreement about whether a certain kind of transaction is "monetary" or not and it won't be clear cut?
I highly doubt that all the humans of the world who want to use bitcoin will be able to agree on what counts as monetary and what does not.
It seems then that there will be some point where we must say: follow these rules and it's a valid transaction (regardless of whether a person is trying to embed data in it or not).
Personally, I think the current block validation rules are plenty good. I run a node. I'm a merchant who accepts bitcoin. I don't believe that adoption is primarily limited by the difficulty of running a node.
Appreciate the constructive comment.
You're partially right: Simple rune operations (basic mints, transfers with few edicts) encode compactly and would likely fit within BIP-110's 83-byte OP_RETURN cap. Complex operations (full etchings with name, symbol, premine, divisibility, spacers, cap, amount, height parameters, plus multi-output airdrops with many edicts) would exceed it.
But the main blockspace driver since February 2023 has not been runes. It has been inscriptions, which embed arbitrary data (images, files, executable code) directly into Taproot witness fields via OP_IF/OP_NOTIF script structures. That is where the bulk of the non-monetary blockspace consumption comes from. BIP-110 Rule 7 bans OP_IF and OP_NOTIF in Tapscript, which would effectively prevent inscription creation. Rule 2 (256-byte data push limit) constrains it further.
BIP-110's own text explicitly states: "This proposal does not aim to eliminate spam entirely" and notes that token protocols are "best countered in policy rather than consensus." It is a targeted first step at the consensus level, not a comprehensive solution to all non-monetary use. The fact that simple token transfers still fit in 83 bytes is by design, not an oversight.
On the witness discount: You're right that I have concerns about how it's being exploited. BIP-110 addresses the vectors (the script structures used to embed large data) rather than the discount itself. The BIP's rationale discusses this trade-off explicitly and opts for simplicity and speed of deployment, noting that more comprehensive changes could be pursued after the temporary period expires.
The blocksize limit and BIP-110 address different layers. The blocksize limit controls total growth. BIP-110 targets what fills that space.