Market snapshot · ↗Bitcoin price$77,735Network hashrate936 EH/sDifficulty127.45 T

Pools & payouts

LNbits tells operators to stop servers after attacks: check your mining payout route

Source report: 2026-11-08 · Editorial analysis published: 2026-11-09

The November 8 warning covers LNbits servers, beyond an earlier Paywall-only precaution. A hosted-service pause and promised patches are separate facts.

Original timeline from the November 8 project posts: the Paywall precaution was followed by an all-server stop and a separate hosted shutdown.
Original timeline from the November 8 project posts: the Paywall precaution was followed by an all-server stop and a separate hosted shutdown. ASIC.tools · original explanation · CC BY 4.0

A warning for the wallet service behind a payment

LNbits told all operators to stop their LNbits servers immediately on November 8, citing a wave of attacks and security patches still to be published. The original notice was posted at 13:56:18 UTC. For a miner receiving small Bitcoin payments through a Lightning wallet, the practical question is whether LNbits is part of the receiving service, rather than simply whether the mining machine is still connected to its pool.

Lightning moves bitcoin through payment channels, while LNbits is software for managing wallets, accounts and payment applications on top of funding sources. Those are different layers. The notice does not instruct every Bitcoin miner or every Lightning node to stop. An LNbits issue can nevertheless affect access to an account or the service accepting a payout, so a pool’s successful mining connection and the destination wallet’s availability should be checked separately.

The later instruction was broader than Paywall

At 12:33:40 UTC, LNbits first asked operators with its Paywall extension enabled to disable that extension while a possible bug was investigated. Paywall lets an application require payment to access content. Around 83 minutes later, the project addressed all LNbits server operators. The later message was not limited to people who knew they had enabled Paywall.

That sequence matters when reading a forwarded screenshot or an old support reply. Turning off one extension is not the same action as stopping the server software named in the later warning. The posts do not identify the ultimate attack mechanism or establish that Paywall caused the reported theft. A service operator should follow the project’s applicable current instruction; a wallet user should ask the actual service operator what software and notice apply to the account.

Original flow: miner connection, pool payout record and receiving-service access are separate checks. LNbits is relevant only where actually used.
Original flow: miner connection, pool payout record and receiving-service access are separate checks. LNbits is relevant only where actually used. ASIC.tools · original explanation · CC BY 4.0

One reported loss is not the incident total

Operator Kevin Ravensberg reported that newly created accounts withdrew 2,285,545 satoshis from his LNbits instance before he could stop it. His post gives an attack window from 09:22 to 14:00 UTC on November 8. One satoshi is one hundred-millionth of a bitcoin, so the reported amount equals 0.02285545 BTC. This is an attributed report from one operator, not an audited aggregate across all LNbits installations.

A fiat conversion would add a changing exchange price without explaining the failure, so the amount is kept in its original units. The project’s stop notice does not give a global victim count, total loss or list of affected versions. The important operational distinction is between a balance displayed inside an application and an independently completed payment. An application’s records can help investigate, but they do not replace the receiving account’s settlement evidence.

Hosted shutdown and patch timing are separate

At 17:18:42 UTC, LNbits said it had disabled every instance on its own hosted my.lnbits.com service as a precaution. It expected services to resume within 24 hours. Core contributor Ben Arc separately said patches should be merged and available within 24–48 hours. Both are the authors’ expectations, not evidence that recovery or deployment had already happened.

During this article’s November 9 check, the public GitHub release list still identified 1.6.2, published September 18, as the newest release. That older release is not itself the promised November incident patch. A patch in development, a published version, a version installed by the operator and an application available to customers are four different milestones. Checking one does not establish the others, and the date on a hosting forecast is not a safe-restart confirmation.

Original recovery milestones, without a fixed duration: code, release, operator deployment and customer availability are not equivalent.
Original recovery milestones, without a fixed duration: code, release, operator deployment and customer availability are not equivalent. ASIC.tools · original explanation · CC BY 4.0

Follow the route from pool to receiving account

For a miner, identify the pool’s payout method and the provider serving the destination. An ordinary on-chain Bitcoin address and a Lightning receiving service have different delivery records. If the destination uses LNbits, the relevant details include the service’s own status, the pool’s payment status and the payment reference. This is a reason to check the route actually used, not to assume all mining payouts pass through LNbits.

A pool balance that has not been sent is different from a payment marked as sent, and neither proves that a receiving application is accessible. Avoid repeatedly changing destinations or requesting replacement payments before reconciling the existing attempt with the pool and receiving operator. Keep timestamps and reference identifiers together, in the same time zone. These are ordinary records for explaining a pending payment, not a request to reveal control of a wallet.

LNbits documentation describes transaction tables, CSV export and separate API keys for each wallet. Existing records or an export supplied by the operator can help reconcile an account without treating an application key as a public payment reference. This does not mean restarting an affected server just to inspect it. Use records already available or follow the operator’s safe recovery process, and keep the authority to spend funds separate from the information needed to trace a payment.

Recovery needs an explicit status, not a familiar version number

Operators need the project’s update identifying the relevant fix and the applicable deployment instructions. A familiar older version, an extension toggle or a front-page maintenance banner does not by itself establish that the server has been patched. For customers of a hosted service, the provider is the party that can confirm its installed software and handling of affected accounts. A planned reopening and an actual successful service check should remain separate in the record.

ASIC.tools verified the original posts through public X representations, checked the project’s official account links and read its release history. It did not access any user wallet, test an exploit or establish the global losses. The official support group also warns that administrators do not initiate private support messages. A genuine payout investigation can use public references and verified support channels without handing over a recovery phrase, private key or wallet API credential.

Source: LNbits / original security notices ↗ · Earlier Paywall precaution ↗ · Hosted-instance shutdown notice ↗ · Contributor patch estimate ↗ · One operator’s original loss report ↗ · Official release history ↗ · LNbits product and official account links ↗

Mining calculator ↗

More in this section