04-16-2026Price:

The Frontier

Your signal. Your price.

BITCOIN

Developers push script revival to unlock Bitcoin privacy

Thursday, April 16, 2026 · from 2 podcasts
2 SOURCESBitcoin OptechCitadel Dispatch
  • Developers propose re-enabling 15 Bitcoin scripting opcodes disabled since 2011 with a new computational budget.
  • Silent Payments, a major privacy upgrade, faces a scanning bottleneck now solved by GPU servers.
  • Widespread adoption requires hardware wallets to implement new standards for signing and verification.

Bitcoin’s foundational scripting language, hamstrung for over a decade, is poised for a restoration that could reshape its privacy and programmability.

Developers Julian and Rusty Russell are championing "Script Restoration" through BIP 440 and 441. This plan would replace Satoshi Nakamoto’s 2011 blanket ban on 15 opcodes - originally meant to prevent denial-of-service attacks - with a precise computational budget called VarOps. The new system prices every script operation, allowing complex logic without crashing nodes, and reintroduces tools like arithmetic, bitwise logic, and large-number support via a new Tapscript leaf version.

"Giving builders general scripting primitives will let useful scaling applications like roll-ups win out via the fee market, improving Bitcoin as decentralized money."

- Julian, Bitcoin Optech

This push for general-purpose building blocks like OpCat represents a philosophical rift. Some developers prefer narrow, safe opcodes like CheckTemplateVerify, but Julian argues that general tools foster unforeseen innovation, with the fee market acting as the ultimate filter for useful applications.

The other half of this privacy push is BIP 352 for Silent Payments. This protocol creates static payment codes that automatically generate a fresh, unlinked on-chain address for every transaction, solving the widespread problem of address reuse. Craig Raw of Sparrow Wallet notes that during bull markets, up to 50% of transactions reuse addresses, degrading network-wide privacy.

"Silent payments aim to provide a static, reusable payment code while enforcing fresh addresses for each transaction, aligning privacy with convenience."

- Craig Raw, Citadel Dispatch

The catch was performance. Wallets had to scan every blockchain transaction to find their funds, a process that could take mobile devices nine hours. Raw’s solution, Frigate, uses GPU acceleration to cut scanning from hours to seconds, enabling public servers to support thousands of users. Yet a critical hurdle remains: hardware wallets must adopt standards like BIP 376 for signing and fraud proofs before cold storage users can benefit. Until then, the old, less private system persists.

ProtocolPaymentsPrivacy
BIP 352BitcoinTapscript

Source Intelligence

- Deep dive into what was said in the episodes

Bitcoin Optech
Bitcoin Optech

Bitcoin Optech: Newsletter #400 Recap • Apr 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.
ProtocolPrivacyAdoption
Citadel Dispatch
Citadel Dispatch

CD199: CRAIG RAW - SILENT PAYMENTS AND SPARROW WALLET • Apr 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.
PrivacyProtocolAdoption