Crypto Insights
Proposal to Remove OP_RETURN Limit Sparks Heated Debate Among Developers
Introduced in 2014, OP_RETURN allows small pieces of data—like timestamps or short messages—to be included in Bitcoin transactions, serving as a lightweight method to store limited information on-chain. Over time, the size limit was reduced to prevent spam, before settling at the current 83 byte-limit.
Peter Todd recently proposed removing the limit entirely. He argues that the restriction fails to deter misuse and instead complicates things, as it pushes developers to use workarounds—like scriptsig or unspendable outputs (such as storing data in unspendable Taproot outputs)—to embed media, spam, or arbitrary data, which bloats the UTXO set.
Pieter Wuille, who also supports lifting the OP_RETURN cap, points out that standardness policies can’t truly stop well-funded entities from broadcasting data-heavy transactions directly to miners. The network is strong and block space is always full—even without spam, so those rules are no longer as useful.
In short, those in favor of removing the OP_RETURN limit argue that the restriction is futile, and that alternative data storage methods within blocks already exist in abundance.
On the other side, opponents believe the limit must stay, as using OP_RETURN to store arbitrary data violates Satoshi’s intent and Bitcoin’s purpose as a financial network (Luke Dashjr). Other opposing voices include:
- @Mechanic from Ocean Mining: The devs just instinctively knew, you don’t use Bitcoin for arbitrary file storage and you do everything you can to make Bitcoin awkward to use for that purpose.
- Jason Hughes: Bitcoin Core developers are about to merge a change that turns Bitcoin into a worthless altcoin…
Here for more perspectives on this debate.
Comparing Three Cluster Linearization Techniques
Pieter Wuille compares three cluster linearization strategies—SFL (spanning-forest linearization), GGT, and CSS (candidate set search)—and follows up with benchmark results for each.
StarkWare Introduces ColliderVM: A BitVM Alternative for Computation and L2 Bridges
ColliderVM protocol is StarkWare’s research effort on a BitVM alternative. It retains the same trust assumptions but without needing fraud proofs, thus eliminating fraud-proof time window. Researchers use ColliderVM to sketch a trustless bridge design to a L2 network, aiming to scale Bitcoin with a rollup-like design and enabling more functionality and privacy.
The paper: ColliderVM: Stateful Computation on Bitcoin without Fraud Proofs
And a talk: Bitcoin Horizons: from OP_CAT to Covenants
Bitcoin Goes Green(ish): Over 50% of Mining Now Uses Sustainable Energy
A report from the Cambridge Centre for Alternative Finance (CCAF) finds that 52.4% of Bitcoin mining now uses green energy. Of that, 42.6% comes from renewables such as hydro and wind, while 9.8% comes from nuclear.
Top Reads on Blockchain and Beyond
Kraken Shares Lessons on Identifying a North Korean Hacker in Job Recruitment
Kraken recently uncovered a North Korean hacker attempting to apply for a job. They’ve shared insights on how to detect and prevent such actors at various stages of the hiring process.
Round-Efficient Adaptively Secure Threshold Signatures with Rewinding
A threshold signature scheme allows distributing a signing key to n users, such that any t of them can jointly sign, but any t−1 cannot. It is desirable to prove adaptive security of threshold signature schemes, which considers adversaries that can adaptively corrupt honest users even after interacting with them. For a class of signatures that relies on security proofs with rewinding, such as Schnorr signatures, proving adaptive security entails significant challenges.
This work proposes two threshold signature schemes that are provably adaptively secure with rewinding proofs. Our proofs are solely in the random oracle model (ROM), without relying on the algebraic group model (AGM).
Read the full paper.
Vitalik on Simplifying Ethereum L1, Taking Cues from Bitcoin’s Minimalism
In a new post titled Simplifying the L1, Vitalik suggests simplifying Ethereum’s base layer by moving from EVM to RISC-V (or another minimal VM), adopting Simple Serialize, and embracing Tinygrad’s coding philosophy.
Key impacts of this shift include:
- Radical efficiency improvements: Contracts can run directly in ZK provers without interpreter overhead. According to Succinct, performance could increase by over 100x in many cases.
- Radically improved simplicity: RISC-V spec is far more minimal than the EVM. Other options like Cairo also offer a simple design.
- All the benefits that motivated Ethereum Object Format (EOF): Including code sections, friendly static analysis, and larger code size limits.
- Expanded tooling: Solidity and Vyper can target the new VM with backend updates. If RISC-V is chosen, developers may be able to port existing code from mainstream languages.
- Reduced reliance on precompiles: Most precompiles may become obsolete—except perhaps highly optimized elliptic curve operations, which could also be phased out with advances in quantum computing.
