I don't feel like it is tbh. BIP 110 "makes no sense" because: 1. Technically Ineffective: Network dynamics ensure that a "tolerant minority" of nodes or direct miner submission can bypass any relay-level filter. 2. Philosophically Misaligned: It prioritizes "spam prevention" over the core goals of decentralization, censorship resistance, and enabling Bitcoin as global money. 3. Harmful to Decentralization: By filtering, it disadvantages small miners who rely on the public network, potentially making mining more centralized. 4. Based on a Flawed Premise: It treats the symptom (data in blocks) instead of acknowledging that cheap blockspace is a desirable condition for scaling, and data encoding within it is unavoidable.

Replies (2)

All points are misinformation from Coretards. 1. BIP110 restricts OP_RETURN on consensus level, meaning no miner can bypass is via direct submission. Mempool filters could be bypassed by miners. 2. BIP110 helps decentralization, censorship resistance and Bitcoin as Freedom Money by reducing spam waste, reducing bandiwth and allowing more space for monetary transactions that transfer value. 3. Nonsense. Miner decentralization is solved with DATUM which Luke and Ocean developed. 3. Bitcoin blockspace is meant for monetary transactions that transfer value. Bitcoin is not a memecoin or arbitraty database. Cheap blockspace is found on BSV and other shitcoins. image
BitcoinIsFuture's avatar BitcoinIsFuture
Running BIP110 on Bitcoin Knots because Bitcoin is Freedom Money ๐Ÿค™ image https://github.com/bitcoin/bips/pull/2017#pullrequestreview-3384767316 "I'm generally supportive of the changes in this BIP. Aside from minor nitpicks in language, the 34 byte scriptPubKey restriction I think will prove to be quite valuable in addressing the larger concern of DoS blocks / poison blocks that impose such high computational costs on nodes that a single block would take 30 minutes to verify on decent hardware instead of taking about a second. This is an even larger threat to Bitcoin than either CSAM or quantum, because I've read that CSAM has already been present on Bitcoin for a very long time, and quantum computers aren't anywhere near good enough to be a threat, and may never be, whereas DoS blocks could be introduced by miners who take direct submissions without sufficient checks at any time. It's been pointed out that disabling OP_SUCCESS in Tapscript would conflict with adding new signature verification opcodes in future BIPs that might use them to add quantum resistance, but I would point out that the semantics around existing opcodes could simply be altered to preserve compatibility with BIP 110. For example, instead of creating new sets of OP_CHECKSIG opcodes to support new signature schemes, the semantics of existing OP_CHECKSIG opcode could simply be adjusted to accept imperatively inputs of varying lengths, a form of overloading / polymorphism / or duck typing. While it could be argued that a more declarative approach is superior in cryptographic contexts, I don't weight that concern as heavily as the larger concern over DoS blocks, and as such, I'm supportive of this approach. My only major objection is that this is temporary. I'm not very comfortable with either temporary soft forks or default node expiry because it forces users to act instead of delaying action, which I think delaying action is perfectly fine and reasonable as the protocol matures. It also reminds me too much of the "difficulty bomb" based monetary policy used to coerce Ethereum miners to adopt new code from the Ethereum foundation or else. That said, if BIP 110 were activated as is, I would still be supportive, and I would also support reactivating it in the future as a more permanent feature of Bitcoin. At a high level, this proposal reminds me in spirit of early versions of my original P2QRH proposal. I just think it could use a little more polish, but I see it as being directionally correct."
View quoted note →
I honestly don't think your points are a faithful representation of reality: 1. Bypassing relay filters can be currently done, but BIP110 would remove this possibility since it would define more restrictive consensus rules 2. It prioritizes data embedding reduction, not necessarily spam prevention since blocking spam entirely is basically impossible. The approach of the BIP is that of removing most or all "features" which are currently unused (taproot annex anyone?) so that easy data embedding options are not available anymore. How is this hurting monetary properties? 3. See point 1: BIP110 is about consensus rules, not relay policy. 4. Not sure what to make of this point.
โ†‘