This week’s newsletter warns about a severe vulnerability affecting wallets generated by COLDCARD signing devices, summarizes the disclosure of two denial-of-service vulnerabilities in Core Lightning, and describes a proof of concept for a zero-knowledge proof of reserves. Also included are our regular sections with selected questions and answers from the Bitcoin Stack Exchange, announcements of new releases and release candidates, and descriptions of notable changes to popular Bitcoin infrastructure software.

Action items

  • ● Move funds secured by COLDCARD-generated keys: if you used a COLDCARD Mk3 to generate a wallet, any funds received by that wallet are at risk of theft and should be carefully moved to an unaffected wallet as soon as possible. Wallets generated by other COLDCARD models may also be affected. See the News section below for details.

News

  • ● Wallets generated by COLDCARD at risk of theft: On 30 July 2026, some Bitcoin users discovered that funds from their COLDCARD wallets had been stolen in a series of unexpected transactions on 29 July. Over the course of the day, a bug was identified in the firmware of the COLDCARD Mk3 that causes wallets to be generated with insufficient entropy. As of this writing, estimated losses exceed 1,000 BTC, a figure that may continue to rise as the situation develops.

    A security advisory by Coinkite identified wallets generated by COLDCARD Mk3 using firmware version 4.0.1 (March 2021) or later, including the latest released version, as vulnerable to theft, unless the seed was created with sufficient externally generated entropy (such as 50 or more private dice rolls) or the wallet was additionally encumbered with a strong passphrase. The advisory also identifies seeds generated by Mk4 and Mk5 firmware before version 5.6.0 and Q firmware before version 1.5.0Q as affected.

    In a follow-up technical backgrounder, Coinkite attributes the bug to a 2021 code change that unintentionally routed seed generation to a software PRNG, initialized from predictable device-unique values, instead of the device’s hardware RNG. Seeds generated by an affected Mk3 without supplemental dice rolls have roughly 40 bits of effective entropy instead of the intended 128. Seeds from affected Mk4, Mk5, and Q devices are harder to attack because output from a secure element is also mixed in, although an analysis by Block, performed with anonymous researchers and disclosed in coordination with Coinkite, found that only 32 bits of that entropy reach the PRNG state, leaving those seeds still well below the intended security level.

    Several developers were able to immediately reproduce the attack with the assistance of frontier AI models, so the vulnerability should be assumed to be under active exploitation. Block’s analysis additionally identifies the older COLDCARD Mk2 running 4.x firmware as affected to the same degree as the Mk3, and notes that other randomly generated secrets, such as paper-wallet private keys and ephemeral seeds, are also affected.

    This is an evolving situation, and additional information is likely to emerge after this newsletter’s publication. Readers should monitor Coinkite’s blog and other sources for updates. Bitcoin Optech recommends that COLDCARD users whose wallets may be affected move their funds carefully to an unaffected wallet as soon as possible. Seeds generated on an affected device without supplemental dice rolls should be treated as compromised. Users of Mk4, Mk5, and Q devices should upgrade to fixed firmware before generating any new wallets. Upgrading alone does not make an existing seed safe.

  • ● Disclosure of two DoS vulnerabilities in Core Lightning: Chandra Pratap posted to Delving Bitcoin about two denial-of-service (DoS) vulnerabilities he found in Core Lightning during his internship for the Summer of Bitcoin program. Specifically, these vulnerabilities would have allowed an attacker to crash a node by exhausting its memory. The bugs are related to the gossipd daemon state machine, in particular to its interface with the connectd daemon. Pratap was able to find the vulnerabilities thanks to his work on a new fuzz target, fuzz-gossipd-connectd, which aims to test the robustness of the communication between the two modules.

    The first vulnerability was related to the inter-daemon message queue, shared between the two daemons, whose goal is to store all the channel_update messages arriving from the network. An attacker would have been able to flood the node with messages, causing the internal queue to grow indefinitely and leading to the consumption of all the available RAM. The bug was simply fixed in Core Lightning #8376 by allowing the queue to drop messages, adding a cutoff point at 500,000 messages.

    The second vulnerability was found while trying to fix the first one. In particular, this was related to the internal map used to track unknown short channel IDs (SCIDs) to query peers for possible missing channels. An attacker would have been able to flood the node with fake SCIDs, causing an ever-increasing memory consumption. Although the bug had not been previously reported, Rusty Russell was already working on a patch in Core Lightning #8903, which introduced an improved garbage collection mechanism for the internal map.

  • ● Proof of concept for a zero-knowledge proof of reserves: fabohax posted about zkPoH (“zero-knowledge proof-of-hodl”), a proof of concept for a non-custodial proof of reserves system for Bitcoin. The prototype allows a user to prove that they control a set of UTXOs, whose combined value is at least 100,000,000 sats (1 BTC), without revealing any further information.

    The proof of concept takes as input a UTXO snapshot generated off-chain, which is then committed into a merkle tree, whose root becomes the public commitment. The prover selects up to four UTXOs from the snapshot and generates the witness input for the Noir circuit, which verifies that the chosen UTXOs actually belong to the snapshot, the merkle paths are valid, and the sum of the selected UTXOs is at least the required amount. The verifier only learns that the prover satisfies the 100,000,000 sats requirement.

    As of this writing, an explicit ownership binding step is not available in the proof of concept. This means that there is no way to prove that the chosen UTXOs actually belong to the prover. The author is currently working on adding this feature, either through an off-circuit ownership check or directly inside it. The prototype is currently available in a dedicated repository.

Selected Q&A from Bitcoin Stack Exchange

Bitcoin Stack Exchange is one of the first places Optech contributors look for answers to their questions—or when we have a few spare moments to help curious or confused users. In this monthly feature, we highlight some of the top-voted questions and answers posted since our last update.

Releases and release candidates

New releases and release candidates for popular Bitcoin infrastructure projects. Please consider upgrading to new releases or helping to test release candidates.

  • ● BTCPay Server 2.4.1 is a maintenance release for this self-hosted payment processor. It adds BIP329 wallet label imports (see Newsletter #415), editable invoice comments, and several other improvements and bug fixes.

  • ● Eclair 0.14.1 is a maintenance release for this LN node implementation. It now requires Bitcoin Core 31.x, disables an experimental BOLT12 blinded-path fee discount that did not correctly work with multipath payments, and includes several bug fixes and performance improvements. Operators using custom offer-handler plugins should review the release notes.

Notable code and documentation changes

Notable recent changes in Bitcoin Core, Core Lightning, Eclair, LDK, LND, libsecp256k1, Hardware Wallet Interface (HWI), Rust Bitcoin, BTCPay Server, BDK, Bitcoin Improvement Proposals (BIPs), Lightning BOLTs, Lightning BLIPs, Bitcoin Inquisition, and BINANAs.

  • ● Bitcoin Core #34628 replaces independent per-peer transaction relay backlogs with global inbound and outbound backlogs controlled by count and serialized size token buckets. This reduces duplicate storage and sorting across peers, which contributed to a CPU exhaustion problem (see Newsletter #324). Relay credit starts at 420 transaction tokens and 12 MB, replenishing at a rate of 14 transactions and 20 kB/s for the inbound peer backlog. The count balance is capped at 420 tokens, while the size balance can accumulate up to 50 MB. The outbound refill rate retains the 2.5-times multiplier described in Newsletter #373. When relay demand exceeds available credit, transactions are prioritized by mining score while respecting dependencies. Selected transactions then enter small, randomized, per-peer queues. New getnetworkinfo fields expose each backlog and its token balances, and the debug-only -txsendrate option allows testing different count rates.

  • ● Bitcoin Core #28463 increases the default maximum number of connections from 125 to 200 and adds the -inboundrelaypercent option (default 50), which sets the maximum percentage of inbound slots that transaction-relaying peers can occupy. With eleven outbound slots by default, 189 slots remain available for inbound connections, of which at most 94 may be occupied by transaction-relaying peers under the default setting. This limit is enforced after a peer announces its relay preference and is rechecked if the peer later enables transaction relay using BIP37 messages. This reserves capacity for low-bandwidth block relay and prepares for the addition of more outbound block-relay-only connections, to improve resistance to eclipse attacks.

  • ● Bitcoin Core #32800 adds explicit BIP141 and policy-adjusted transaction size fields to several RPCs. vsize_bip141 reports the virtual size calculated from the transaction’s weight, while vsize_adjusted reports the greater of that value or the size implied by the transaction’s sigops cost under the configured -bytespersigop policy. The adjusted value is used for mempool policy and block template feerate calculations. getmempoolentry, verbose getrawmempool, testmempoolaccept, and submitpackage now report both fields. The existing vsize field, which was documented as the BIP141 virtual size but actually contained the policy-adjusted value, is retained but marked as deprecated. Additionally, getrawtransaction reports vsize_adjusted when the transaction is in the mempool, while its existing vsize remains the BIP141 value. The verbose output of getorphantxs also adds the explicit vsize_bip141 field.

  • ● Bitcoin Core #34683 adds an automatically generated OpenRPC 1.4.1 description of the RPC interface. The new rpc.discover RPC returns the public interface, while getopenrpcinfo can optionally include hidden commands and arguments. The document is generated at runtime from the RPCHelpMan metadata for all registered RPCs, and describes method parameters, required and default values, result shapes, and other interface details.

  • ● Bitcoin Core #33014 fixes how descriptorprocesspsbt (see Newsletter #253) handles a PSBT whose finalized script fields are populated but contain invalid signatures. Previously, the RPC only checked for the presence of final scripts, marked the PSBT as complete, and returned an internal error when transaction extraction failed. Now, it verifies every input before reporting completion, so a PSBT with an invalid signature returns complete: false without a serialized transaction in the hex field.

  • ● Eclair #3325 accepts BOLT12 invoice onion messages that include a reply_path. A payee can attach a blinded reply path to an invoice so that the payer can return an invoice_error if it considers the invoice invalid. Eclair previously rejected this combination, causing interoperability problems with LDK, which added reply paths to invoices (see Newsletter #321).

  • ● BOLTs #1346 specifies BOLT12 payer proofs, a receipt format that allows a payer to prove they paid an invoice using the payment preimage, the invoicing node’s signature, and a payer signature from invreq_payer_id, while allowing selected invoice fields to be omitted for privacy. The specification assigns the lnp human-readable prefix and adds generation and verification test vectors. Core Lightning experimentally implemented an earlier draft (see Newsletter #405).

  • ● BOLTs #1344 extends the attributable failures protocol to successful payments by adding an optional fulfillment_payload to update_fulfill_htlc, the message that returns the payment preimage and settles an HTLC. Only a padding field is defined, so the PR establishes transport for future success-related data, such as signed keysend receipts, without yet standardizing any application.

  • ● BOLTs #1343 adds the option_onion_messages_only_channels feature bit for nodes that only accept onion messages from channel peers. Nodes that do not advertise this feature should accept onion messages from peers without channels, though they may still rate-limit or drop them. This feature allows senders to avoid relay paths that are known to fail while enabling operators to reduce their exposure to denial-of-service attacks. See Newsletter #409 for an LDK workaround that addresses LND’s behavior of receiving but not forwarding onion messages from non-channel peers.

Want more?

For more discussion about the topics mentioned in this newsletter, join us for the weekly Bitcoin Optech Recap on Riverside.fm at 16:30 UTC on August 4. The discussion is also recorded and will be available from our podcasts page.