04-15-2026Price:

The Frontier

Your signal. Your price.

BITCOIN

Developers propose VarOps budget to restore Bitcoin's disabled smart contracts

Wednesday, April 15, 2026 · from 2 podcasts
  • A new proposal replaces Satoshi-era bans on Bitcoin script functions with a flexible computational budget.
  • Supporters argue general-purpose building blocks will let scaling solutions compete via the fee market.
  • Wallet developers warn that new privacy tech like silent payments creates critical scanning pitfalls.

The goal is to turn Bitcoin’s scripting language from a set of specific instructions back into a flexible toolkit. Bitcoin Optech’s Julian explains that BIP 440 establishes a ‘VarOps’ budget, a general computational limit that would let the network safely re-enable 15 opcodes Satoshi disabled over a decade ago. The old bans were a blunt fix for denial-of-service risks; the new system prices each operation, from signatures to hashing, shifting security from arbitrary restriction to measurable resource consumption.

“[BIP 440] establishes a computational budget, called VAR OPS, for Bitcoin script by generalizing the existing SIG OPS limit to also account for hashing and future operations.”

- Julian, Bitcoin Optech

The philosophical divide is over how much power to give builders. One camp advocates for narrow, purpose-built opcodes like CheckTemplateVerify (CTV). Julian and the Script Restoration team argue for general-purpose building blocks like OpCat, which could enable zero-knowledge verifiers and complex vaults in ways developers haven’t yet imagined. Julian’s bet is that the fee market will be the ultimate filter, allowing useful applications to outcompete junk for block space.

This technical renaissance arrives alongside a push for better privacy. On Citadel Dispatch, Sparrow Wallet creator Craig Raw detailed how Silent Payments solve Bitcoin’s chronic address reuse problem. By using a static payment code that generates a fresh address for every transaction, the tech aligns privacy with user convenience. But it introduces a heavy scanning burden, forcing wallets to check every on-chain output.

A recent BIP 352 update flags a dangerous edge case. If a sender pays the same recipient twice in one transaction - common in batch payments - and the first output is tiny ‘dust,’ a wallet set to ignore low-value outputs might stop scanning early and miss the second, larger payment. As Bitcoin Optech’s Merch notes, this makes the protocol significantly more expensive to support reliably than standard transactions.

Full hardware wallet support is the final hurdle for broad silent payment adoption. Raw is calling on Ledger, Trezor, and Coldcard to implement standards like BIP 376, which would let secure signing devices handle the new transaction types. Without this integration, the tech remains confined to hot wallets, leaving cold storage users in the old, less private paradigm.

“The primary technical challenge for silent payments is client-side scanning cost. Early implementations required hours of computation, making them impractical for average users.”

- Craig Raw, Citadel Dispatch

The underlying theme is Bitcoin’s gradual shift from a fixed protocol to a more programmable system. Proponents of script restoration see it as unlocking a wave of innovation; privacy advocates see tools like silent payments as essential for real-world use. Both efforts face the same challenge: moving from proposal to deployed, secure code that the entire ecosystem can trust.

Source Intelligence

- Deep dive into what was said in the episodes

Bitcoin Optech: Newsletter #400 RecapApr 14

  • Julian says BIP 440 establishes a computational budget, called VAR OPS, for Bitcoin script by generalizing the existing SIG OPS limit to also account for hashing and future operations.
  • Julian explains BIP 441 introduces Tapscript v2, which re-enables 15 opcodes disabled by Satoshi in 2011. It includes splicing, bitwise logic, arithmetic, and lifts arbitrary stack size and element limits.
  • Julian notes the new VAR OPS budget in BIP 440 is more restrictive than old limits for Tapscript v2, meaning some previously valid scripts could fail under the new framework.
  • Merch encourages community review of draft BIPs, noting about 50 open pull requests with roughly 10 proposing new BIPs.
  • Gustavo details Bitcoin Core PR #33908, which adds a 'CheckBlockContextFree' API function for validating blocks without chain state, used for Stratum v2 mining template validation.
  • Gustavo says Eclair PR #3283 adds a 'fee' field to routing endpoints, eliminating the need for callers to manually calculate total fees by summing per-hop costs.
  • Gustavo explains LDK PR #4529 allows separate inbound HTLC limits for announced and private channels. Defaults are 25% of capacity for private and 100% for announced channels.
  • Gustavo reports LDK PR #4494 updates RBF logic to comply with both BIP125 and BOLT2 fee bump rules, choosing the larger required increase. This prompted a BOLT spec discussion.
  • Merch finds the BOLT2 fee bump rule confusing, as its 25/24 multiplier may be insufficient versus Bitcoin Core's incremental relay fee, and notes BIP125 is no longer in Bitcoin Core.
  • Gustavo says LND PR #10666 adds a 'DeleteForwardingHistory' RPC to delete records older than a timestamp, with a one-hour minimum age guard to prevent deleting recent data.
  • Merch explains BIP 393 adds optional metadata like block height and gap limit to output descriptors, aiding wallet backup and scanning efficiency, especially for silent payments.
  • Merch details a BIP 352 update warning silent payment wallets to scan all outputs, even dust, to avoid missing multiple payments in one transaction due to indexed output generation.
  • Mike notes Bitcoin Core 31.0 is on Release Candidate 4 with no open issues, nearing final release after testing covered features like cluster mempool and GitBlock RPC.
  • Julian expresses optimism that giving builders general scripting primitives will let useful scaling applications like roll-ups win out via the fee market, improving Bitcoin as decentralized money.

CD199: CRAIG RAW - SILENT PAYMENTS AND SPARROW WALLETApr 13

  • Craig Raw argues Bitcoin's HD wallet system, introduced in 2013 via BIP32, improved address generation but still suffers from high address reuse, which degrades network-wide privacy.
  • Craig Raw cites evidence that 25-35% of Bitcoin addresses are reused, a rate that can spike to 50% during bull markets. This reuse creates a negative privacy externality for all users.
  • Silent payments aim to provide a static, reusable payment code while enforcing fresh addresses for each transaction, aligning privacy with convenience.
  • Craig Raw explains BIP47, an earlier static payment code solution, failed to gain broad adoption primarily because it lacked hardware wallet support, requiring the private key for address derivation.
  • Silent payments solve the HD wallet gap limit issue, which can cause wallets to miss transactions if too many future addresses are queried without payment.
  • The primary technical challenge for silent payments is client-side scanning cost. Early implementations required hours of computation, making them impractical for average users.
  • Craig Raw developed Frigate, a server-side solution that uses GPU acceleration to reduce silent payment scanning from hours to seconds, enabling potential public server support.
  • Full hardware wallet support for silent payments requires implementing new BIPs, including BIP376 for spending, and discrete log equivalence proofs to prevent coordinator fraud.
  • Multisig wallets cannot currently send to silent payment addresses, though Craig Raw suggests an intermediate transaction workaround is possible but not yet implemented.
  • BIP353 allows combining a static on-chain silent payment address and a static Lightning invoice into a single human-readable identifier like user@domain.com, verified via DNSSEC.
  • Craig Raw calls for three ecosystem groups to adopt silent payments: hardware wallet vendors to implement standards, node/Electrum server operators to run scanning services, and individuals to test the technology.
  • Odell cites OpenSats' logistical burden of managing 200 unique addresses for monthly grant payouts as a prime use case for a static silent payment address.