Bitcoin Optech Newsletter #429 This week’s newsletter describes a protocol for creating silent payment transactions from multiparty wallets, summarizes the responsible disclosure of a denial-of-service vulnerability that affected older versions of Core Lightning, and explains Bitcoin Core’s updated security policy for easily discoverable vulnerabilities. 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. News ● Silent payments for multiparty wallets: Oleksandr Kurbatov posted to Delving Bitcoin to describe a protocol to use multiparty inputs in silent payment transactions. BIP352 does not recommend using that kind of input due to lack of a security proof. The protocol allows a multiparty sender to compute the ECDH share as a weighted sum of the signers’ contributions, while providing an aggregated DLEQ proof, called AggDLEQ, to prove that the ECDH share is correctly derived from the input key. The proposal works with several multiparty protocols, such as FROST and MuSig2. The proposed protocol relies on two rounds. A coordinator provides context, containing signer set, signing protocol coefficients and tweak, key material, the transaction, and a session ID. During the first round, each signer generates two random nonces and sends messages needed for AggDLEQ back to the coordinator, such as the ECDH share computed from their own key fragment and nonce commitments. Those messages are used by the coordinator to compute the combined ECDH share and a challenge. During the second round, each signer produces a contribution to the proof based on the provided challenge. If the responses are correct, the coordinator aggregates all the responses into a single proof compatible with BIP374. Kurbatov stated that the protocol needs no changes to BIP352, BIP374, BIP375, or the MuSig2 and FROST signing protocols, and no new PSBT fields, because the AggDLEQ messages are exchanged only between the signers over the wallet’s coordinator channel. He said a paper with security proofs is under internal review, but noted that its claim that corrupted signers and the coordinator cannot forge a proof or a signature relies on an assumption whose hardness is an open question. ● CLN self-referential channel announcement DoS disclosure: Nishant Bansal posted to Delving Bitcoin disclosing a denial-of-service vulnerability affecting Core Lightning (CLN) versions 25.02 through 26.04. CLN never checked that the two node IDs in a channel announcement differ, so an announcement naming the same node as both endpoints passed validation and was written to the on-disk gossip store before being loaded into the in-memory channel graph. Loading it added the unknown node twice, which tripped a no-duplicates assertion in gossipd and crashed the node. The stored message then crashed the node again on every restart until the operator removed it by hand, which upgrading alone did not do. An attacker only needed to fund a 2-of-2 output it controlled and sign the announcement with those keys and a fresh node key, so the cost was limited to onchain fees. Older CLN releases accept and relay such an announcement without crashing, so they could carry it to vulnerable nodes the attacker could not reach directly. Bansal found the bug with a gossip fuzz target later proposed in Core Lightning #9115. It was responsibly disclosed in April and fixed in CLN 26.04.1 (see Newsletter #398) by Core Lightning #9082, which rejects any announcement whose node_id_1 is not strictly less than node_id_2. BOLTs #1333 added the same receiver requirement to BOLT7, which had only required senders to order the IDs. Operators still on an affected version should upgrade to the latest release. ● Bitcoin Core security policy update: Antoine Poinsot posted to the Bitcoin-Dev mailing list that Bitcoin Core has amended its security policy (see Newsletter #306) for vulnerabilities it classifies as easily discoverable, such as those found with a simple prompt to a large language model. The project has seen an increase in reports of such bugs, which can be rediscovered or inferred from covert fixes. Rather than wait for the next major release and the severity-based embargo the policy otherwise applies, Bitcoin Core now backports a fix to every maintained release, cuts point releases as soon as possible, and publishes an advisory alongside them. The three vulnerabilities described in this week’s notable code section (Bitcoin Core #36665, #36667, and #36669) were disclosed under the new classification. Their fixes were merged after 32.0 had been tagged, so 32.0 was never released and Bitcoin Core 32.1 (described below), along with 31.2, 30.4, and 29.5, ships them instead. 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. ● Why does Bitcoin use both a transaction ID and a witness transaction ID? Pieter Wuille explains that segwit moved signatures and other malleable data into the witness, which the txid excludes, so that presigned chains of unconfirmed transactions keep working. Inputs therefore still reference txids. Blocks additionally commit to wtxids so that a node handed a block with tampered witness data can reject it permanently rather than reprocess every variant a peer offers. BIP339 later extended wtxid use to transaction relay for similar denial-of-service reasons. ● How to sign a MuSig with Bitcoin Core Ava Chow explains that MuSig2 signing takes two rounds, so each wallet must process the PSBT twice. The first pass adds the wallet’s public nonce and the second, run on the combined PSBT once every nonce is present, adds its partial signature, after which finalizepsbt produces the transaction. The asker published an example of creating and spending from a MuSig2 address with Bitcoin Core. ● What changed in Bitcoin P2P protocol version 70017 compared to 70016? Ava Chow explains that BIP434 assigns the new version number because it introduces a new feature message exchanged during the version handshake. The message itself lets peers announce and negotiate optional features for the life of a connection, replacing the historical practice of bumping the protocol version or defining a dedicated message for each new feature (see Newsletter #386). Bitcoin Core implemented the message and the version bump earlier this year (see Newsletter #410), and both ship in Bitcoin Core 32.1, described below. 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. ● Bitcoin Core 32.1 is the latest major release of the network’s predominant full node implementation. Version 32.0 was tagged but never fully released because of last-minute issues. This release includes the three security fixes described below. Other changes include mempool-based fee estimation, PSBTv2 by default, watch-only wallet exports, and faster block validation. Existing transaction and transaction-output-spender indexes remain compatible but must be rebuilt to save disk space. See the release notes for details and upgrade considerations. Versions 29.x and earlier have reached the end of their lifecycle and will no longer receive updates. ● Bitcoin Core 31.2 is a maintenance release of the predominant full-node implementation. It includes the same three security fixes as 32.1. It also excludes the version bits that BIP323 reserves as extra nonce space for miners from the BIP9 unknown soft fork warning (see Newsletter #409), caps the -privatebroadcast queue at 10,000 transactions, and compacts the chainstate database regularly. See the release notes for details. ● Bitcoin Core 30.4 is a maintenance release for a previous major release series. It includes the same three security fixes as 32.1, the BIP323 warning change, and the removal of one DNS seed. See the release notes for details. ● Bitcoin Core 29.5 is a maintenance release for a previous major release series. It includes the same three security fixes as 32.1 and the removal of one DNS seed. See the release notes for details. ● Eclair 0.14.6 is a security release for this LN node implementation. It includes the splicing force-close and on-the-fly funding fee-tracking fixes described below. The project strongly recommends upgrading because malicious peers can exploit some of the fixed issues. ● LND v0.21.5-beta and v0.20.6-beta are maintenance releases of this popular LN node implementation, following the release candidates covered in Newsletter #428. Both include the commitment feerate fixes described below, as well as fixes for excessive memory allocation when parsing TLV records and SQL database deadlocks, and faster startup cleanup on SQL-backed nodes. 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 #36665 fixes a memory-exhaustion vulnerability that allowed a connected peer to crash nodes running on Windows, macOS, or BSD. Although Bitcoin Core pauses reads from a peer when its receive queue grows too large, its select() socket backend continued monitoring exceptional conditions. A peer could send TCP urgent data to trigger further reads and bypass the queue limit. Now, exceptional conditions are only monitored when reads are enabled for that socket. Linux uses a different socket backend and was unaffected. ● Bitcoin Core #36667 adds a timeout that disconnects a peer if the node’s send buffer for that peer exceeds its limit for more than 20 minutes, mitigating unbounded memory growth. Bitcoin Core continues to queue some transaction announcements even after this limit is exceeded. Typically, a ping timeout would eventually disconnect a slow-reading peer. However, peers claiming a protocol version predating BIP31 could avoid this. This would allow a malicious peer to maintain an open connection while queued announcements gradually accumulate. The new timeout applies regardless of the peer’s protocol version. Nodes using the -blocksonly option were much less affected. ● Bitcoin Core #36669 fixes an undo-file overflow that could corrupt data needed to disconnect blocks during a reorg. Since undo data can exceed the size of its corresponding block data, an undo file can exceed 4 GiB and wrap its 32-bit offset, thereby overwriting earlier data. A subsequent reorg could stop the node, requiring reindexing with a fixed version to recover. The fix increases the file offset size to 64 bits. It also uses 64-bit file positioning calls on Windows, where exceeding 2 GiB could stop the node even without a reorg. Exploitation requires mining thousands of specially constructed blocks. For the corruption case, it also requires precisely positioning those blocks within the targeted node’s block files, followed by a reorg. The disclosure deems this impractical. Nodes on 32-bit systems or FAT32 block storage are still affected. ● BIPs #2130 adds draft BIP139, Wallet Metadata Export Format, specifying a JSON format for exporting wallet accounts and their output script descriptors, signer information, labels, transactions, coins, and PSBTs (see Newsletter #399). This format enables the transfer of metadata between wallets and the restoration of information that cannot be recovered by a seed backup alone. The specification prohibits including spending private keys or mnemonic seeds in mainnet exports, so these exports complement a separate key backup. ● Core Lightning #9627 updates xpay to account for BOLT4’s 1,300-byte routing information limit for the payment onion before selecting a payment route. Previously, pathfinding could succeed, but onion construction could fail if the selected path exceeded the limit. This could cause a payment to fail even when a shorter path might have worked. xpay now calculates the available space after accounting for the receiver’s final payload or the invoice’s blinded path, then passes a corresponding hop limit to askrene through a new maxhops parameter on its getroutes RPC. The pathfinding cost calculation in askrene also adds a penalty for each hop to favor shorter routes. ● Eclair #3417 and #3419 improve force-close handling when splice transactions remain unconfirmed (see Newsletter #427). For non-zero-conf channels, Eclair now selects the newest commitment whose funding transaction is confirmed or present in its Bitcoin backend’s mempool, reevaluating that choice as blocks arrive or as splice transactions are published. It also includes unconfirmed funding ancestors in anchor CPFP fee calculations and starts claiming outputs of non-revoked remote commitments for earlier funding states after one confirmation. The new require-confirmed-inputs-for-splicing setting, enabled by default, requires confirmed inputs from the peer when splicing and prevents Eclair from initiating another splice until the previous one confirms. The changes also ensure that a previously published local commitment is recognized if it confirms after Eclair switches to a different commitment. Previously, Eclair could leave its own balance and HTLC outputs unclaimed. ● Eclair #3416 fixes a bug that allowed a peer to repeatedly obtain on-the-fly funding without paying the agreed-upon liquidity advertisement fees. Previously, a peer could reject the proposed payments intended to cover these fees, yet Eclair could still complete the liquidity purchase. Now, Eclair flags underpaid purchases and blocks the peer from making further purchases paid from future payments (from_future_htlc). Settling other parts of a multipath payment does not clear the flag. Flagged peers count toward the existing suspicious-peer limit, which disables this payment method globally once it is reached. Flags are cleared on restart, through operator intervention, or if the funding transaction is aborted before publication. ● LDK #5314 fixes a privacy leak in onion message forwarding that could link an unannounced channel to its onchain funding output. An attacker could derive a candidate short channel ID (SCID) from an output’s blockchain location. By connecting to both suspected channel endpoints and sending an onion message through them back to itself, the attacker could use the SCID to identify the channel between them. Receiving the message would confirm the link between the output and the nodes. LDK now refuses to resolve real SCIDs for unannounced channels when forwarding onion messages. SCID aliases remain usable. This complements the HTLC-forwarding privacy protections covered in Newsletter #426. ● LDK #5412 fixes a denial-of-service bug in its LSPS2 server for just-in-time channels. Previously, a client could submit the same request ID repeatedly while the original request remained pending. Each duplicate increased the service-wide pending-request counter and replaced the stored entry. Reaching the 1,000-request limit caused the LSP to reject requests from other clients, despite having far fewer requests to process. Duplicate IDs are now rejected without increasing the counter or replacing the original request. ● LND #11164 advances its gossip-v2 implementation by updating message formats to match the latest taproot gossip proposal, which would allow nodes to announce and verify taproot channels. Signature-exchange messages now include the funding transaction ID to distinguish funding attempts in preparation for splicing and carry separate MuSig2 partial signatures for the node and funding keys. The changes also correct the encoding of the fee and capacity fields and preserve optional fields containing default values. This preserves the signed bytes when messages are decoded and re-encoded, thus preventing signature verification failures. ● LND #11373 and #11380 enforce L https://bitcoinops.org/en/newsletters/2026/10/30/ #rss #feeds #linksharing #qwibbit

Bitcoin Optech Newsletter #428 Recap Podcast Gustavo Flores Echaiz and Brandon Black are joined by Adam Gibson, Vincenzo Palazzo, and João Dias to discuss Newsletter #428. The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0 Download audio News ● Trust-minimized exits from a single-issuer layer 2 (1:32) ● Descriptor syntax for hash preimages (18:03) Changes to services and client software ● Ibis Wallet v5.0-beta released (26:31) ● Landfall wallet for Lightning mining payouts (28:57) ● rbitcoin 0.8.0 released (38:44) Releases and release candidates ● Eclair 0.14.4 (43:18) ● BDK chain 0.23.4 (45:37) ● LND v0.21.5-beta.rc1 (47:09) Notable code and documentation changes ● Eclair #3409 (50:16) ● Eclair #3411 (52:20) ● LDK #5126 (55:03) ● LND #10919 (56:19) ● BTCPay Server #7679 (1:01:06) ● BTCPay Server #7684 (1:02:39) ● BDK #2325 (1:04:18) ● BOLTs #1357 (1:07:13) ● BOLTs #1352 (1:10:03) Transcription transcription coming soon https://bitcoinops.org/en/podcast/2026/10/27/ #rss #feeds #linksharing #qwibbit

Understanding the COLDCARD Mk5 and Q Security Model COLDCARD Mk5 and Q look very different, but they use the same core security architecture: two secure elements from different vendors, an STM32 microcontroller, locally verified firmware, a clear case, and no required companion app. This is the current version of our original Mk4 security-model explainer, which remains online. The original was written by guest author Tristan Borges Solari. This edition keeps the useful parts and updates the setup, hardware, firmware, and seed-generation details for Mk5 and Q. Before You Set Up a Wallet Inspect the device, set the PIN, then stop at the main menu. Check the current security status, install the current standard firmware, and verify the signed download before you generate or import a seed. Firmware changes the device. It does not change an existing seed. If the security status says a seed requires migration, follow the migration guidance; an upgrade alone is not a migration. Start with What You Can Inspect Each COLDCARD ships in a tamper-evident bag with a unique number. Before setup, check the bag for damage and confirm that the number on the bag, the tear-off tab inside, and the number shown by the COLDCARD all match. The clear case is another deliberate check. You can see the board, the chips, and the exposed traces instead of trusting a sealed black box. Neither a bag nor a clear case is magic. Together they make interception and physical changes harder to hide. If the packaging looks wrong, the numbers do not match, or the board looks altered, stop. Do not enter a PIN or seed. Authenticity Without a Required App Every authenticity system has tradeoffs. A remote attestation service can be convenient, but it also creates another central service and a valuable key for attackers to target. COLDCARD keeps its core checks local: inspect the clear case, match the bag number, verify the signed firmware, and check the GENUINE/CAUTION LEDs. At startup, the bootloader checks the firmware and flash contents. The red CAUTION LED is on while verification runs. The green GENUINE LED turns on after the expected firmware state is confirmed. The LEDs are connected to the secure-element path; ordinary firmware cannot simply draw a green light on the screen and call itself genuine. If the red light remains on, do not enter your PIN. A red light can also appear after a firmware change until the PIN holder reviews and blesses it. Follow the firmware instructions rather than guessing why it changed. This design still has trust boundaries. Coinkite signs standard firmware, and you must obtain the verification key through a channel you trust. The firmware source, signed release manifest, reproducible-build process, and on-device indicator make that boundary inspectable instead of hiding it behind an app. The PIN Is More Than a Lock Screen The main PIN has a prefix and suffix. After the prefix, COLDCARD shows two anti-phishing words derived from secrets unique to that device. Record those words during setup and check them before entering the suffix in the future. A replacement device should not produce the same words for the same prefix. That makes the words a useful warning against an evil-maid or look-alike-device attack. They are a check only if you remember to check them. PIN attempts are rate-limited and finite. Mk5 and Q also support Trick PINs that can open a duress wallet, wipe the seed, start a countdown, or brick the device. These are advanced controls. Test any Trick PIN with a disposable setup before depending on it. Two Secure Elements and One MCU Mk5 and Q use three chips from three vendors in the secret-protection path: SE1: a Microchip ATECC608-family secure element; SE2: a Maxim DS28C36B secure element; and MCU: an STMicroelectronics STM32L4S5 microcontroller. COLDCARD Q and Mk5 share the same dual-secure-element design. SE1 stores the seed material in encrypted form, but SE1 does not hold the full key needed to decrypt it. The decryption path combines secrets held by the MCU and SE2 and requires the correct PIN. Pairing secrets and authenticated communications protect the short electrical links between the chips. The design goal is straightforward: compromising one chip should not be enough to recover the wallet secret. An attacker targeting the stored seed must get through the MCU, both secure elements, and the PIN path rather than depending on one component. The secure elements do not implement Bitcoin transaction signing. Bitcoin operations run on the MCU using the same libsecp256k1 cryptographic library used by Bitcoin Core. The secure elements protect secrets and enforce parts of the access-control path; the public firmware implements the Bitcoin logic. The secure elements remain visible through the Mk5 case. The detailed key relationships, pairing operations, ECDH exchanges, wipe keys, and storage slots are documented in the public dual-secure-element design and security-model document. Current Seed Generation Uses Device and User Entropy Current standard firmware does not ask you to trust one random-number source. For each new seed, COLDCARD combines fresh input from the STM32 hardware TRNG, SE1, and SE2. It then requires one physical user-entropy method: at least 65 key presses with unpredictable timing; at least 50 rolls of a physical six-sided die; or at least 128 physical coin flips. You cannot skip this step. Dice rolls are our recommended standard method. Current firmware can also display the full device-generated input as 24 BIP-39 words before dice or coin input is mixed in. The public verify_seed_mix.py tool can recompute the result offline for dice rolls or coin flips. It does not support key-mashing input. Verification exposes wallet secrets. Anyone who obtains the displayed device words together with your complete dice or coin sequence can recreate the wallet. The safest way to test the math is with a disposable run that will never hold funds, then start over with new device words and fresh, unrecorded rolls or flips for the actual wallet. Read the Master Seed guide for the current workflow and the verification guide before using the advanced checks. The Firmware Is Part of the Security Model COLDCARD firmware is developed in public. You can inspect the source, build it, and compare builds with a signed release. The bootloader verifies firmware before normal use, and the GENUINE/CAUTION system reports the approved flash state locally. That does not make software bug-free. It makes changes reviewable and gives users several independent checks: source, release history, signed hashes, reproducible builds, and the device’s own boot verification. Keep the firmware current. Verify the release manifest and file hash yourself. Do not rely on a version number copied from an old article, video, or social post. Signing Without Handing the Keys to an App The wallet software on your computer or phone prepares a PSBT. COLDCARD parses it and shows the transaction details for review. If you approve it, COLDCARD signs on the device and returns the signed transaction. Mk5 supports MicroSD, NFC, USB-C, and Virtual Disk workflows. Q adds a camera, QR signing, two MicroSD slots, a larger screen, and a full keyboard. Neither model requires a COLDCARD account or a particular companion wallet. The channel is not the final security decision. A MicroSD card, QR code, NFC, or USB link can carry hostile data. The important boundary is that COLDCARD parses the request, shows what it intends to sign, and waits for your approval. Read the screen. Verify destination addresses and amounts before signing. What Still Depends on You No hardware design can fix a bad recovery plan. You still need to: keep the device on current, verified firmware; protect the seed backup from theft and loss; use a strong, unique BIP-39 passphrase for a wallet whose loss would be materially harmful, back it up separately, and test recovery; verify receive addresses and transaction details on the COLDCARD screen; and consider multisig when its extra recovery and operating complexity fits the amount and threat model. The point of the Mk5 and Q security model is not that any one chip, bag, light, or workflow is perfect. The point is that the layers fail differently and can be checked in different ways. Get COLDCARD Q or Mk5 Technical References Current COLDCARD security status Physical security notes Hardware features and GENUINE/CAUTION LEDs Mk4/Mk5/Q security model Dual secure elements Firmware source Firmware verification and upgrade guide COLDCARD Mk5 COLDCARD Q https://blog.coinkite.com/understanding-mk5-q-security-model/ #securitymodel #firmware #pin #borgessolari #tristanborges #genuine #app #walletinspect #rss #feeds #linksharing #qwibbit

Bitcoin Optech Newsletter #428 This week’s newsletter describes a design for a single-issuer layer 2 whose users can redeem their bitcoin onchain without the issuer’s cooperation and summarizes a proposal for including hash preimages in output script descriptors. Also included are our regular sections describing recent changes to services and client software, announcing new releases and release candidates, and describing notable changes to popular Bitcoin infrastructure software. News ● Trust-minimized exits from a single-issuer layer 2: Adam Gibson posted to the Bitcoin-Dev mailing list a paper and proof-of-concept code for Lichen, a design in which a single issuer, which Gibson calls a hub, mints tokens redeemable one-to-one for bitcoin on a layer 2 ledger run by a server called the sequencer. Each user holds a 2-of-2 contract with the hub that lets them redeem their tokens even if the hub refuses or is offline, so users trust the sequencer to run the ledger honestly but not the hub to return their bitcoin. The design builds on LN-GAP (see Newsletter #427) but replaces its honest-majority attestation committee with a dispute settled entirely onchain. Each user locks bitcoin in their own 2-of-2 output with the hub and receives the same amount of tokens on the layer 2 ledger, where users pay each other without touching the chain. To exit, a user hands tokens back to the hub and collects bitcoin from their own output. Because that output is the only one a user can draw on, the hub also locks some of its own bitcoin in each output up to a negotiated cap, like LN inbound liquidity, so that the user can redeem tokens received from others. Tokens received beyond the cap are redeemable only at the hub’s discretion. In the cooperative case, the hub simply signs a settlement of the output paying the user. If it refuses or does not respond, the user generates a Groth16 proof that the sequencer signed a state recording the returned tokens. Since Script cannot verify such a proof, the user instead claims onchain that a fixed verifier program accepts it, and if the hub disputes that, presigned BitVMX transactions narrow the disagreement to a single execution step that Script can check. Each side locks a reserve that it forfeits by losing a dispute, deterring false claims and refusals. Gibson acknowledges that a sequencer that omits a user’s return, or signs a state it never validly reached, can still cost the user or the hub funds, and lists validity proofs and a committee of sequencers as future work. ● Descriptor syntax for hash preimages: João Dias posted to Delving Bitcoin a proposal for extending BIP379 to add a private form for hash fragments to miniscript. As of today, there is no way to directly give a preimage to Bitcoin Core’s wallet to spend funds that need one to satisfy a spending condition. It is only possible to provide it through external tools in one of the PSBT hash fields (e.g. PSBT_IN_SHA256). The author noted that this proposal only covers the preimages already known when a descriptor is created, not those learned at spend time, such as in a HTLC. Dias explained that the preimage should be treated more like a key than a signature, highlighting an inconsistency in the descriptor model. His idea aims to let a wallet import a secret from a descriptor and build and sign a transaction directly. To do so, the author proposed a specific syntax for the descriptor (e.g. sha256(preimage(HEX))) and a set of boundaries, such as the need for a specific marker instead of raw hex, a fixed size of 32 bytes for all the hash fragments, and the requirement to handle the preimage like any other secret, with backups, encryption, and never shown in the public descriptor string. Before proceeding to formalize the proposal, Dias highlighted some open points that need to be addressed, such as what the marker syntax should be , whether to amend BIP379 or draft a new BIP, if it is necessary to add an RPC call for Bitcoin Core to manage preimages, whether hardware signing devices should handle preimage secrets or this should remain software-wallet-only, and if there is any interest in deterministically deriving preimages from key material. Changes to services and client software In this monthly feature, we highlight interesting updates to Bitcoin wallets and services. ● Ibis Wallet v5.0-beta released: Ibis Wallet v5.0-beta (see Newsletter #406) adds Ark support built on Bark, unilateral exits from the Spark statechain, and receiving to silent payment addresses. ● Landfall wallet for Lightning mining payouts: Landfall is a proof-of-concept wallet, showing UX achievable today, that derives from a single seed the payout address, BOLT12 offer, and BIP322 signature that the OCEAN mining pool requires to pay rewards over LN, using a Lexe-hosted node (see Newsletter #419). It is not intended for production use. ● rbitcoin 0.8.0 released: rbitcoin 0.8.0 is a Bitcoin full node written in Rust and built on rust-bitcoin, described as entirely AI-written, for wallet and Lightning backends that replaces the UTXO set with a relational archive, serves Electrum and Esplora-style APIs, and uses BIP324 exclusively. 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. ● Eclair 0.14.4 and 0.14.5 are security releases for this LN node implementation. Version 0.14.4 fixes several issues related to splicing, HTLC settlement, on-the-fly funding, and onion parsing, as described in Newsletter #427. It also rejects API requests with an Origin header to prevent cross-site request forgery using cached HTTP Basic authentication credentials (see Newsletter #423). Browser-based integrations must now use their own backend to call Eclair. Version 0.14.5 fixes the trampoline routing and taproot splicing vulnerabilities described below, and closes an integer-overflow bypass of the onion payload length validation covered in Newsletter #427. The project strongly recommends upgrading. ● BDK chain 0.23.4 is a maintenance release of BDK’s libraries for building Bitcoin wallets. It fixes issues with transaction tracking and full scans that stop before checking all previously revealed addresses. Accompanying updates fix Bitcoin Core RPC synchronization after reorgs and include previously covered Electrum fixes for txid verification, confirmation detection for transactions with an OP_RETURN first output, and confirmation tracking after reorgs. ● LND v0.21.5-beta.rc1 and v0.20.6-beta.rc1 are release candidates for maintenance versions of this popular LN node implementation. Both include the fee-update handling and channel-message limits described in Newsletter #418, along with fixes for commitment feerates, excessive memory allocation when parsing TLV records, and SQL database deadlocks. Version 0.21.5 also includes the auxiliary HTLC signature validation fix for Taproot Assets channels described in Newsletter #427, and fixes wallet synchronization during blockchain reorganizations. 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. ● Eclair #3409 fixes a vulnerability that could allow a malicious payer to steal funds from a node forwarding trampoline payments. Eclair now limits the total CLTV expiry delta of a downstream route to ensure that the outgoing HTLC expires before the incoming HTLC (see Newsletter #423 for a related fix). Previously, when pathfinding failed, Eclair would retry with relaxed limits on route length and expiry, allowing a payer to provide routing hints or blinded paths with excessive expiry deltas. The payer could then reclaim the incoming HTLC onchain after it expired, while the receiver could still claim the outgoing HTLC. Eclair now only relaxes the route-length limit, preserving the required expiry ordering. ● Eclair #3411 fixes a vulnerability that could allow a malicious channel peer to steal funds by making Eclair sign an invalid splice transaction (see Newsletter #427 for related fixes). When splicing simple taproot channels, a peer can only provide the amount and script of an input’s previous output instead of the full transaction. Previously, Eclair trusted these values without verifying them. A peer could lie about either field, causing Eclair to sign a splice transaction that could never confirm because taproot signatures commit to the actual amounts and scripts of the spent inputs. Nevertheless, Eclair would treat the invalid splice as its latest channel funding state. The peer could then publish a previously signed commitment spending the previous funding output and claim an outgoing HTLC using its payment preimage after Eclair’s corresponding incoming HTLC had timed out and been refunded, leaving Eclair unable to collect the forwarded payment. Eclair now verifies the claimed outputs against its Bitcoin backend before signing. ● LDK #5126 fixes a bug where BOLT12 payments using one-hop blinded paths could be rejected because their HTLC expiry was too short. Previously, LDK ignored the path’s cltv_expiry_delta because the introduction node was also the receiver. This overlooked the fact that it includes the receiver’s required final CLTV delta. Consequently, payments only met the receiver’s minimum requirement when LDK’s random CLTV offset was large enough. This caused intermittent payment failures when testing against Core Lightning. LDK now includes the advertised delta when constructing the route and checking its maximum permitted total CLTV delta. ● LND #10919 adds an experimental local reputation system to mitigate channel jamming attacks, based on the proposed HTLC accountability scheme (see Newsletters #377 and #387), which replaces the earlier HTLC endorsement approach. The system scores outgoing channels based on past forwarding activity and the node’s advertised fees, penalizing accountable HTLCs that take too long to resolve. The system is enabled by default and logs whether HTLCs would qualify for protected resources, without affecting forwarding decisions. Reputation resets on restart. ● BTCPay Server #7679 fixes a bug that could lead to duplicate Lightning payouts. Previously, if a payout was initiated and a subsequent payment lookup returned no results, BTCPay Server would cancel the payout and discard its saved payment hash. This occurred even if the payment had succeeded. Consequently, an operator could issue another payout for a payment that had already succeeded. BTCPay Server now retains payouts in progress and their payment hashes for subsequent checks. ● BTCPay Server #7684 fixes a privilege escalation in its Greenfield API key authorization. Previously, an API key restricted to a particular store could exercise server-wide or account-wide permissions despite its limited scope. Additionally, a key authorized to create API keys for other users could also grant permissions broader than its own. BTCPay Server now enforces permission scopes when authorizing requests and prevents API keys from granting permissions they do not possess. Existing unrestricted administrator keys retain their intended capabilities. ● BDK #2325 and #2360 fix two bugs that could cause the wallet to report successful synchronization without retrieving the requested transaction data. The first affects Electrum synchronization of individual outpoints. Previously, BDK ignored all errors encountered when fetching their transactions, including connection failures and timeouts. This could cause a spent output to remain classified as unspent. BDK now ignores Electrum protocol errors on this path while propagating other failures. The second PR fixes sync and full_scan in the Electrum and Esplora clients. Previously, setting Electrum’s batch_size or Esplora’s parallel_requests to zero could silently skip requested scans or transaction fetches while reporting success. Both clients now treat zero as one for these parameters. ● BOLTs #1357 updates BOLT11 to require invoice readers to reject invoices unless they contain exactly one payment hash (p) and one payment secret (s) field. Previously, the specification recommended that payers use the first p field, while some invoice parsers used the last. This discrepancy was exploited against LNP2PBot, whose invoice parser and Lightning node selected different payment hashes. Consequently, the bot treated completed payouts as unpaid, allowing attackers to obtain duplicate payouts (see Newsletter #425). ● BOLTs #1352 corrects several errors in the simple taproot channels specification and test vectors (see Newsletter #404). Errors in taproot output-key derivation and control-block construction could produce invalid spends if implemented as previously specified. The PR also clarifies that HTLC signatures exchanged in commitment_signed use SIGHASH_SINGLE|SIGHASH_ANYONECANPAY: the receiving peer appends 0x83 to the 64-byte signature when constructing the witness. When combining second-level transactions for fee bumping, each HTLC input and its corresponding output must occupy matching indices in the combined transaction. Additional corrections cover anchor spending paths, MuSig2 nonce encoding and derivation, and local and remote commitment test vectors. These changes align the specification with existing LND and Eclair implementations without changing protocol behavior. 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 October 27. The discussion is also recorded and will be available from our podcasts page. https://bitcoinops.org/en/newsletters/2026/10/23/ #rss #feeds #linksharing #qwibbit

Bitcoin Optech Newsletter #427 Recap Podcast Mark “Murch” Erhardt, Gustavo Flores Echaiz, and Mike Schmidt are joined by Erick Cestari and Adam Gibson to discuss Newsletter #427. The Bitcoin Optech Podcast and transcription content is licensed Creative Commons CC BY-SA 2.0 Download audio News ● Disclosure of two DoS vulnerabilities fixed in Eclair v0.14.1 (0:53) ● Offchain contracts in Lightning channels (12:57) Releases and release candidates ● Bitcoin Core 32.0rc4 (43:15) Notable code and documentation changes ● Eclair #3396 (49:25) ● Eclair #3399 (53:23) ● Eclair #3395 (57:23) ● Eclair #3401 (59:09) ● LDK #5080 (1:01:03) ● LDK #5087 (1:02:46) ● LND #11068 (1:05:04) ● Rust Bitcoin #6956 (1:07:44) ● BDK #2319 (1:10:22) Transcription transcription coming soon https://bitcoinops.org/en/podcast/2026/10/20/ #rss #feeds #linksharing #qwibbit

Bitcoin Optech Newsletter #427 This week’s newsletter summarizes the disclosure of two denial-of-service vulnerabilities in older versions of Eclair and describes a proposed scheme for running complex multi-round contracts inside Lightning channels. Also included are our regular sections announcing new releases and release candidates and describing notable changes to popular Bitcoin infrastructure software. News ● Disclosure of two DoS vulnerabilities fixed in Eclair v0.14.1: Erick Cestari posted to Delving Bitcoin the responsible disclosure of two denial-of-service (DoS) vulnerabilities in the channel opening process of Eclair v0.14.0 and earlier. Both were fixed in Eclair #3324 and released in v0.14.1 in July, and users running an older version should upgrade. The first, found by Matt Morehouse with his smite fuzzer, is a race condition in a duplicate temporary_channel_id check. Eclair checked whether the ID was already in use before accepting an open_channel message, but did not record the new channel until a later step, so an attacker sending several identical open_channel messages in quick succession could get two past the check. Eclair then created two channel states for one ID, and the second replaced the first, leaving an unreachable channel state that held about 25 kB of memory until the peer disconnected. Repeating the attack leaked about 1 MB per second until the node ran out of memory or spent all of its CPU on garbage collection. The second, found by Cestari, bypasses Eclair’s limit on the number of pending channels whose funding transaction has not confirmed. The duplicate check only looked at temporary IDs, so an attacker could start opening a channel, then reuse that channel’s final channel_id as the temporary_channel_id of the next open_channel. The limiter counted the reused ID twice and dropped both entries once the new channel received its final ID, so its count never rose above two while the number of pending channels grew without bound. Each pending channel stores a copy of the peer’s init features, and setting a single unknown odd feature bit at a very high position inflated that copy to about 65 kB. In Cestari’s test, one connection with no onchain cost exhausted a node’s 4 GB of memory in about 48 minutes. Because pending channels are written to the database, the node crashed again on every restart until its memory limit was raised or the rows were deleted by hand. Replying to a question, Morehouse noted that mobile wallets that use an Eclair node as their LSP, such as Phoenix, are unaffected because ACINQ patched its nodes months ago. ● Offchain contracts in Lightning channels: Adam Gibson posted to the Bitcoin-Dev mailing list about a proposal for protocol, called LN-GAP, to run complex, multi-round, two-party contracts inside a Lightning channel while settling disputes onchain in a constant number of transactions. In order to showcase the proposal, Gibson implemented a game of chess, which he deems a good example of a game that is difficult to run onchain, in which the winner takes the whole pot. Both a repository and a paper for the proposal are available. Two players, Alice and Bob, agree on a certain set of rules. Each player makes their own moves. In case of a dispute, Alice can enforce the rules onchain. However, Gibson notes that Lightning can enforce rules about a published state, but it cannot do so in case a counterparty stalls or stops responding. To address this issue, Gibson introduces a venue, a committee of members whose role is to attest whether a signed message (a move in a chess game and its signature) was published before a certain deadline or not. The venue only needs to attest the timeliness of the publication, not the content of the message. In case of a dispute, Alice posts a transaction claiming that no event was published by Bob; in turn, Bob can post a second transaction containing a rebuttal (his move and the venue’s attestation); finally, Alice can post a disproof, stating that Bob’s rebuttal doesn’t stand due to the event not being compliant with the rules. In Gibson’s proposal, the venue never holds users’ funds. Moreover, it avoids relying on FROST-style threshold signature in order to make fraud attributable only to malicious members. To do so, attestation is done through per-member “one-bit signatures” checked using OP_CHECKSIGADD. Members are incentivized by fees paid atomically over channels using adaptors. However, the construction relies on an honest-majority assumption. If more than half of the members of the venue collude with one of the parties involved, funds can be stolen. Other than games, possible applications include proof-of-storage contracts, where a provider forfeits a bond for failing to respond to a challenge, and offchain dispute resolution similar to what BitVMX-style zero-knowledge verifiers do onchain. 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. ● Bitcoin Core 32.0rc4 is a release candidate for the next major version of the predominant full node implementation. A testing guide is available. 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. ● Eclair #3396, #3397, and #3400 fix several ways a malicious channel peer could prevent Eclair from enforcing HTLCs onchain during splicing (see Newsletter #423). Previously, a peer could make Eclair sign a splice transaction that could not be published promptly by choosing a distant absolute locktime, adding inputs with relative timelocks, providing nonstandard witnesses, exceeding the standard transaction weight limit, or setting the signed transaction’s feerate too low. The first PR adds checks for these cases. The second makes Eclair retry commitment and penalty transactions that were rejected by a conflicting unconfirmed transaction, as the peer may later replace that transaction through RBF by double-spending one of its other inputs. The retry fix also applies when the channel’s funding transaction is unconfirmed, including zero-conf channels. The third fixes another recovery gap: if an RBF replacement of a splice confirms after Eclair force-closes using a commitment for a sibling attempt, Eclair now recognizes that the funding transaction has changed and broadcasts a commitment transaction that spends the confirmed splice output. Previously, funds could remain locked and HTLCs unenforced. ● Eclair #3399 and #3394 fix two ways on-the-fly funding could leave Eclair paying a downstream peer without collecting the corresponding incoming HTLC (see Newsletter #419). Previously, after Eclair stopped tracking an expired payment, a new payment could reuse its payment hash. If the downstream peer then claimed the original outgoing HTLC onchain, revealing the preimage, Eclair could mistakenly fulfill the newer payment’s incoming HTLCs instead of the original ones, allowing the original incoming HTLCs to time out without paying Eclair. The first PR now checks if a settlement belongs to the currently tracked payment and, if not, it uses the incoming HTLC details retained with the settlement to fulfill the correct HTLCs. The second PR ensures that funded payments are only forwarded over the channel where liquidity was purchased. Previously, Eclair could forward over another channel with the same peer, but would only check the funded channel before failing upstream at expiry, even though the outgoing HTLC on the other channel remained claimable. ● Eclair #3395 fixes a bug where a spender could construct a malformed payment onion packet with a valid HMAC that left an incoming HTLC unresolved. The spender could encode a per-hop payload length larger than the packet’s actual capacity while still providing a valid HMAC. Previously, Eclair did not validate the length before extracting the next HMAC, causing an uncaught exception. The relayer would then resume without failing the HTLC, and the malformed packet could also prevent HTLC cleanup from initializing after a restart. Now, Eclair checks that the per-hop payload, including its HMAC, fits within the packet. If it does not, Eclair returns InvalidOnionVersion, allowing normal failure handling. ● Eclair #3401 fixes a bug that could cause a forwarding node to lose funds after a disconnection. Eclair stores instructions to fulfill or fail HTLCs until the corresponding channel updates are signed, allowing them to be retried after reconnection. Previously, if a duplicate or conflicting instruction was rejected because a fulfillment had already been proposed but not signed, Eclair scheduled the deletion of the original stored instruction. If the channel disconnected before signing, the unsigned update was discarded, leaving no instruction to replay the fulfillment. The incoming HTLC could then time out even though the outgoing HTLC had already been fulfilled. Eclair now retains the original instruction until the settlement is signed. ● LDK #5080 fixes a bug where restarting during cooperative channel close could prevent pending HTLCs from being failed back to their upstream peer. Previously, when LDK restarted, it excluded channels undergoing cooperative close from the lookup used to process HTLCs, even though those channels could still have unresolved payments. Consequently, when a downstream peer failed an HTLC, LDK could mistakenly treat the upstream channel as nonexistent and discard the failure. LDK could also drop incoming HTLCs awaiting onion decoding. This could leave HTLCs unresolved until the upstream peer force-closed the channel at expiry. LDK now includes channels undergoing shutdown when restoring the information needed to resolve existing HTLCs. ● LDK #5087 fixes a potential privacy leak in onion messages sent over blinded paths that use dummy hops (see Newsletter #370). Dummy hops are additional encrypted layers that the recipient processes to obscure its position in the path. Previously, forwarding hops rejected intermediate onion layers containing message-content TLV records, but dummy hops accepted them. A malicious sender could insert these records at different, nonfinal layers and observe whether the final message produced a response, potentially revealing where the actual forwarding ended and the dummy hops began. LDK now rejects message-content records at dummy hops as well. ● LND #11068 fixes a missing check for auxiliary HTLC signatures on experimental taproot overlay channels used for Taproot Assets (see Newsletter #324). In these channels, a Taproot Assets signer (tapd) provides an additional signature entry for each non-dust HTLC alongside the usual Bitcoin signatures. Previously, if a peer sent a commitment containing the required Bitcoin signatures but omitted some or all of the auxiliary HTLC signature entries, the receiving LND node would incorrectly accept it. If the channel is later force-closed, the missing signatures could prevent the affected asset HTLCs from being resolved onchain. LND now verifies that the number of received auxiliary signature entries matches the number of non-dust HTLCs. If they differ, LND rejects the commitment and force-closes the channel. ● Rust Bitcoin #6956 introduces a ScriptCode type for the script data used in legacy and segwit v0 signature hashing, which may differ from the full script being spent. According to BIP143, when a P2WSH script contains OP_CODESEPARATOR, signature hashing excludes everything up to and including the last separator executed before the signature check, while retaining any subsequent separators. Previously, p2wsh_signature_hash accepted a witness script, which could lead callers to hash the complete script and produce an invalid signature. The API now accepts ScriptCode, but callers must still identify the last executed separator and shorten the script themselves. The PR also adds P2wpkhScriptCode, a fixed-size, allocation-free representation of the standard script used to sign P2WPKH inputs. ● BDK #2319 fixes a bug where an Electrum-backed wallet could lose track of a transaction’s confirmation after a reorg if the same transaction was mined again at the same height. BDK could retain the displaced block’s header in its cache and fail to recognize the transaction’s confirmation in the replacement block, incorrectly showing it as unconfirmed. The fix refreshes the header cache with newly fetched block headers during synchronization, including after a one-block reorg. 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 October 20. The discussion is also recorded and will be available from our podcasts page. https://bitcoinops.org/en/newsletters/2026/10/16/ #rss #feeds #linksharing #qwibbit

Technical Deep Dive into the Entropy Issue What Happened, in Simple Terms There was no intentional weak-entropy fallback. It is important to be precise about what happened. Yasmarang was MicroPython’s built-in general-purpose PRNG, introduced upstream in May 2018. It did not become part of COLDCARD’s seed-generation path until the libNgU migration in March 2021. Most language runtimes include a non-cryptographic PRNG for general-purpose tasks. Its presence was not itself unusual. COLDCARD was designed to rely exclusively on its hardware TRNG for seed generation, with no software fallback. Setting MICROPY_HW_ENABLE_RNG=0 was intended to disable the software path. A build and link integration error meant that setting did not have the intended effect, and libNgU’s rng_get() symbol resolved to MicroPython’s default Yasmarang implementation instead. The hardware TRNG did not fail and trigger a weaker fallback at runtime. This was inherited platform behavior activated by a link-time error, not an intentional seed-generation design decision or shortcut. This distinction does not change the risk or migration guidance for affected seeds. The COLDCARD devices themselves were not hacked, remotely accessed, or taken over. A firmware bug in affected releases caused weakened seed generation. Attackers exploited those weak seeds offline by regenerating the corresponding private keys and stealing funds. Updated August 1, 2026 at 2:35 p.m. EDT: Funds controlled by seeds generated on affected firmware are at risk if the seed was created without at least 50 independent, private dice rolls and the funded wallet is not protected by a strong, unique BIP-39 passphrase. Fixed firmware is now available for every affected model and release track, including Edge firmware versions 6.6.0X for Mk4/Mk5 and 6.6.0QX for Q. What You Should Do The passphrase must be strong, unique, secret, and separate from the seed backup. A short, common, patterned, quoted, reused, exposed, or uncertain passphrase does not qualify; treat those funds as at risk. Even when a strong passphrase reduces the immediate exposure, it does not repair an affected seed. Unless the independent dice-entropy exception applies, replace the seed and migrate as soon as practical. If your seed was generated on a Mk2 or Mk3 running firmware 4.0.1 through 4.1.9 without at least 50 independent, private dice rolls: Update the Mk2 or Mk3 to firmware version 4.2.0 or later before generating a replacement seed. Generate a completely new seed on the updated COLDCARD. Record and verify the new backup, wallet fingerprint, and a receive address. Send a small test transaction before moving the remaining funds. Keep the old backup until the migration is complete and confirmed. Follow the dedicated Mk2/Mk3 Security Advisory and migration instructions. Proceed calmly and verify every step. If you added at least 50 fair, independent, private dice rolls when originally creating the seed, read the dice guidance in the advisory before migrating. We do not consider that seed at risk from this RNG issue alone. If your seed was generated on affected Mk4, Mk5, or Q firmware without at least 50 independent, private dice rolls: Upgrade to the fixed firmware for the release track you use before generating any new seed: Standard: version 5.6.0 or later for Mk4/Mk5, or version 1.5.0Q or later for Q Edge: version 6.6.0X or later for Mk4/Mk5, or version 6.6.0QX or later for Q Generate a completely new seed on the updated COLDCARD. The fixed firmware’s device-generated seed is sufficient. Dice rolls are optional and are not required to address this issue. A BIP-39 passphrase is a separate wallet-security choice. Back up the new seed and any passphrase carefully. Store the passphrase separately from the seed words. Power-cycle the COLDCARD and verify the wallet fingerprint and a receive address. Send a small test transaction before moving the remaining funds. Updating the firmware does not repair a seed that was generated by affected firmware. A new seed must be generated and the funds migrated to the new wallet. Standard and Edge are separate release tracks. If you use Edge, install the fixed Edge release for your model. Do not assume an older Edge 6.x release is fixed merely because its version number is higher than the standard release. A passphrase creates a different wallet. Every passphrase—including one containing a typo—produces a valid wallet, so verify the wallet fingerprint before depositing funds. Losing the passphrase means losing access to that wallet. Read the COLDCARD passphrase instructions and dice-roll instructions before using either option. TAPSIGNER, OPENDIME, and SATSCARD are not affected because they use different codebases. Summary A complex and subtle series of bugs prevented the hardware RNG from contributing randomness in certain versions of the firmware. We were unaware of the bug until today. Changes introduced for Mk4 added entropy from SE1 and SE2, which partially reduced the impact on later models but did not restore the intended 128-bit security target. The COLDCARD source code has always been open and publicly available, so we have to assume that someone used AI to review previous versions of our firmware and stumbled upon this issue. A few weeks ago, we used one of the best available AI models to review our code for security issues, and it did not find this bug or anything serious. Both attackers and defenders have the same AI tools, but today it did not help us, and only helped the bad guys. For funded wallets with neither the independent dice entropy nor a strong, unique BIP-39 passphrase described above, the reduced search space is a direct security risk, not a theoretical possibility. Technical Background In 2021, we moved COLDCARD’s elliptic-curve operations to Bitcoin Core’s libsecp256k1, using the same implementation trusted by Bitcoin Core instead of maintaining a separate EC stack. That required adding libNgU, an embedded MicroPython library that exposes libsecp256k1 and other Bitcoin primitives. The cryptographic choice was sound. The integration was not. During that migration, wallet seed generation moved from ckcc.rng_bytes() to ngu.random.bytes(). That path resolved rng_get() to MicroPython’s software fallback instead of COLDCARD’s hardware RNG implementation. The bulk of randomness on the COLDCARD was coming from a PRNG that I didn’t know was actually in the source code base (it is from a submodule, Micropython). At the same time the carefully crafted TRNG code I wrote was being used, but just by chance, and only for less important things. On Mk2 and Mk3, the active PRNG was seeded primarily from device and timing state. Under our current attack assumptions, we estimate the effective search space at about 40 bits. This is a preliminary estimate and may change as analysis continues. During Mk4 development, we also mixed values from the TRNGs in SE1 and SE2 into the PRNG state as a backup to a backup. This additional entropy materially improves the situation for Mk4, Q and Mk5. Under the same current assumptions, we estimate the effective search space at about 72 bits. Although Mk4, Q and Mk5 had additional secure-element entropy mixed into the PRNG state, they continued to draw most subsequent random values from the same MicroPython PRNG: micropython/ports/stm32/rng.c That file either builds PRNG code, or uses the STM32 hardware TRNG. Looking quickly at it, you’d think we got the TRNG version of get_rng() but in fact, I explicitly set MICROPY_HW_ENABLE_RNG to zero, thinking we didn’t need either version, but that’s not what it does. Because that code provided a PRNG with the same function signature as the desired code, the build completed without identifying the wrong implementation. The MicroPython fallback was introduced upstream in May 2018. It did not enter COLDCARD wallet seed generation until the libNgU migration in March 2021. The affected Mk2 and Mk3 firmware range is 4.0.1 through 4.1.9. Version 4.2.0 corrects new seed generation. The eight-year figure therefore describes the age of the upstream fallback code, not the duration of affected COLDCARD seed generation. Existing review confirmed that the intended TRNG implementation was present in the firmware binary, but did not verify which rng_get() implementation the wallet seed-generation path actually reached across the two submodules. No changes are needed in the COLDCARD firmware itself, just which code comes along for the ride. Why Existing Review Did Not Catch It Both RNG implementations had the same function signature, and the intended board-specific TRNG code was present in the binary. Existing review verified that code but did not verify end-to-end symbol resolution and call reachability from wallet seed generation. The relevant preprocessor guard is visible in this section of code: random.c:22-31 The guard used #ifndef, which tests whether MICROPY_HW_ENABLE_RNG is defined, rather than whether its value is nonzero. We defined that macro as zero, so the #error did not stop the build. The hotfix now explicitly excludes MicroPython’s fallback PRNG object and adds a build-time RNG symbol check. The build fails unless the board-specific object defines the global rng_get() symbol and the upstream fallback object defines no symbols. Next Steps We have released emergency hotfixes for every affected model and release track: Version 4.2.0 for Mk2 and Mk3 Standard version 5.6.0 for Mk4 and Mk5 Standard version 1.5.0Q for Q Edge version 6.6.0X for Mk4 and Mk5, and Edge version 6.6.0QX for Q These hotfixes correct entropy generation. Updating does not repair seeds that were generated by earlier affected firmware; those seeds must still be replaced unless the independent dice-entropy exception applies. At this point, many researchers and competitors have studied this bug and published their own analysis: LLFOURN: Attack-cost model for affected COLDCARD generations Block: Predictable RNG Fallback and 32-Bit Reseed in COLDCARD Firmware Download the latest firmware https://blog.coinkite.com/entropy-technical-backgrounder/

Update, Sunday. The last three days have been some of the hardest in this company’s history, and for a lot of the people reading this, they’ve been something much worse. Money that took years to save, gone. Trust that took years to build, broken. That impact is real, and for some, the damage is permanent. Some are asking hard questions about our company. We are, too. Our work won’t stop in the weeks ahead. It is just beginning. Since Friday, our team has been reaching out and working directly with customers, helping move funds that were still safe to move, walking through recovery options together, and staying reachable for anyone who wrote in not knowing where they stood. We acknowledge that others in the community did the same, selflessly, and without compensation. We thank them sincerely. We’ve also been in direct contact with the wider hardware wallet and self-custody community, including other builders, researchers, and people who’ve thought hard about this kind of failure. All have graciously offered whatever resources they could spare. We are still engaged in this outreach and are committing to work with the broader industry going forward. If you have an affected device, please do not dispose of it. It may become essential if funds are recovered. Our legal team will coordinate as warranted with law enforcement across multiple jurisdictions to support efforts in identifying those responsible. We destroyed our remaining COLDCARD inventory manufactured with the vulnerable firmware, and shipment was halted when the vulnerability was confirmed. SATSCARD, OPENDIME, and TAPSIGNER are not affected by this issue. Our patched firmware prevents this issue from affecting any new seed generated going forward. It does not repair or restore security to a seed that was already generated on vulnerable firmware. A new seed must be created, and funds moved to it to be secure. If you need a device sooner than we can provide one, or want an alternative while you decide next steps, Bitkey, Ledger, Trezor, Jade, and BitBox are reputable options. For collaborative custody, AnchorWatch, Casa, Unchained, Nunchuk, and Liana are worthy of consideration. We continue to read everything—the replies, the texts, the emails. Some of it we owe direct answers to. We’ll follow up on that specifically and soon. There are real lessons here for us as a company. We owe the community better, and we’re beginning to understand the many ways in which our best efforts and designs could have allowed for this to happen. We’ll show that in our technical postmortem, as soon as it is possible to do so. For now, please continue to refer to the COLDCARD Security Advisory for the best available information. Please continue to reach out to friends, family, and loved ones who may be affected. Time is of the essence. The threat remains real and ongoing. https://blog.coinkite.com/update-sunday/

Adding to the Public Record on Our Ongoing Investigation What Happened, in Simple Terms There was no intentional weak-entropy fallback. It is important to be precise about what happened. Yasmarang was MicroPython’s built-in general-purpose PRNG, introduced upstream in May 2018. It did not become part of COLDCARD’s seed-generation path until the libNgU migration in March 2021. Most language runtimes include a non-cryptographic PRNG for general-purpose tasks. Its presence was not itself unusual. COLDCARD was designed to rely exclusively on its hardware TRNG for seed generation, with no software fallback. Setting MICROPY_HW_ENABLE_RNG=0 was intended to disable the software path. A build and link integration error meant that setting did not have the intended effect, and libNgU’s rng_get() symbol resolved to MicroPython’s default Yasmarang implementation instead. The hardware TRNG did not fail and trigger a weaker fallback at runtime. This was inherited platform behavior activated by a link-time error, not an intentional seed-generation design decision or shortcut. This distinction does not change the risk or migration guidance for affected seeds. The COLDCARD devices themselves were not hacked, remotely accessed, or taken over. A firmware bug in affected releases caused weakened seed generation. Attackers exploited those weak seeds offline by regenerating the corresponding private keys and stealing funds. We understand there is real anger at this moment. Users have suffered real losses, and for those impacted, no public statement is enough. We continue to support affected customers directly and urge others to reach out to any other users they are aware of who may be affected. Urgently: if your seed was generated with our affected firmware, without at least 50 independent, private dice rolls, and your funds aren’t protected by a strong, unique BIP-39 passphrase, move those funds to a new wallet now. We also believe this vulnerability is a warning for every company building Bitcoin hardware and software, not only us—and we’re publishing this now, while the details are still fresh, because other companies need time to check their own code to prevent potential further loss. To support that effort, we’ve published a new resource: coinkite.com/historical-disclosures, a page that records all known public security research, coordinated disclosures, professional reviews, internal findings, and security advisories affecting COLDCARD devices. We’re publishing it because researchers, journalists, and security teams doing their own review need a definitive record to work from. We’ll keep this updated as the investigation continues. Where This Bug Lived As independent researchers have publicly corroborated, this firmware bug appears to have lived at a boundary between two unrelated submodules, not in the parent code, and not in the cryptographic or Bitcoin-specific logic that are the subject of most internal and third-party reviews. Because the flag check looked correct, the bug silently went unnoticed, and its potential impact grew with every release. We believe it’s important for the broader ecosystem to understand how this bug arose, and why it evaded detection, so they can avoid similar consequences. What AI-Assisted Review Did, and Didn’t, Catch We know there are questions about our own use of AI in code review. We’ll cover this fully in our post-mortem, but given the active investigation right now, here’s what we can say immediately. We’ve run AI-assisted review against our critical codebases, including in the weeks before the exploit. It did not catch this vulnerability. Since the incident, we’ve also tested our code against frontier models, including Kimi K3, Claude Fable, and Codex 5.6. None of them caught it. It’s a reason for us, and anyone else relying on AI tools, to be specific about what they currently catch and what they might not. What We’re Asking Other Teams to Do We remain committed to sharing what we learn as our own review process continues. If your team relies on AI review of security-critical code, we recommend you test it specifically against build and submodule boundaries. As a result of these new and powerful AI models, we believe many Bitcoin projects, including those that rely on open-source code, require immediate review. We’re addressing what we can, we’re supporting the people directly affected, and publishing everything we know. https://blog.coinkite.com/adding-to-public-record/

Update on Customer Data Retention We want to inform our customers of a change to our data-handling practices in connection with the security incident disclosed on July 30, 2026. As many of you know, our standard practice has been to automatically blank customer records after 120 days, retaining only email addresses and country of residence. We have also offered customers the option to request accelerated blanking at any time after delivery. Due to legal obligations arising from the security incident, including the preservation of records that may be relevant to ongoing and anticipated legal proceedings, we have temporarily suspended our automated data-blanking process. This means that customer records that would otherwise have been blanked under our standard schedule will be retained until further notice. However, if you would like us to apply our existing retention policies to your data, we will exempt them from this protocol. Please confirm that you do not want us to preserve your data by using our support form. We understand that this is a departure from our published practices and that our customers value the privacy protections we have committed to. We want to be transparent about why this change has been made. We are required by law to preserve records that may be relevant to legal proceedings. This obligation applies regardless of our internal data-retention policies and overrides our standard deletion schedule. During this period, all retained customer data will be stored securely and access will be restricted to authorized personnel. Retained data will not be used for any purpose other than compliance with legal obligations. We will resume our standard data-blanking practices as soon as we are legally permitted to do so. If you have questions about this change, please use our support form. https://blog.coinkite.com/update-on-customer-data-retention/