Bitcoin Thursday — Hot Wallet Drains and a New LND Release
LND maintenance updates, confirmed hot-wallet thefts, home-node connectivity research and ongoing Bitcoin consensus discussions.
Welcome back to Bitcoin Thursday (one day later on a Friday), my weekly overview of important developments around Bitcoin, node software, the Lightning Network and security.
This edition primarily covers information published or confirmed since November 5. One important BTCPay Server incident from November 2 is included as a clearly marked late addition because it was not covered in the previous edition.
TL;DR
- LND 0.21.8 and 0.20.8 were released on November 11 with numerous correctness and recovery fixes.
- The current LND releases include the earlier mitigation for a remotely exploitable Linux kernel vulnerability involving Multipath TCP.
- BTCPay Server confirmed that attackers stole bitcoin and litecoin from hot wallets on outdated servers.
- Developers are exploring TCP hole punching to make more home Bitcoin nodes reachable, but the security trade-offs remain disputed.
- BIP54, the proposed Bitcoin consensus cleanup, remains under review and has no mainnet activation.
- A draft standard could make covenant-like co-signer policies more interoperable.
- Several Bitcoin Core fixes improve PSBT compatibility, disk-error handling and wallet exports.
1. LND 0.21.8 and 0.20.8 improve channel and fund recovery
Status: Confirmed releases — November 11, 2026
Lightning Labs has released LND 0.21.8-beta and LND 0.20.8-beta.
Despite the word “beta” in LND’s version scheme, these are published maintenance releases rather than release candidates. Neither version requires a database migration.
The 0.21.8 release fixes correctness problems across:
- Wire-message decoding
- Watchtower policy
- Sweeper fees and retries
- Channel-state persistence
- Gossip validation
- Channel negotiation
- Cooperative closing
- Forwarded HTLC recovery
- AMP and keysend on-chain recovery
One fix preserves pending channel information if broadcasting a batch-funding transaction returns an error. A transaction may have reached the network even when the publishing call reports an error. Previously, LND could abandon the pending channels and release their input leases prematurely.
LND now continues watching for the funding transaction and can recover the channels if it confirms.
Another correction ensures that forwarded HTLCs are recovered across link reconnections. LND also sends channel_reestablish when reconnecting while a channel’s funding transaction is still unconfirmed. Previously, a waiting peer could disconnect and unintentionally take every other channel between the two nodes offline.
The update additionally fixes a peer deadlock and improves fee-bumping behavior during force closes.
A versioning note from the developers says that the v0.21.7-beta tag and Docker image contain the same release build and are safe to use. Version 0.21.8 corrects the release metadata and notes.
Contributors listed for 0.21.8 include Boris Nagaev, Olaoluwa Osuntokun, Vincenzo Palazzo, Yong Yu and Ziggie.
Why it matters: These are not flashy new features, but they affect situations in which channels, HTLCs or on-chain recovery transactions are already under stress. Reliable recovery behavior matters most when something has gone wrong.
Operators using a managed platform such as Umbrel or Start9 should wait for the platform’s tested package rather than replacing its bundled LND binary manually.
Sources: Official LND 0.21.8 release notes · LND 0.20.8 release
2. LND mitigates a remotely exploitable Linux kernel vulnerability
Status: Confirmed vulnerability and mitigation
The recent LND maintenance chain also includes a mitigation for CVE-2026-98432, a use-after-free vulnerability in the Linux kernel’s IPv4 TCP stack.
The demonstrated remote exploit requires a Multipath TCP, or MPTCP, listener. Go 1.24 and newer enable MPTCP listeners by default on supported Linux systems, potentially exposing LND even when an operator never deliberately enabled MPTCP.
LND now disables MPTCP listeners by default.
However, this is only a mitigation for the demonstrated route through LND. It does not fix the vulnerable Linux kernel or protect other applications that may expose MPTCP listeners.
Linux node operators should:
- Install the latest supported LND release.
- Install a patched kernel supplied by their Linux distribution.
- Consider disabling MPTCP at the operating-system level until the kernel is patched.
Operators who temporarily remain on an older LND binary can disable Go’s MPTCP listener by starting it with:
GODEBUG=multipathtcp=0
Windows and macOS are not affected by this Linux kernel vulnerability.
Why it matters: A Lightning update can close LND’s demonstrated exposure, but only a kernel update fixes the underlying operating-system flaw. Node security does not stop at the Bitcoin or Lightning application.
Sources: LND 0.21.6 security release · Bitcoin Optech Newsletter #430 · LND pull request #11456
3. BTCPay confirms hot-wallet thefts from outdated servers
Status: Confirmed incident — advisory published November 2, 2026
This report was published before the previous edition but was not included there. Because it involves confirmed theft of bitcoin from self-hosted infrastructure, it is important enough to add now.
On November 1, BTCPay Server received reports of bitcoin and litecoin being stolen from hot wallets. Its investigation found that the affected servers were running BTCPay Server 2.4.1 or earlier.
According to the project, attackers used a different method to exploit the same vulnerability fixed in version 2.4.2 on August 7.
BTCPay reports no impact from this attack on servers that were already running version 2.4.2 or newer when the November 1 warning was issued.
The project advises anyone who operated an affected version to:
- Sweep remaining funds to a newly generated wallet
- Take the old server offline
- Preserve logs and transaction records
- Provision a completely fresh server
- Install the latest supported BTCPay release
- Revoke and replace potentially exposed passwords, API keys, SSH credentials and Lightning credentials
- Avoid restoring the entire compromised machine or reusing its seed
Updating the old server is not considered sufficient because an attacker may already have gained persistent access or copied credentials.
Wallets whose private keys remained on a separate hardware wallet were not drained through this attack. BTCPay continues to recommend receiving payments into wallets whose spending keys are not stored on the server.
The project published destination addresses reported by victims but explicitly warned that their complete transaction histories must not be treated as a confirmed total loss. Some activity at those addresses predates the reported thefts, and the full timeline remains under investigation.
Why it matters: Self-hosting removes dependence on a payment custodian, but it also makes the operator responsible for patching, key separation and incident recovery. Keeping large balances in an internet-connected hot wallet increases the consequences of a server compromise.
Source: BTCPay Server’s official incident report
Self-hosted means you control the server. It does not mean the server maintains itself.
4. Can TCP hole punching make more home Bitcoin nodes reachable?
Status: Experimental proposal and ongoing debate
Developer and researcher 0xB10C has resumed work on a specification and experimental Bitcoin Core implementation for TCP hole punching.
Bitcoin nodes behind ordinary home routers can usually make outbound connections but cannot accept inbound connections without port forwarding, NAT-PMP or a reachable Tor service.
Hole punching attempts to solve this by having two nodes connect to each other at approximately the same moment. Each router interprets the corresponding traffic as a response to an outgoing connection and allows it through.
0xB10C proposed a coordinator-free design in which nodes announce a punchable address and temporary public key. Two nodes would use a shared secret and recent block data to derive when they should attempt the connection.
The potential benefit is a larger population of reachable home nodes. Today, attacker-controlled servers can be easier to reach than honest home nodes, making it easier for an attacker to compete for outbound connection slots.
The proposal is controversial.
Anthony Towns argued that attackers could advertise thousands of addresses and become an early match for many participating nodes. He questioned whether random inbound connections provide enough benefit to justify making home nodes more directly reachable.
Jonathan Harvey-Buschel favored coordinating through a node’s own Tor service instead.
Why it matters: More reachable home nodes could improve network diversity, but every new inbound-connection mechanism creates additional exposure. This is research and experimental implementation work—not a feature node operators should enable today.
Sources: 0xB10C’s original discussion · Bitcoin Optech Newsletter #430
5. BIP54 consensus cleanup remains under review
Status: Proposed soft fork — no mainnet activation
Discussion continues around BIP54, the proposed Bitcoin consensus cleanup.
BIP54 attempts to remove or constrain several long-known consensus edge cases, including the time-warp bug. Its most debated rule would prohibit transactions whose witness-stripped size is exactly 64 bytes.
A Bitcoin Core implementation is under review, but it activates the proposed rules only on regtest. There is currently no mainnet activation logic.
Antoine Riard described additional review, testing and wallet documentation as necessary before activation should be considered. Speaking only for himself, he suggested that discussion of activation might become realistic during the second half of 2027 if sufficient agreement exists by then.
That date is an individual estimate—not an announced activation schedule.
Pieter Wuille also updated his analysis of BIP54’s timestamp rules, including formally verified calculations describing how they constrain chain length and accumulated work.
Why it matters: BIP54 would change Bitcoin’s consensus rules, but it is still in the review and testing stage. Headlines describing it as an upcoming or scheduled fork would be premature.
Sources: BIP54 specification · Bitcoin Core reference implementation · Bitcoin Optech’s November 6 summary
6. Draft BIP proposes interoperable co-signer spending policies
Status: Draft proposal — no assigned BIP number
Luke Carriere has proposed a standard format for spending policies enforced by co-signers that emulate covenant-like restrictions.
Several existing designs—including blinded co-signers and chain-code delegation—define their policies differently. A wallet built for one system may therefore be unable to use a co-signer or oracle built for another.
The proposal separates each policy into five parts:
- The Taproot descriptor holding the funds
- The co-signer group and signing threshold
- The transaction templates co-signers may approve
- The conditions that must be satisfied
- The verification and accountability profile
The design requires at least one spending path that does not depend on the co-signer. It also proposes compatibility with DLC oracle attestations.
Open questions include serialization, blinded verification, timelocked fallback paths and how precisely implementations must commit to their verifier behavior.
Reviewers PREDGE and tehiyadu identified concerns involving provisional attestations and inconsistent verifier interpretations. Carriere agreed to clarify both areas.
Why it matters: This could make advanced wallet-security and covenant-emulation systems more interoperable. It does not add covenants to Bitcoin and does not change Bitcoin’s consensus rules.
Sources: Luke Carriere’s proposal · Draft specification · Bitcoin Optech Newsletter #430
7. Bitcoin Core development fixes PSBT and disk-error edge cases
Status: Confirmed code changes — not a new Bitcoin Core release
Several recently merged Bitcoin Core changes address practical wallet and node-recovery problems.
Bitcoin Core 32.1 exported some GUI-created unsigned transactions and fee bumps as PSBT version 2. This prevented them from being signed by hardware wallets and other tools supporting only PSBT version 0.
Bitcoin Core PR #36539 restores PSBTv0 for this GUI workflow. The separate external-signer workflow continues to use PSBTv2.
Bitcoin Core PR #35714 fixes an ordering problem after a disk-write failure. Bitcoin Core could update its block index and UTXO database even though the corresponding block or undo data had not been safely written. The node would shut down, but its local databases could be left describing data that did not exist safely on disk.
Bitcoin Core PR #35492 improves bitcoin-wallet dump. The command previously reported success if it could open the destination file, even when a later write, flush or close operation failed—for example because the disk became full. It now detects those failures and removes incomplete dump files.
Why it matters: Backups, hardware-wallet compatibility and recovery from disk failures are not glamorous, but they determine whether node and wallet operators can rely on their tools under real-world conditions.
These merged changes are development updates. They should not be described as a separately released Bitcoin Core version unless and until they appear in official release notes.
Source: Bitcoin Optech Newsletter #430
Confirmed facts versus proposals
The LND releases, BTCPay theft reports and Bitcoin Core code changes are confirmed through official project sources.
TCP hole punching, standardized co-signer policies and the consensus-cleanup soft fork remain proposals or experimental work.
BIP54 has no announced mainnet activation. The suggested 2027 timeframe is one developer’s personal assessment, not a community decision.
BTCPay has confirmed thefts, but it has not confirmed a final total loss. Address balances and third-party estimates should not be presented as the established amount stolen.
This week’s takeaway
The strongest lesson this week is that self-hosting is a continuing responsibility rather than a one-time installation.
A Bitcoin or Lightning server can be non-custodial in design while still exposing hot-wallet keys, API credentials or vulnerable operating-system services. Software updates, kernel patches, offline keys and tested backups are all part of self-custody.
Self-hosted does not mean set-and-forget.
Would you rather keep your node completely private behind Tor, or accept more inbound connections to support the wider Bitcoin network?
Bitcoin Thursday is an independent weekly overview of Bitcoin development and security. It is not financial advice. Always verify releases, signatures and upgrade instructions through the project’s official channels.
There is no order without chaos!
#bitcoin #lightningnetwork #bitcoinnews #selfcustody #technology
[email protected]
Images and screenshots are from me or AI generated