IDK if this is the right question, but I asked Grok "does Bip-110 help or hinder a move towards layered storage?" answer below
I tend to fall in the camp of Optimistic View below. The other problem that Grok isn't even taking into consideration is a bad actor poisoning the network with illicit content--which is why this debate annoyingly comes back to "p**do this and that" because what would be good design is not taking into account evil human behavior. and this seems to be a blindspot for a lot of people.
---Grok Slop---
*How BIP-110 Could Help Layered Storage (The Optimistic View)*
--It temporarily raises the cost and friction of on-chain data storage (by limiting large pushes, OP_RETURN size, certain Taproot patterns, etc.).
--In theory, this could push people toward off-chain or layered solutions faster (e.g., anchoring hashes on Bitcoin while storing actual data on IPFS, Arweave, Filecoin, or dedicated Bitcoin L2s).
--It signals “Bitcoin base layer is for money, not bulk storage,” which aligns philosophically with layered architecture.
*Why It Mostly Hinders a Good Transition:*
--Creates uncertainty and precedent risk: A temporary consensus change that invalidates currently valid transactions makes developers and users wary of building on Bitcoin. Why invest in layered solutions if the rules can suddenly tighten via social pressure?
--Disrupts ongoing innovation on Taproot: Many layered approaches (e.g., advanced commitments, BitVM-style constructs, better inscription protocols, Taproot Assets) rely on the flexible scripting that BIP-110 restricts. It freezes experimentation for a year.
--Doesn’t actually solve the root problem cleanly: Existing data stays forever (grandfathered), and determined users can work around the limits with smaller/split pieces. It adds governance friction without a clean “migrate to layers” path.
--Pushes adversarial dynamics: Instead of organic fee-market pressure encouraging layers, it creates a culture war (“spam vs. money”). This makes coordinated upgrades harder, including ones that would genuinely enable better layering (e.g., prunable data regions or improved anchoring).
--Opportunity cost: Energy spent debating/fighting BIP-110 distracts from positive proposals like SegData (prunable data blocks), better L2 designs, or improvements to Lightning/Taproot for efficient commitments.
Login to reply
Replies (1)
i outright reject there is any use for taproot assets. the sooner bitcoiners realise that blockstream is an enemy of bitcoin the better. it's a clearinghouse, a settlement layer. distributed database systems without clear ownership just put the cost of storage on users who gain no benefit from it. it's a violation of Earth law in my Pentalogue rule system (based on chinese Wu Xing 5 element model). there is no real purpose for it. that's why p2spkh is my solution. deprecate (delete is not literal, it just means don't propagate taproot transactions) taproot, deprecate segwit and legacy, and move to p2spkh and musig2 for all transactions.
there is no use for data storage on bitcoin. anchoring is perfectly fine, op_return with 80 bytes is plenty for anchoring, you can plant a timestamp, hash, and still have another 16 bytes to spare.
when you put data on chain, you are having your data storage bill paid for by people who gain no share in the profit you make from whatever business model or scam associated with the data. there is no use in it. and taproot assets are useless. they are straight up shitcoins. they aren't satisfied enough with liquid that runs assets like an ethereum chain tuned for just arbitrary tokens. they have to poison bitcoin with the actual token data as well, instead of just anchoring teh chain.
if their ability to secure their system is inadequate, that cost should not be paid by node runners. the problem with bitcoin now is this normalization of ethereumization of bitcoin. but what point is there? is there something wrong with ethereum and solana and polkadot and avalanche? and if there is, is that OUR problem?