Menu
MCAP $2.82T ▼-4.27%
BTC $82,643 ▼-1.94%
ETH $2,560 ▼-2.22%
BNB $767.13 ▼-0.28%
XRP $1.400 ▼-4.90%
SOL $114.83 ▼-3.21%
DOGE $0.0871 ▼-3.79%
ADA $0.252 ▼-1.91%
TRX $0.3348 ▲+0.47%
LINK $13.09 ▼-4.25%
AVAX $10.83 ▼-3.82%
HYPE $87.07 ▼-4.20%
DOT $1.096 ▼-2.59%

Bitcoin Security

Every Crypto Coin Show story tagged Bitcoin Security, newest first, alongside the guides and interviews that give it context.

Guide: How do blockchains reach consensus? ProofGuide: What is restaking? EigenLayer, liquid restakingNewsletter
From the interview archive
Justin Drake warns OpenAI math advances threaten Bitcoin and Ethereum wallet security
AI News

Justin Drake warns OpenAI math advances threaten Bitcoin and Ethereum wallet security

, , , , , , , ,

AI NewsCrypto Coin Show News Team·October 7, 2026·5 min read

OpenAI’s release of a broad collection of new mathematical results has prompted Ethereum researcher Justin Drake to warn that AI could break elliptic-curve cryptography, the foundation of Bitcoin and Ethereum wallet security, far sooner than quantum computing poses a threat, possibly within months in a worst-case scenario. For institutions holding large balances, the implication is immediate: moving assets to addresses with unexposed public keys may now be a prudent interim defense while blockchains work toward quantum-resistant cryptography.

  • OpenAI’s internal model generated 722 mathematical manuscripts using an average of three hours of ChatGPT Pro reasoning per result across roughly 4,000 problems tested.
  • Justin Drake urged large custodians including Binance, Bitfinex, Robinhood and Tether to migrate holdings to fresh addresses that have never signed transactions to hide public keys.
  • Ethereum’s post-quantum security roadmap is currently targeted for around 2029, but Drake argues AI-driven mathematical breakthroughs now demand accelerated defensive timelines.
  • 722 mathematical manuscripts released by OpenAI in a single collection, compared to previous isolated publications.
  • 2029 Ethereum’s current target date for core post-quantum infrastructure, subject to revision based on threat acceleration.
  • 3 hours average ChatGPT Pro reasoning compute used per mathematical result in OpenAI’s internal model evaluation.

According to first reporting on the subject, OpenAI released a catalog of 722 mathematical manuscripts on October 6 produced by an internal frontier model. The company spent approximately three hours of ChatGPT Pro thinking compute on the average result and tested the model across thousands of problems. The release includes computer-verifiable Lean formalizations of many proofs but does not claim a practical attack on Bitcoin’s or Ethereum’s cryptography. On October 7, Ethereum researcher Justin Drake responded by urging the blockchain industry to enter “bunker mode,” warning that accelerating AI-driven mathematical discovery could collapse the security assumptions underlying both networks.

Drake warns AI could break ECDSA within months, not the years quantum computing requires

Bitcoin and Ethereum rely on the Elliptic Curve Digital Signature Algorithm (ECDSA) on the secp256k1 curve to authorize transactions and prove ownership of funds. Once an account sends a transaction, its public key becomes visible on the blockchain. If an attacker could efficiently derive the private key from that public key, they could take control of all assets in that account.

Drake argued that OpenAI’s mathematical breakthroughs should force the industry to reconsider how long ECDSA will remain secure against classical algorithms, not merely quantum computers. He said an effective break of ECDSA could arrive “in months, not years” in a worst-case scenario. That timeline differs sharply from the industry’s traditional post-quantum roadmap: Ethereum’s documentation indicates core post-quantum infrastructure is targeted for roughly 2029. Drake cited the historical precedent of quantum algorithms occasionally inspiring faster classical approaches and said researchers should remain open to discovering a classical counterpart to Shor’s algorithm, which would threaten both elliptic-curve cryptography and RSA.

OpenAI’s announcement does not report a practical attack on ECDSA or RSA, and Drake’s months timeline is an unverified conjecture, not a demonstrated capability.

Moving to fresh addresses with hidden public keys offers interim protection without blockchain upgrades

Drake proposed a practical response that does not require waiting for new blockchain infrastructure or consensus upgrades. He urged large custodians including Binance, Bitfinex, Robinhood, Bitbank and Tether to migrate holdings into addresses that have never signed a transaction. Once a new address is used to send funds, he recommended transferring any remaining balance into another fresh address. The protection works because standard Ethereum externally owned accounts only expose an address hash on-chain until they send a transaction; the public key itself remains hidden behind that hash until the first outgoing transaction is signed.

The distinction matters for different address types. Bitcoin Taproot outputs expose a public key from the outset, and Taproot uses Schnorr signatures rather than ECDSA, although both rely on the secp256k1 curve.

For critical blockchain infrastructure such as oracles and layer-2 security councils, Drake recommended more aggressive precautions: rotating ECDSA keys after signing messages or combining existing signatures with hash-based systems such as SPHINCS. He cautioned against rushed transfers, warning that hurried moves could create more risk than they eliminate, but argued that Ethereum’s existing post-quantum timelines should now be revisited as AI changes the underlying assumptions.

Ethereum’s post-quantum roadmap includes hash-based signatures, but Drake’s concerns demand faster action

Ethereum has already established a dedicated post-quantum security effort, with work underway on hash-based signatures, account abstraction and replacements for cryptographic systems vulnerable to quantum computers.

Drake said his preferred long-term approach would rely heavily on hash-based cryptography, which has less algebraic structure for future AI systems to exploit than elliptic curves, lattices or isogenies.

Ethereum’s roadmap includes hash-based validator signatures and mechanisms designed to let individual accounts adopt different signature schemes without requiring the entire network to migrate at once.

The timing question remains unsettled. Ethereum’s second annual post-quantum research retreat is scheduled for October 9 to October 12, and Drake said he plans to address institutional participants in London next month as he pushes for faster defensive preparations. Europol separately added urgency to the broader issue, warning that quantum computing could eventually undermine cryptography protecting cryptocurrency wallets and urging the industry to begin preparing before the threat becomes practical. The agency argued that uncertainty over timing should not delay migration because upgrading systems and coordinating defenses could itself take years.

The core question remains unresolved: whether a classical algorithm capable of breaking ECDSA actually exists or could be discovered soon enough to pose a threat before quantum computers do.

The CCS read. Drake’s proposal does not require Ethereum or Bitcoin to change their protocols, only that custodians and holders change their behavior. For institutional holders, the move to fresh addresses is low-friction and costs only transaction fees, creating a hedge against both AI-discovered classical breaks and quantum threats. The pressure now falls on major exchanges and self-custody platforms to lead the transition and make address rotation a standard practice rather than an edge case.

Ethereum’s October 9 to October 12 post-quantum research retreat and Drake’s stated plan to address London-based institutional participants next month will serve as concrete markers for whether the industry accelerates its defensive timeline or maintains the existing 2029 target for core post-quantum infrastructure migration.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

Bitcoin developer Liam Gilligan’s BIP461 closes signature loophole that leaks private keys
Bitcoin

Bitcoin developer Liam Gilligan’s BIP461 closes signature loophole that leaks private keys

, , , , , , ,

BitcoinCrypto Coin Show News Team·October 1, 2026·3 min read

A new Bitcoin Improvement Proposal gives wallet makers a way to catch hardware that secretly leaks private keys inside otherwise valid signatures. For custodians and exchanges that rely on hardware signing devices to secure institutional bitcoin holdings, a shared, checkable standard narrows a blind spot that has existed since ECDSA signing began.

  • BIP461, authored by developer Liam Gilligan, was merged into the Bitcoin BIPs repository as a Draft on Sept. 16.
  • The proposal forces two independent signers holding the same secret key to produce byte-identical ECDSA signatures for the same message.
  • A Bitcoin Core reviewer said test vectors and a reference implementation are still required before BIP461 can advance to Complete status.
  • 70 bytes maximum size of a BIP461 signature
  • Sept. 16 date Gilligan’s draft was merged into Bitcoin’s BIPs repository

Bitcoin developer Liam Gilligan’s proposal, filed as BIP461, specifies a fully deterministic version of ECDSA, the signature scheme Bitcoin has used since its launch to authorize transactions. Under existing rules, a signer has latitude over a value called the nonce, a one-time number chosen during signing, and that freedom lets compromised firmware encode fragments of a secret key inside a signature that still passes verification. Gilligan’s draft closes that gap by fixing every choice in the signing process, so any two honest, compliant signers given the same key and message must output the identical result.

The document was merged into the BIPs repository on Sept. 16. It remains marked Draft, the earliest formal stage in the BIP process.

According to its report on the proposal, CryptoSlate noted that BIP461 requires no change to Bitcoin’s consensus rules, since the resulting signatures remain valid under existing validation logic. The fix operates entirely at the signer level, meaning wallet and hardware vendors can adopt it without any network upgrade or soft fork.

Standardization Turns a Signature Into a Checkable Benchmark

The vulnerability BIP461 targets was formalized by the Dark Skippy disclosure, which showed that corrupted wallet firmware could embed seed material inside transaction signatures without failing verification. Dark Skippy’s original demonstration used Schnorr signatures, the scheme behind Taproot, while BIP461 covers ECDSA; Taproot uses the separate BIP340 Schnorr scheme, so the new draft does not directly standardize a remedy for that specific demo.

Detection works by loading the same key into two independent signers, signing the same message on both, and comparing the output. A mismatch proves at least one signer deviates from BIP461, though it does not by itself prove theft or identify which device is malicious.

Another important motivation is that signatures produced according to a standardised approach will be byte-identical. This means signers can be compared to ensure they are not leaking secrets by embedding them in signatures (e.g. Dark Skippy).

Sjors, reviewer on the related Bitcoin Core pull request

The proposal’s mitigation discussion warns the check has a real limit: a malicious device could pass a test signature while leaking only on a selected real transaction, so a single matching comparison confirms nothing beyond that one sample. The document itself states that standardization alone “is what enables leak detection,” since a nonstandard algorithm has no reference to cross-check against. Our Crypto Coin Show coverage of a separate post-quantum signing proposal for Lightning shows developers are tackling signer-security gaps across multiple layers of the Bitcoin stack this year, not just at the base layer.

Test Vectors and Reference Code Remain Unbuilt

BIP461 carries a secondary benefit: its deterministic algorithm also grinds signatures to a maximum of 70 bytes in DER encoding, by enforcing low-r and low-s forms, with the side effect that a non-grinding signer becomes identifiable on-chain by its high-r signatures.

At the September merge, a reviewer said reference implementation code and test vectors were still listed as “TODO” and necessary before BIP461 could progress from Draft to Complete.

The CCS read. For institutional custodians, this draft matters less as a protocol change than as an audit tool for vendor firmware. Firms with large on-chain reserves, like the one disclosed in Strategy’s 8-K filing, could eventually require hardware signers to pass BIP461 comparisons as a procurement condition, shifting signer verification from a trust assumption to a contractual one once compliant implementations exist.

BIP461 cannot advance beyond Draft until someone publishes the missing reference implementation and test vectors, work the jeanpablojp offer on the pull request has proposed but not yet delivered. Until that code lands and hardware vendors adopt the deterministic algorithm, the detection benchmark Gilligan designed exists on paper only.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

Core Lightning patches flaw that bypassed penalty for revoked channel closes
Bitcoin

Core Lightning patches flaw that bypassed penalty for revoked channel closes

, , , , , , ,

BitcoinCrypto Coin Show News Team·September 27, 2026·3 min read

Core Lightning, a Lightning Network node implementation, has patched a channel-closing flaw that let a peer broadcast an old, revoked commitment without triggering the penalty meant to punish cheating. The fix, folded into release v26.06.7 and forward-ported to the main codebase on Monday (Sept. 15), matters because it touches the core economic guarantee that makes Lightning channels safe to leave unmonitored.

  • Core Lightning shipped the fix in v26.06.7 on Aug. 28, then published the source publicly on Sept. 11.
  • Pull request 9509, merged into the master branch on Sept. 15, carried the shutdown-script fix forward for future releases.
  • Docker images tagged v26.06.7 between Aug. 28 and Sept. 1 reported the new version number but lacked the actual fixes.
  • v26.06.7 release that patched the revoked-close penalty bypass
  • Sept.15 date the fix was forward-ported into Core Lightning’s master branch
  • Aug28-Sept1 window when Docker images misreported an unpatched build as fixed

Lightning channels work because each side can punish the other for broadcasting an outdated, revoked balance. Before the fix, Core Lightning could instead mistake that cheat for a routine cooperative close, letting the penalty path go unused. Bitcoin Optech’s Sept. 25 explanation made the already-shipped patch legible to operators.

PR 9509 Closes the Shutdown-Script Loophole in Revoked Commitments

The bug required a specific setup. A peer that had not specified an upfront shutdown script when opening a channel could later name the output script of its own revoked commitment inside a shutdown message.

It could then abandon the cooperative close and broadcast that old commitment instead. Because every output matched a shutdown script already on record, Core Lightning read the funding spend as legitimate and skipped the penalty check.

The patch adds a regression test confirming the fix. The fix now checks a transaction’s locktime and sequence encoding to recognize a commitment before it ever considers the outputs as a possible mutual close.

Docker Images Misreported the Fix for Four Days

Operators who pulled Core Lightning through Docker during the initial rollout face a separate risk. The project’s release notes say images served under the v26.06.7 tag between Aug. 28 and Sept. 1 reported the corrected version number on startup while still running the vulnerable code underneath.

The project has since published corrected image digests and told users with a mismatch to re-pull the image. Anyone running a build older than v26.06.7, or a Docker image from that four-day window, should treat the update as unfinished.

Core Lightning now strongly recommends v26.06.8, released Sept. 22 with additional security fixes and immediately available source, though maintainers note a few tests remain withheld. That sequencing matters: an operator who updated on Aug. 28 assuming they were safe may not have been, depending on which artifact they pulled and from where.

What Changes in Practice, and What the Patch Notes Do Not Say

For channel operators, the practical shift is narrow but consequential. Previously, a counterparty exploiting the shutdown-script gap could walk away from a stale channel state without forfeiting funds to the penalty transaction that is supposed to deter exactly that behavior.

After the fix, Core Lightning checks transaction shape before it checks outputs, closing that path regardless of whether a peer specified an upfront shutdown script at open time.

The pull request’s own maintainers are careful to frame this as a narrowed capability rather than a confirmed loss: it documents “a potential way to evade the penalty,” not a recorded theft. What the materials do not establish is how many live channels ran the vulnerable configuration, or whether any counterparty attempted the exploit before Optech’s disclosure made it public.

The developers also note this is a Core Lightning implementation issue, not a change to Bitcoin’s base-chain consensus rules, so other Lightning node software is unaffected by this specific defect.

The CCS read. This is a routine implementation bug, not a protocol failure, but it is the kind institutional custodians running Lightning infrastructure need surfaced fast. The real exposure sits with operators who trusted a version string rather than a digest during the Aug. 28 to Sept. 1 window, a gap that ordinary node monitoring would not have caught without Optech’s writeup.

Core Lightning maintainers have not disclosed whether any node operator’s channel was actually exploited under the pre-patch behavior, and the project has not said how many Docker deployments still carry the mismatched Aug. 28 to Sept. 1 digest. Operators on builds older than v26.06.8 are the open question until they confirm and re-pull.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

Liquid loses 3,960 Bitcoin to software flaw despite securing private keys
Bitcoin

Liquid loses 3,960 Bitcoin to software flaw despite securing private keys

, , , , , ,

BlockchainCrypto Coin Show News Team·September 20, 2026·5 min read

Nearly 4,000 Bitcoin left Liquid’s reserve on September 6 despite private keys remaining secure, exposing a gap between cryptographic protection and financial accountability that insurance alone cannot bridge. Institutional custodians and exchanges must now clarify whether customers are covered for losses from software flaws, and whether compensation means replacing coins or paying a dollar amount.

  • Attackers exploited a software flaw to create L-BTC without depositing Bitcoin, then redeemed those tokens for real coins from the reserve.
  • Coinbase’s crime insurance covers only a “portion” of digital assets and excludes losses from compromised login credentials, with total losses potentially exceeding recoveries.
  • Compensation agreements may specify dollars rather than coins, meaning a customer repaid in full dollar terms could receive fewer Bitcoin if the price has risen.
  • ~3,960 BTC withdrawn from Liquid reserve on September 6 despite secure private keys
  • 3,400 BTC returned by attackers on September 7, reducing shortfall but not determining liability
  • $250,000 FDIC deposit insurance limit per account, not applicable to digital assets

Software accepted a withdrawal that should never have qualified. According to TRM Labs’ reconstruction of the attack, Liquid operators approved the transaction despite consulting incorrect account balances, much as multiple signers might authorize a payment based on shared false data. The lesson inverts the axiom that protecting private keys protects crypto. Cryptographic security means nothing when the software authorizing those keys approves the wrong payment. That raises the billion-dollar question: who pays to put the money back?

Coinbase Insurance Covers Only a Portion and Excludes Credential Breaches

Crypto insurance exists, but the gap between “insured” and “fully protected” is vast. Coinbase’s public disclosure of its crime insurance states that coverage protects a “portion” of digital assets against theft and cybersecurity breaches. The policy also warns that total losses could exceed insurance recoveries, and excludes losses from unauthorized account access caused by compromised or lost login credentials. Two customers might face identical account depletion with completely different insurance outcomes depending on how the breach occurred.

The insurer’s agreement is with the company holding your Bitcoin, not with you.

If a loss exceeds insurance proceeds, the custodian must fund the gap from its own capital or negotiate with the insurer. Neither obligation is visible from your account balance. Whether you can claim directly, what payout mechanism applies, and how long reimbursement takes all depend on contracts you cannot see.

A provider might promise to replace specified losses and hold enough capital to cover an insurance shortfall; another might make a far more limited commitment despite advertising the same word: “insured.”

FDIC Protects Bank Deposits But Not Digital Assets Held Through Banks

The U.S. regulatory framework creates a false sense of security for customers who buy Bitcoin through an insured bank. The FDIC protects eligible deposits when an insured bank fails. That protection does not extend to digital assets, even when they are purchased through an insured institution and appear in the same app as cash. A customer seeing Bitcoin and dollars side by side has no way to know they carry fundamentally different protections.

Digital assets fall outside the federal safety net that covers traditional deposits.

Private insurance fills that gap, but private policies are negotiated between businesses, not mandated by law. The result is a patchwork where two crypto services can both advertise insurance coverage and deliver radically different levels of customer protection.

Institutional investors comparing custodians cannot rely on the word “insured” alone; they must read the actual policy terms, assess the provider’s capital reserves, and understand whether repayment is measured in coins or dollars.

Software Errors Can Trigger Liability Claims, But Recovery Takes Time

When software fails, multiple insurance claims may overlap and compete. Relm, a specialist insurer for crypto firms, offers digital asset crime coverage for infrastructure exploits and theft via smart contracts, alongside technology errors and omissions policies. A storage provider hit by a withdrawal software flaw might claim against its own crime policy, pursue a claim against the software vendor’s liability coverage, and face customer demand for immediate repayment. Each claim serves a different purpose and moves at different speed.

Liquid shows why recovering assets and assigning responsibility are separate tasks. According to Bitquery’s investigation, attackers returned 3,400 BTC on September 7. Blockstream later rejected a bounty demand, as reported by CryptoSlate.

Every coin recovered reduces the shortfall, but repayment by an attacker does not determine who must fund any remaining gap. That turns on obligations which the transaction record alone cannot establish.

Compensation Agreements May Promise Dollars, Leaving Customers Short of Coins

Even a binding payout must specify what is being replaced. A customer who lost one Bitcoin worth $80,000 might sign an agreement promising $80,000 in compensation. If Bitcoin costs $100,000 when payment is made, that customer receives the promised dollars but can buy only 0.8 BTC. The dollar amount has been repaid in full while a fifth of the original Bitcoin holding is still gone.

If the price falls during the wait, the same dollars buy more Bitcoin; the risk of price movement passes to whoever the contract assigns it to.

Getting coins back into a wallet is not the same as resolving the loss.

Allocating recovered coins among people entitled to repayment is a separate problem from getting them into custody. Someone who eventually receives every coin back may have spent weeks unable to meet a payment or move savings, and replacing the asset does not automatically compensate for those consequences.

These complications expose a hard limit to the instruction that customers should do their own research. Few people can inspect the software approving their Bitcoin withdrawals or compare its possible failures against an insurance policy negotiated between their provider and a third party, neither of which they may ever see.

The CCS read. We hold that institutional custodians should be required to publish not just that they are insured, but the specific losses they will repay and whether repayment is in coins or dollars. This disclosure should also state how they would fund a gap between customer obligations and insurer proceeds. Market competition for institutional deposits would then reward clarity and capital strength, not opaque marketing of the word “insured.”

Institutional investors should demand that any potential custodian provide written confirmation of which specific loss categories are covered, the amount of insurance in force, whether the provider will fund gaps from its own capital, and whether compensation is measured in coins or dollars, and require that commitment in the customer agreement before moving assets.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

Malicious bots are actively probing exposed Bitcoin payment servers to steal master administrative keys
Bitcoin

Bots exploiting BTCPay restart vulnerability to steal Lightning Network administrative keys

, , , , , , ,

Bitcoin·3 min read

Malicious bots are systematically scanning for exposed Bitcoin payment servers running BTCPay to exploit a timing vulnerability and steal administrative credentials for Lightning Network nodes. This represents an active, ongoing threat to merchant wallets even as developers patch the software, targeting operators who manually restored access after a prior August breach.

  • Bots are probing exposed LND password-change endpoints during a brief window after node restart when macaroon authentication is not required.
  • BTCPay version 2.4.4, released September 7, closes the restart vulnerability and rotates shared default passwords on older installations.
  • Custom deployments and manually exposed infrastructure remain vulnerable; operators must audit proxy rules and migrate behind BTCPay’s managed controls.
  • 3 BTC Maximum bounty cap for recovered funds from the August breach, then worth about $190,000
  • 2.4.2 Last affected BTCPay version before the August vulnerability was patched in subsequent releases
  • Sept. 11 Date a route-control change merged to enable remote access through supported, managed paths

BTCPay Server, a widely adopted open-source Bitcoin payment processor, disclosed that automated systems are actively targeting exposed Lightning nodes to extract master administrative keys. The bots exploit a narrow but critical window that opens after LND (Lightning Network Daemon) restarts while the wallet remains locked. During this interval, the password-change endpoint does not require a macaroon, the cryptographic credential normally required to authorize administrative actions, creating an attack surface for anyone with network access to the interface.

Restart-window vulnerability targets servers with manually exposed LND access

The current bot activity differs from the August vulnerability but follows a similar exploitation pattern. In August, attackers compromised all BTCPay versions before 2.4.2 by obtaining unauthenticated access to LND macaroon files, allowing them to move funds directly from merchant wallets.

This time, the threat vector is more narrowly bound to timing: an attacker must reach the password-change interface immediately after LND restarts, before BTCPay’s internal unlocker process completes.

The risk escalates for operators running older BTCPay installations that used a shared default password across deployments.

An attacker who submits that default password first, changes it, and requests a new administrator macaroon gains control over the entire LND node. BTCPay disabled external LND access in its standard Docker deployment following the August breach, but operators who manually restored that access to support remote operations remain exposed to the bot probing.

BTCPay has not reported any successful takeovers through this newly observed activity, nor has it linked the bots to the threat actors behind the August theft.

Version 2.4.4 hardens default credentials and closes restart-window access

BTCPay released version 2.4.4 on September 7 to address the restart-window vulnerability. New LND wallets now receive unique random passwords instead of a shared default, and older installations using the shared credential are automatically migrated with passwords rotated. The standard reverse proxy now blocks unauthenticated wallet setup and unlock methods at the network perimeter, closing the restart-time opening for any traffic routed through BTCPay’s managed public path.

Those protections apply only to infrastructure deployed according to BTCPay’s standard architecture. Administrators who configured their own reverse proxy or exposed LND directly to the internet can still bypass BTCPay’s controls entirely. The project has urged operators to install 2.4.4 and remove manually exposed LND routes, emphasizing that custom deployments cannot rely on the default hardening measures.

Custom deployments require manual audit as bots continue scanning the network

A route-control change merged on September 11 now provides a supported, managed pathway for remote LND access that keeps the interface disabled by default.

Operators running custom infrastructure must audit their reverse proxy rules immediately to identify any publicly exposed LND or Core Lightning endpoints. Those who need remote access should migrate their configurations behind BTCPay’s official managed controls while automated systems continue searching for reachable nodes.

The urgency reflects the active, ongoing nature of the bot scanning; attackers are not waiting for slower manual patching cycles to complete across the merchant ecosystem.

BTCPay’s security team has not announced a timeline for mandatory updates or forced migration of custom deployments, leaving the responsibility on individual operators to detect their exposure and remediate before bots locate their infrastructure.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

The biggest vulnerability in your Bitcoin wallet might be the shipping label
Legal & Crime

Trezor breach exposes 80,689 customers to phishing through retained shipping records

, , , , , ,

BitcoinSeptember 12, 2026·3 min read

Hardware wallet manufacturers collect names and addresses essential for delivery, but these details can persist in vendor databases for years and become tools for targeted phishing attacks against Bitcoin holders. A Trezor breach affecting 80,689 customers demonstrates how shipping records, considered temporary operational data, expose users to identity-based social engineering even after devices arrive and private keys remain secure.

  • Trezor disclosed that approximately 67,000 additional US customers were affected by a ShipMonk breach, with records spanning 2019 to 2021 orders.
  • Leaked information included only contact and delivery details; no private keys, wallet contents, or funds were exposed or stolen.
  • Physical mail and personalized email using shipping data enable convincing phishing campaigns targeting wallet recovery words, bypassing device-level security.
  • 80,689 Total Trezor customers affected by shipping provider breach disclosure overall
  • 2019-2021 Years covered by affected orders in the Trezor ShipMonk incident
  • 0 Financial losses reported so far despite customer data exposure

Hardware wallet manufacturers sell security by keeping private keys isolated from internet-connected computers, yet the purchase process creates an unprotected record that outlasts the device’s usefulness. According to reporting on the incident, Trezor’s Sept. 4 update to its shipping-provider breach disclosure revealed that ShipMonk, the fulfillment vendor, retained customer contact and delivery information from orders placed years earlier. Trezor confirmed that its own systems and devices were unaffected, that parcel contents remained secure, and that no financial theft occurred. But the absence of immediate financial loss masks a persistent vulnerability: a home address tied to a Bitcoin purchase creates a permanent target for impersonation and social engineering.

Shipping records enable targeted phishing campaigns against wallet owners

A thief with a customer’s name and address can craft messages that feel legitimate in ways generic spam cannot. Ledger’s record of phishing campaigns documents instances of physical letters directing recipients to scan codes or visit fraudulent websites where they are prompted to share recovery words. An email addressed to you by name, referencing an order from years ago, carries far more credibility than a mass mailing sent to millions.

Letters delivered to your home can easily mimic official correspondence, even when their instructions are fraudulent.

The attack succeeds not by compromising the hardware wallet itself but by persuading the owner to voluntarily hand over backup recovery words, the only credential that bypasses device-level protection entirely.

A name and address alone cannot drain a wallet, but they transform a broad attack into a precision strike against someone the scammer can credibly impersonate as a business or service provider the customer once trusted.

Permanent data retention exposes customers long after purchase purposes expire

Shipping information serves a legitimate short-term function: routing parcels, resolving delivery failures, and processing returns. That temporary operational need does not justify permanent storage. The Federal Trade Commission’s business guidance establishes a straightforward principle: collect and retain sensitive information only for a legitimate business need, know where it goes, and dispose of it securely. Yet retailers and their fulfillment partners routinely retain old records in database replicas, support-system exports, and backups long after removal from active systems.

A deletion clause in a contract and a vendor’s assurance that records were removed are not the same as direct evidence that every storage system, including replicas, exports, and backups, actually applied the retention policy. Manufacturers choose the warehouse and negotiate the contract, giving them leverage to demand proof of secure disposal. Most do not.

Home addresses remain valid long after the original purchase is forgotten, and a copied record cannot be recalled from everyone who received it.

Manufacturers must demand evidence of data deletion, not accept vendor assurances

Protecting the person who buys a hardware wallet requires manufacturers to establish retention limits before a breach occurs. This means collecting less information where possible, separating data that does not need to travel together, and requiring vendors to prove that old records have been securely deleted when their operational purpose expires.

A parcel locker, neutral packaging, or a separate contact detail for online orders can reduce attack surface, but none of these measures eliminate the retailer’s own database records.

Trezor’s breach demonstrates that contract language alone is insufficient; manufacturers must implement processes to verify deletion across all systems where data is stored or replicated, establish clear retention deadlines tied to operational necessity rather than administrative convenience, and hold vendors accountable with periodic audits rather than one-time assurances. Until hardware wallet makers demand and verify evidence that shipping records are actually removed, buyers will remain exposed to targeted phishing campaigns years after their devices arrive and their private keys are secured.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

LayerZero deploys quantum-resistant cryptography with 2029 deadline for institutional migration
Institutional

LayerZero deploys quantum-resistant cryptography with 2029 deadline for institutional migration

, , , , , ,

BitcoinSeptember 9, 2026·3 min read

LayerZero and Coinbase are moving from research to production deployment of quantum-resistant cryptography, setting concrete 2029 deadlines that will force institutional custody systems and blockchain infrastructure to migrate away from vulnerable elliptic-curve encryption. For asset managers and custodians, this signals a window to pilot post-quantum systems before regulatory and technical pressure makes migration mandatory.

  • LayerZero shipped Akita, a production-ready zero-knowledge proving system using lattice-based cryptography that cuts proof sizes by 60% and proving time by 50% versus prior systems.
  • Google’s March 2026 quantum research showed breaking 256-bit elliptic-curve cryptography could require fewer than 1,200 logical qubits, down sharply from earlier estimates, with Google targeting 2029 for its own post-quantum migration.
  • Coinbase hosted a closed Stanford workshop where Bitcoin developers and hardware-wallet makers found no consensus on a single signature scheme, signaling migration will proceed iteratively rather than through an industry-wide standard switchover.
  • 65-80 KB Akita proof sizes compared to prior 200 KB benchmarks
  • 2029 Target year for Google, Ethereum, and Coinbase quantum-resistant cryptography deployment
  • 99.9% Percentage of Coinbase customer assets protected by current security architecture

The cryptography protecting Bitcoin, Ethereum, and most major blockchains faces a concrete, measurable threat from quantum computing that has accelerated faster than previously modeled. According to reporting from Cryptopolitan, LayerZero and Coinbase have begun moving beyond research into production systems designed to withstand quantum decryption. The urgency stems from research released by Google Quantum AI in March 2026, in which Ryan Babbush and Hartmut Neven calculated that breaking the 256-bit elliptic-curve cryptography used by most blockchains could require fewer than 1,200 logical qubits and approximately 90 million Toffoli gates, a dramatic reduction from prior estimates. While Google’s current “Willow” quantum chip operates only 105 physical qubits, the trajectory is forcing institutions to begin planning migrations now.

LayerZero ships Akita with 60% smaller proofs and 50% faster verification

LayerZero has introduced Akita, the first production-ready zero-knowledge proving system built on lattice-based cryptography, the same mathematical foundation that the U.S. National Institute of Standards and Technology has already standardized for post-quantum encryption and digital signatures. Akita compresses proof sizes from 200 kilobytes or larger down to between 65 and 80 kilobytes, cuts proving time by two to three times versus LayerZero’s prior Jolt system, and roughly halves memory consumption. The system will initially be deployed within Jolt, the zero-knowledge virtual machine LayerZero developed with a16z crypto, which powers LayerZero’s Zero blockchain.

These efficiency gains matter to institutional operators because smaller proofs reduce bandwidth and storage costs, while faster proving times lower computational infrastructure expenses at scale.

Coinbase workshop reveals no consensus on Bitcoin’s quantum migration path

Coinbase convened a closed Post-Quantum Bitcoin Workshop at Stanford University in collaboration with cryptographer Dan Boneh and Localhost Research, gathering Bitcoin developers, institutional custodians, and hardware-wallet specialists to compare quantum-resistant signature schemes.

The participants examined multiple candidates but discovered trade-offs in security, transaction size, hardware performance, and key management that prevented agreement on a single best approach.

Coinbase also hosted a separate initiative on post-quantum preparation, emphasizing that a well-tested migration plan matters more than the exact year a quantum attack might occur. The company noted that its current architecture already protects approximately 99.9% of customer assets and stated that any transition will likely occur in phases. In July, Coinbase had already introduced PQ-CoreKMS, a post-quantum version of its key-management system designed to operate alongside current infrastructure during a staged rollout.

Ethereum targets 2029, NIST sets 2030-2035 deprecation deadlines

Ethereum’s roadmap for “Lean Ethereum” targets 2029 for full post-quantum protection across consensus-layer BLS signatures, KZG data-availability commitments, account-level ECDSA signatures, and zero-knowledge proof systems.

Google has named Coinbase, the Stanford Institute for Blockchain Research, and the Ethereum Foundation as collaborators on its 2029 post-quantum migration goal. NIST has signaled its own timeline: deprecating ECDSA by 2030 and disallowing it entirely by 2035.

The convergence of these deadlines means institutional operators have less than five years to pilot, test, and deploy quantum-resistant systems before both regulatory pressure and technical necessity force a broader industry transition.

The absence of consensus on a single Bitcoin signature scheme means different custodians and exchanges may implement different post-quantum solutions during the migration window, creating operational complexity for institutions that manage assets across multiple chains. Watch for announcements from major hardware-wallet makers and custody providers on which specific signature schemes they will support by 2028, and whether Bitcoin’s developer community proposes a soft fork or upgrade to lock in a preferred standard before the 2029-2030 regulatory and technical deadlines take full effect.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

Coldcard Firmware 5.6.1 Forces User Entropy Into Every New Seed After $100M Exploit
Blockchain

Coldcard Firmware 5.6.1 Forces User Entropy Into Every New Seed After $100M Exploit

, , , , , ,

BitcoinAugust 22, 2026·5 min read

Coinkite has released firmware requiring manual entropy input for all new Coldcard seeds, a mandatory security patch following a critical random-number generator flaw that exposed approximately $100 million in Bitcoin to attackers. For institutional custody operators and hardware wallet users, this represents both an immediate remediation requirement and a sobering reminder that even air-gapped devices require active verification of their cryptographic foundations.

  • Firmware 5.6.1 mandates at least 50 dice rolls, 128 coin flips, or 65 timed keypad presses before seed generation can complete on Mk4 and Mk5 models.
  • A build error in firmware shipped from March 2021 through July 2026 routed seed entropy to an unintended software PRNG instead of hardware, reducing entropy from 128 bits to approximately 72 bits.
  • Confirmed losses exceed $100 million across roughly 7,300 addresses, with attackers recovering 1,596 BTC in at least four separate waves between July 30 and August 3.
  • 594.5 BTC swept from 500 addresses on initial exploit date of July 30
  • 72 bits of entropy generated versus intended 128-bit standard in affected seeds
  • 7,300 addresses impacted across four confirmed attack waves through August 3

Coinkite disclosed on August 13 that a firmware build failure had diverted seed entropy generation away from Coldcard’s hardware true random number generator (TRNG) into MicroPython’s Yasmarang software PRNG, a cryptographically weak alternative that left all seeds generated between March 2021 and July 2026 vulnerable to practical recovery.

The defect, traced to a disabled security flag during compilation that went undetected through the device’s boot verification sequence, opened a window spanning roughly five and a half years during which attackers could enumerate the reduced seed space and derive private keys.

On July 30, confirmed losses began accumulating rapidly: 594.5 BTC was swept from 500 addresses in the initial attack, followed by waves totaling 1,596 BTC across approximately 7,300 addresses by August 3, making this one of the largest institutional custody failures in recent blockchain history.

Build Error Disabled Hardware RNG Path, Routing Seeds Through Weak Software Generator

The technical root cause was straightforward but devastating: a configuration flag meant to enforce hardware-only entropy was left inactive during the build process, allowing the random-number generation call to fall through to MicroPython’s Yasmarang PRNG instead of the STM32 microcontroller’s dedicated TRNG and secure elements.

Coldcard’s architecture had been designed with redundancy, entropy was meant to be drawn from both the STM32 hardware generator and two separate secure element chips, but the software path became the default when the hardware enforcement mechanism failed silently.

Yasmarang, a software-based pseudorandom number generator, is not cryptographically suitable for key material. Seeds generated through this path carried approximately 72 bits of entropy instead of the intended 128 bits, reducing the search space from 2^128 to 2^72, a difference that moved private key recovery from computationally infeasible to practical within weeks.

The flaw went unnoticed because Coldcard’s existing firmware shipped without a boot-time verification that the hardware path was actually being used; the device simply assumed its configuration was correct and proceeded to generate seeds.

Firmware 5.6.1 Adds Hardware Path Verification and Mandatory User-Supplied Entropy

The patch introduces two independent mitigations. First, Coldcard now performs a cryptographic boot check that verifies seed entropy actually reaches the hardware RNG before allowing the device to complete startup; if the path is broken or misconfigured, the device halts with an error rather than silently degrading to software generation.

Second, firmware 5.6.1 and 1.5.1Q (for the larger Q model with keyboard and QR scanning) require manual entropy injection from the user, at minimum 50 dice rolls, 128 coin flips, or 65 timed keypad presses, before any new seed can be finalized.

The user-supplied entropy is combined with refreshed hardware randomness from both secure elements, seeded at startup with a full 256-bit SHA-256 Hash_DRBG derived from NIST SP 800-90A specification. Earlier firmware had truncated the secure element output to only 32 bits; the new build uses the full digest.

For the keypad-based entropy method, Coinkite implemented a design originally proposed by developer Peter Todd that credits two bits of entropy per keypress gap, measured at CPU-cycle resolution. The first press establishes a timing reference, and each of the 64 subsequent gaps contributes to the entropy pool through high-resolution timing measurements.

Existing Seeds Remain Vulnerable; Migration Mandatory for Affected Users

Coinkite stated explicitly that “installing this update does not make an existing vulnerable seed safe.” Any Coldcard user whose device generated a seed between March 2021 and July 2026, the entire window during which affected firmware was in production, must assume that seed is compromised and create a replacement immediately, then migrate all Bitcoin holdings to a new address derived from the fresh seed.

The advisory affects Coldcard Mk4 and Mk5 models running firmware 5.6.1 and the Q model running 1.5.1Q. Older Mk2 and Mk3 models are not covered by this release; their minimum fixed version remains 4.2.0, indicating they were either unaffected or receive updates through a separate track.

Coinkite has not provided a tool to determine whether a specific device generated a vulnerable seed without external analysis, forcing users into a conservative posture: unless they can prove their device was updated before March 2021 or activated after July 2026, migration is prudent.

The scope of affected devices remains uncertain, as Coinkite has not disclosed shipment numbers or activation dates for units sold during the vulnerable period.

Second Vulnerability Discovered in Transaction Approval Process

During the post-breach investigation, Coinkite identified a second defect that would have allowed a compromised USB host, a connected desktop or laptop executing attacker code, to rewrite a transaction after the user approved it on the Coldcard display, changing the outputs without invalidating the signature.

An attacker who could intercept the USB connection could display one transaction to the user for approval, then substitute a modified version for signing, with the device’s signature applying to the attacker’s revised outputs instead.

Firmware 5.6.1 now rechecks the transaction bytes immediately before signing and halts with a “Transaction modified” warning if any discrepancy is detected.

This remediation adds a verification layer that closes the window between user approval and cryptographic signing, though it assumes the Coldcard’s display and user interface remain trustworthy, the device cannot detect a compromised host that modifies data before the initial transaction is shown.

Coinkite Publishes Independent Review Results; Audit Scope Explicitly Capped

In response to institutional custody concerns, Coinkite published a new Security Status page documenting four independent reviews, including a real-device test that observed the hardware RNG reads directly and conducted byte-for-byte verification of the signed firmware binary.

The company was transparent about limitations: the reviews represent targeted testing of specific security concerns, not a comprehensive audit of every firmware component.

One review examined hardware RNG behavior by instrumenting eight separate reads for a 32-byte seed request, validating that entropy actually originated from the STM32 and secure elements. Another rebuilt the entire firmware binary and confirmed that every byte matched the signed release, ruling out any hidden code insertion or divergence between source and compiled versions.

However, Coinkite explicitly noted these checks “are not a complete audit of every firmware binary,” leaving room for subtle logic errors or attack vectors outside the reviewed scope to remain undiscovered.

Institutional Custody Operators Face Immediate Key Rotation and Disclosure Decisions

For institutional users, cryptocurrency exchanges, custody providers, and enterprise treasuries that held Bitcoin on Coldcard devices,

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

AI Bitcoin Security Campaign Finds Nearly 5,000 Software Issues in 390 Projects
Bitcoin

AI Bitcoin Security Campaign Finds Nearly 5,000 Software Issues in 390 Projects

, , , , , , ,

AI NewsAugust 8, 2026·5 min read

A coordinated campaign of 16 security researchers using AI tools identified nearly 5,000 software vulnerabilities across 390 Bitcoin projects in just 30 hours, uncovering 85 critical issues that institutional investors rely on for custody, trading, and infrastructure. The findings expose systemic weaknesses in open-source Bitcoin libraries and SDKs at a moment when ecosystem security has become a competitive differentiator for institutional adoption.

  • 4,962 total findings across 390 Bitcoin projects, including 85 critical and 635 high-severity issues discovered in 30 hours
  • 1,385 reported issues concentrated in crypto libraries and software development kits, the largest category of affected software
  • Campaign averaged 166 findings per hour using human-guided AI, yielding 2.3 critical or high-severity issues per person-hour spent
  • 4,962 total software findings across 390 Bitcoin projects in one coordinated campaign
  • 85 critical-severity issues identified, representing systemic risk across infrastructure layer
  • 30 hours timeframe for discovering vulnerabilities versus traditional multi-month security audits

A rapid security review organized by developer Calle and supported by OpenSats, OpenCode, and AI inference sponsors uncovered nearly 5,000 software defects across hundreds of Bitcoin-related projects between July 30 and July 31.

The 16-person research team combined manual code review with artificial intelligence tools to systematically examine 390 open-source projects, yielding 4,962 reported findings in approximately 30 hours of coordinated work.

The scale and speed of the campaign distinguish it from traditional security audits conducted over months by small teams, exposing the potential for AI-assisted vulnerability discovery to accelerate threat identification across decentralized ecosystems.

Crypto Libraries Account for Nearly 1,400 of 4,962 Total Findings

The highest concentration of reported issues appeared in crypto libraries and software development kits, which recorded 1,385 findings, or roughly 28 percent of the total discovered across all project categories.

This concentration matters directly to institutional operators: libraries and SDKs form the foundation upon which exchanges, custody providers, and node operators build production systems. A vulnerability in a widely used library can cascade across dozens of downstream applications simultaneously, creating systemic risk that individual project audits may fail to surface.

Among the 4,962 total findings, 720 issues fell into the critical or high-severity categories, meaning roughly one out of every seven reported findings posed material risk. The team identified 85 critical-severity issues specifically, a figure that reflects vulnerabilities requiring immediate remediation to prevent potential loss of user funds, unauthorized access, or network disruption.

Only one reviewed project completed the campaign without any reported findings, underscoring the breadth of the vulnerability landscape across the Bitcoin development ecosystem.

Researchers have already begun notifying affected project maintainers of verified critical findings, including proof-of-concept demonstrations to confirm exploitability. Many maintainers responded quickly to initial reports, though the sheer volume of findings, averaging 166 per hour, presents a significant operational challenge for smaller teams with limited security resources.

The speed at which issues were surfaced now creates a bottleneck at the remediation stage, where maintainers must prioritize, patch, and coordinate disclosure timelines.

Human-Guided AI Uncovered Weaknesses Traditional Audits Typically Miss

The campaign methodology diverged from conventional security audits in a critical way: human researchers actively directed AI tools throughout the testing process rather than running automated scans independently.

Each of the 16 participants employed different prompts, testing strategies, and analytical approaches, a diversity that proved essential to discovering edge cases and context-dependent vulnerabilities.

This collaborative model yielded approximately 2.3 critical or high-severity issues for every person-hour invested, a productivity metric that suggests AI-assisted review can substantially compress the timeline for identifying material defects.

The human-in-the-loop approach mitigates a known limitation of pure automation: AI systems can generate false positives and may miss subtle logical flaws that require domain knowledge to recognize. By having experienced security researchers guide and validate each finding, the campaign created a filter that elevated signal-to-noise ratio while maintaining broad coverage.

The variety in methodology also prevented a single analytical blind spot from systematically missing classes of vulnerabilities, a risk present in any standardized or single-researcher audit.

One contributor submitted findings collected before the live campaign officially commenced, and those results were subsequently incorporated into the final tally. This suggests the 4,962 figure represents work conducted across a slightly extended window, though the core 30-hour window remains the organizing metric for the campaign’s speed advantage.

The inclusion of pre-campaign findings indicates the organizers prioritized comprehensive coverage over strict temporal boundaries, a pragmatic choice that may have increased the total count but also acknowledged that vulnerability discovery is not perfectly synchronous.

Campaign Timing Reflects Rising Institutional Pressure on Bitcoin Infrastructure Security

The security campaign arrived amid heightened ecosystem attention to Bitcoin software vulnerabilities following recent incidents that directly impacted user custody. In late July, attackers exploited defective firmware in Coldcard hardware wallets to compromise seed generation, prompting a wave of wallet sweeps and forcing users to migrate funds.

Bitcoin’s daily active address count surged to 0.98 million on July 31, the highest level since December 2024, as users moved coins in response to the Coldcard vulnerability and broader concern about wallet security practices.

For institutional investors, the timing of this security campaign signals renewed focus on the strength of the software supply chain underlying Bitcoin infrastructure. Custody providers, exchange operators, and node runners depend on the security guarantees embedded in widely used libraries and client implementations.

A critical vulnerability in any of these components can expose institutional positions to theft, operational disruption, or regulatory exposure, making the cost of inadequate security review substantially higher than the cost of the review itself.

The campaign also reflects a shift in how open-source security is being resourced. By coordinating 16 researchers with AI tooling and institutional sponsorship from OpenSats and other entities, the organizers demonstrated that rapid, large-scale vulnerability discovery is feasible without requiring each project to fund its own dedicated audit.

This model may establish a precedent for periodic coordinated reviews of critical Bitcoin infrastructure, reducing reliance on sporadic, project-by-project audits and creating a baseline security standard across the ecosystem.

Remediation Bottleneck and Disclosure Timeline Present Next Operational Challenge

The discovery phase is now complete, but the remediation and disclosure phases, typically longer and more complex, are just beginning. Maintainers across 390 projects must triage, validate, patch, and release updates for thousands of findings while coordinating disclosure timelines to prevent attackers from exploiting publicly known vulnerabilities before fixes are widely deployed.

This coordination problem grows exponentially with the number of affected projects, and no single entity controls the release cycles of independent open-source teams.

The distribution of findings across project categories and severity levels will determine the urgency and complexity of remediation workflows. Critical issues in widely used libraries may trigger immediate patches and coordinated disclosure windows, while lower-severity findings in niche tools may see slower remediation.

Institutional users will need visibility into which findings affect the specific software components and versions they operate, making clear communication from maintainers and coordinating bodies essential to risk management decisions.

The open question now centers on coordination mechanisms for disclosure and patching: whether maintainers will adopt a staggered, coordinated release schedule to minimize the window of public vulnerability, and whether ecosystem participants will maintain a shared registry tracking remediation status across all 390 affected projects. Watch for announcements from OpenSats, OpenCode, and individual maintainers regarding standardized disclosure timelines and for any public guidance from Bitcoin Core developers on prioritization of critical issues affecting node implementations and widely deployed libraries.

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

Michael Saylor Says Bitcoin Has Won, So Why Did MicroStrategy Stop Buying BTC?
Bitcoin

Michael Saylor Says Bitcoin Has Won, So Why Did MicroStrategy Stop Buying BTC?

, , , , , ,

BitcoinJuly 28, 2026·5 min read

Michael Saylor’s abrupt halt to MicroStrategy’s Bitcoin purchases signals deepening concern over a contentious protocol change set for mandatory activation in August 2026. The move underscores a critical split between major Bitcoin stakeholders over network governance, with implications for long-term security economics and institutional confidence in Bitcoin’s rule-setting process.

  • MicroStrategy has not purchased Bitcoin in five consecutive weeks, accumulating $3.75 billion in cash instead.
  • BIP-110, a proposed soft fork capping arbitrary data in transactions, begins mandatory lock-in signaling window around August 2026.
  • Saylor frames the proposal as a threat to Bitcoin’s consensus rules and long-term security economics dependent on fee markets.
  • $3.75B Cash reserve MicroStrategy built instead of buying Bitcoin
  • Aug 2026 Deadline for mandatory BIP-110 lock-in window activation
  • 55% Lowered activation threshold that triggered Blockstream CEO’s fork-risk warning

Michael Saylor’s public statement that Bitcoin has won came paired with a striking contradiction: his company, MicroStrategy, has ceased Bitcoin purchases entirely. For five consecutive weeks, the firm that built a corporate treasury strategy around accumulating the asset has remained on the sidelines, instead stockpiling $3.75 billion in cash. The timing is not coincidental.

A proposed protocol change known as BIP-110 has triggered a rare moment of vulnerability in Bitcoin’s governance, with mandatory activation now scheduled for August 2026 and a lock-in window imminent.

Saylor’s warning against the proposal, and his company’s sudden withdrawal from the market, signal that prominent institutional holders now view the network’s consensus process itself as a material risk.

MicroStrategy’s Five-Week Buying Halt Coincides With Protocol Change Concerns

MicroStrategy’s absence from the Bitcoin market during a five-week window stands in sharp contrast to the company’s established posture as a relentless accumulator. The firm had built its corporate strategy around dollar-cost averaging into Bitcoin, positioning itself as the largest publicly traded holder of the asset.

The pause, analyzed by blockchain intelligence firm Arkham, reveals a deliberate shift: rather than deploy capital into Bitcoin, the company chose to build a $3.75 billion cash reserve.

Saylor’s framing of this decision centers on governance risk rather than price or market conditions. The executive chairman did not cite volatility, regulatory headwinds, or macroeconomic concerns as reasons for the pause.

Instead, his public statements targeted the technical and economic implications of BIP-110, a proposal that would cap the size of arbitrary data fields embedded in Bitcoin transactions. This was not a casual observation.

Saylor’s warning came as miner signaling for the proposal began on December 1, 2025, and with the knowledge that Bitcoin’s own deployment schedule would force a mandatory decision point within months.

The strategic pause underscores how deeply institutional Bitcoin holders now track protocol governance decisions and their potential impact on network security and property rights.

BIP-110’s Mandatory Activation Calendar Creates Unprecedented Governance Pressure

Unlike most protocol proposals that require broad consensus and can linger indefinitely if support is weak, BIP-110 operates on a binding timeline. The proposal began miner signaling on December 1, 2025, and its deployment schedule sets a mandatory lock-in window for around August 2026. That window is not a suggestion.

Once it opens, blocks that fail to signal acceptance are rejected as invalid, making lock-in guaranteed regardless of whether miners or developers actively support the change.

Activation follows two weeks after lock-in, and the rules expire approximately one year after that. This structure means that BIP-110 will become part of the network unless actively opposed during the signaling window, a reversal of Bitcoin’s traditional governance logic, where changes require affirmative consensus rather than escape the absence of opposition.

Developer Dathon Ohm wrote the proposal and shipped it in Bitcoin Knots, but miner support has been sparse. That indifference has not prevented the proposal’s progress toward activation.

Saylor’s public opposition targets the proposal itself, but his company’s purchasing halt reflects concern about a deeper issue: the governance process that allows a change with marginal support to become mandatory through procedural timing rather than ecosystem consensus.

The lowered 55% activation threshold, a reduction from Bitcoin’s historical standards, amplified concerns among major stakeholders, drawing criticism from Blockstream CEO Adam Back as well.

Saylor’s Technical Critique Centers on Bitcoin’s Long-Term Security Economics

Saylor’s central claim rests on the relationship between transaction fees and network security. Bitcoin’s block subsidy halves every 210,000 blocks, and this halving schedule is embedded in the protocol’s foundational rules.

As subsidies decline toward zero over the next century, transaction fees must carry an ever-larger share of the security budget, the total value paid to miners for processing blocks and securing the network. BIP-110, in Saylor’s reading, weakens the fee market by censoring certain valid transactions, thereby disarming the network’s long-term economic incentive structure.

Bitcoin has won. Now it must survive victory. Its gravest threat is not an enemy at the gates, but corruption from within: factions that invent pretexts, rewrite the rules, and seize economic rights until freedom becomes permission and law becomes loot.

Michael Saylor, Executive Chairman, MicroStrategy

He framed Bitcoin’s consensus rules as a constitution that defines property, scarcity, settlement, and power. Rewriting those rules to suit any faction, he argued, attacks every participant alive today and every one who comes later.

He identified three specific targets: BIP-110’s data censorship, covenants that create new attack surfaces, and larger blocks that thin blockspace scarcity and raise validation costs. Each, in his view, threatens the economic conditions that ensure long-term security.

This framing treats protocol changes not as technical improvements but as potential transfers of economic rights from the entire network to specific factions.

Opposition to BIP-110 Spans Institutions but Diverges on Core Concerns

Saylor is not alone in opposing BIP-110, though the coalition against it is ideologically fractured. Blockstream CEO Adam Back also opposes the proposal, but his critique targets a different problem: the lowered 55% activation threshold rather than the censorship question.

Back warned of fork risk and compared the activation process unfavorably to SegWit, which achieved both technical and ecosystem consensus before activation. His concern centers on the procedure itself, not the substance of the proposal.

BIP-110’s backers counter that arbitrary data embedding burdens node operators by bloating the blockchain and crowds out payments-related transactions. This fundamentally opposing claim, that the proposal prevents network harm rather than causes it, reflects a genuine technical disagreement unresolved by peer review or deployed evidence.

Critics do not agree with each other on which specific aspects of BIP-110 pose the greatest risk.

This fragmentation of opposition creates a governance vacuum where no single alternative narrative can command ecosystem consensus.

Institutional Cash Hoarding Signals Hedging Against Protocol Uncertainty

MicroStrategy’s decision to accumulate $3.75 billion in cash rather than purchase Bitcoin during a period when the asset had not experienced major price declines reveals the weight institutional holders now assign to governance risk. The company did not stop buying because Bitcoin’s market price became unattractive relative to history.

It stopped because the protocol itself entered a governance crisis.

For institutional investors, governance risk is distinct from market risk or regulatory risk. It is the uncertainty that the rules defining an asset’s supply, scarcity, and security could be rewritten by a minority faction through procedural means.

MicroStrategy’s cash reserve functions as a visible hedge: capital held in reserve until the August 2026 window passes and the network’s response becomes clear.

This posture has downstream effects. If one of Bitcoin’s largest publicly traded holders is sufficiently concerned to pause accumulation, other institutional participants are likely tracking the same governance signals. The cash reserve also keeps capital deployed but ready to move, signaling to other market actors that major institutional

Get this in your inboxThe Crypto Coin Show newsletter covers the policy and market moves institutional crypto investors are pricing in.

Subscribe

Load More