Repository navigation
my bitcoin lightning channel and wallet got cleaned out #1608
|
I created a lightning wallet on my Umbrel Home running UmbrelOS 1.7.3 using lightning node version LND 0.20.1-beta and and RTL version 0.15.8-beta. On my smart phone I connect to it using Bitbanana version 1.0.1 build 79. Bitbanana connects using onion and a macaroon and tor. The Umbrel is not connected directly to the Internet -- it is behind a NAT router. Only two ports are open to the Umbrel -- port 8333 for the bitcoin node and and another port via Fulcrum for my mempool instance. I have the umbrel set up so that to log in, I am required to do two-factor authentication (TOTP). I have RTL likewise set up so that to log in, I am required to do two-factor authentication (TOTP). On March 18, 2026 I put some bitcoin blockchain money into the lightning wallet and opened a channel. On June 4, 2026 somebody (not me) closed the channel, and 23 minutes later, transferred the bitcoin on the blockchain to somewhere else. Fortunately the amount of money lost is modest -- a few hundred dollars' worth. But it smarts. I would like to figure out what I did wrong in all of this. I hope that colleagues will help me figure out what I did wrong. |
Replies: 6 comments 1 reply
Between these two events did you make any payments through your lightning channel? Also, if possible please share your channel ID or channel opening transaction or channel closing transaction, so that we can observe the onchain events via block explorers. |
|
On 6/7/2026 1:17 PM, Suheb wrote:
On March 18, 2026 I put some bitcoin blockchain money into the
lightning wallet and opened a channel.
On June 4, 2026 somebody (not me) closed the channel, and 23
minutes later, transferred the bitcoin on the blockchain to
somewhere else.
Between these two events did you make any payments through your
lightning channel?
Yes, at least one payment. Maybe two. I can provide details of this
if it would help.
Also, if possible please share your channel ID or channel opening
transaction or channel closing transaction, so that we can observe the
onchain events via block explorers.
I am glad to try to share. I hope I correctly obtained some of the
pieces of information that you have asked for.
Channel ID is 1034864742115639296. Node ID 0364d01e096121b1c119.
Channel opening transaction is
d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7 .
The channel closing transaction is
a235b2b2289a4dae509afdb1f05461779c6dca218e63171a8c73aabb73139852 .
… Message ID:
***@***.***>
|
Don't think that's your closing transaction. I believe it's this one: And from the transaction details, we can surmise that
|
|
On 6/7/2026 5:03 PM, Suheb wrote:
Don't think that's your closing transaction. I believe it's this one:
https://mempool.space/tx/7162033aae4595788b5c54856e44f60f856dee682f4fb23a0438fee97e369492
Yes you are correct.
And from the transaction details, we can surmise that
1. It's a cooperative channel closure (may have been initiated by
your remote peer).
As you can see from this link
<https://1ml.com/node/0364d01e096121b1c119c68c56c17bc90e130fffff99808a3fb8e7545549e15072>,
the remote peer was nicehash-ln1 which is a sort of ordinary high-volume
channel operator. I cannot think of any reason why they would have
closed the channel.
But okay suppose you are right that the channel peer closed the
channel. If you are right about that, then the money would have ended
up in my local hot wallet inside my LND lightning node, right?
1. Two outputs have been created: One of which should show up in your
wallet (depending on what your local balance was when the channel
was closed)
2. So ideally the amount in your wallet should roughly be: Original
amount - mining fee for channel opening txn - amount spent on
lightning transactions
image.png (view on web)
<https://github.com/user-attachments/assets/afa92a7c-f426-4bca-8ec1-32ea11fd4271>
Yes you are absolutely right about what would have been ideal. What
would have been ideal is that right now as I look at your email message,
I would see that there is some nonzero amount of bitcoin in the hot
wallet that is inside my LND lightning node.
But it's not what happened. /*The amount in my wallet is zero. */
/*I invite you to reread my original posting.*/ The channel got closed,
and 23 minutes later, the entirety of my hot wallet inside my LND
lightning node got transferred somewhere else.
So now we return to what you suggest. You are suggesting that the the
channel peer closed the channel. But if the way the channel got closed
is that the channel peer closed the channel, then how do you explain
that 23 minutes later the entirety of my hot wallet got transferred
elsewhere?
This was all in the middle of the night when I was asleep.
I put it to you that this might mean that some bad person somehow
brute-forced their way into my RTL. I suppose they eavesdropped on the
onion traffic? Saw the macaroon? Gained control of my RTL? asked it
to close the lightning channel, then 23 minutes later (when the "channel
close" actually finished), instructed my hot wallet to transfer its
entire balance to someplace else.
… Message ID:
***@***.***>
|
|
On 6/7/2026 5:42 PM, Carl Oppedahl wrote:
On 6/7/2026 5:03 PM, Suheb wrote:
>
> Don't think that's your closing transaction. I believe it's this one:
> https://mempool.space/tx/7162033aae4595788b5c54856e44f60f856dee682f4fb23a0438fee97e369492
>
Yes you are correct.
>
> And from the transaction details, we can surmise that
>
> 1. It's a cooperative channel closure (may have been initiated by
> your remote peer).
>
As you can see from this link
<https://1ml.com/node/0364d01e096121b1c119c68c56c17bc90e130fffff99808a3fb8e7545549e15072>,
the remote peer was nicehash-ln1 which is a sort of ordinary
high-volume channel operator. I cannot think of any reason why they
would have closed the channel.
But okay suppose you are right that the channel peer closed the
channel. If you are right about that, then the money would have ended
up in my local hot wallet inside my LND lightning node, right?
> 1. Two outputs have been created: One of which should show up in
> your wallet (depending on what your local balance was when the
> channel was closed)
> 2. So ideally the amount in your wallet should roughly be: Original
> amount - mining fee for channel opening txn - amount spent on
> lightning transactions
>
> image.png (view on web)
> <https://github.com/user-attachments/assets/afa92a7c-f426-4bca-8ec1-32ea11fd4271>
Yes you are absolutely right about what would have been ideal. What
would have been ideal is that right now as I look at your email
message, I would see that there is some nonzero amount of bitcoin
in the hot wallet that is inside my LND lightning node.
But it's not what happened. /*The amount in my wallet is zero. */
/*I invite you to reread my original posting.*/ The channel got
closed, and 23 minutes later, the entirety of my hot wallet inside my
LND lightning node got transferred somewhere else.
So now we return to what you suggest. You are suggesting that the the
channel peer closed the channel. But if the way the channel got
closed is that the channel peer closed the channel, then how do you
explain that 23 minutes later the entirety of my hot wallet got
transferred elsewhere?
This was all in the middle of the night when I was asleep.
I put it to you that this might mean that some bad person somehow
brute-forced their way into my RTL. I suppose they eavesdropped on
the onion traffic? Saw the macaroon? Gained control of my RTL?
asked it to close the lightning channel, then 23 minutes later (when
the "channel close" actually finished), instructed my hot wallet to
transfer its entire balance to someplace else.
Okay I have clicked around in my Umbrel and have found what I think is a
log file for the LND lightning node. Here are some excerpts from that
log file.
=========================
2026-06-04 15:51:00.417 [WRN] RPCS: Expected either 'sat_per_vbyte' or
'conf_target' to be set, using default conf of 6 instead
2026-06-04 15:51:00.420 [INF] PEER:
Peer(037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba):
*Local close channel request is going to be delivered to the peer*
2026-06-04 15:51:00.425 [INF] PEER:
Peer(037659a0ac8eb3b8d0a720114efc861d3a940382dcfa1403746b4f8f6b2e8810ba):
Delivery addr for channel close:
bc1psppa5vaf8d85cksh0wkntg2qjwez3gxv8dchdp2jx3rln02kaprsq309eg
2026-06-04 15:51:00.427 [INF] CHCL:
ChannelPoint(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0):
initiating shutdown
2026-06-04 15:51:00.427 [INF] NANN: Announcing
channel(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0)
disabled [requested]
2026-06-04 15:51:00.430 [INF] CHCL:
ChannelPoint(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0):
sending shutdown message
2026-06-04 15:51:00.691 [INF] CHCL:
ChannelPoint(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0):
shutdown response received, entering fee negotiation
2026-06-04 15:51:00.692 [INF] CHCL: Ideal fee for closure of
ChannelPoint(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0)
is: 230 sat (max_fee=690 sat)
2026-06-04 15:51:00.692 [INF] HSWC:
ChannelLink(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0):
stopping
2026-06-04 15:51:00.694 [INF] CHCL:
ChannelPoint(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0):
proposing fee of 230 sat to close chan
2026-06-04 15:51:00.694 [INF] HSWC:
ChannelLink(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0):
exited
2026-06-04 15:51:00.694 [INF] HSWC: Removing channel link with
ChannelID(c77f820dfee78607955740c13314e9c8d2fc42a92a0f38cb0c285da91831d9d5)
2026-06-04 15:51:00.937 [INF] CHCL:
ChannelPoint(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0)
fee of 0.00000230 BTC accepted, ending negotiation
2026-06-04 15:51:00.943 [INF] CHCL: Broadcasting cooperative close tx:
(*wire.MsgTx)(0xc00d0adb40)({
Version: (int32) 2,
===================
See what I marked in bold. I think this means the channel close was
requested at our end. Not by the peer.
==========================
2026-06-04 16:02:14.678 [INF] RPCS: [closechannel] close completed:
txid(*7162033aae4595788b5c54856e44f60f856dee682f4fb23a0438fee97e369492*)
2026-06-04 16:02:14.679 [INF] CNCT:
ChannelArbitrator(d5d93118a95d280ccb380f2aa942fcd2c8e91433c14057950786e7fe0d827fc7:0)
marking channel cooperatively closed at height 952363
===========================
I think this shows the result of the channel close. It shows your
transaction ID that starts with 7162, right? Note the time stamp for
the channel close which is 2026-06-04 16:02:14.678.
==========================
2026-06-04 16:03:46.976 [INF] RPCS: [sendcoins]
addr=bc1qgweedzg37umuh4j76tt477uxut0hn8guu0cquh, amt=0 BTC, sat/kw=1000,
min_confs=1, send_all=true, select_outpoints=0
2026-06-04 16:03:46.985 [INF] BTWL: Inserting unconfirmed transaction
a235b2b2289a4dae509afdb1f05461779c6dca218e63171a8c73aabb73139852
2026-06-04 16:03:46.987 [WRN] BTWL: Transaction
a235b2b2289a4dae509afdb1f05461779c6dca218e63171a8c73aabb73139852 not
accepted by mempool: txn-already-in-mempool
2026-06-04 16:03:46.991 [INF] RPCS: [sendcoins] spend generated txid:
a235b2b2289a4dae509afdb1f05461779c6dca218e63171a8c73aabb73139852
2026-06-04 16:03:46.991 [INF] NTFN: New confirmation subscription:
conf_id=3,
txid=a235b2b2289a4dae509afdb1f05461779c6dca218e63171a8c73aabb73139852,
num_confs=6 height_hint=952363
================
And now what you see is that somebody local sent the contents of the LND
hot wallet to somewhere else, on the blockchain.
…> Message ID:
> ***@***.***>
>
|
|
Thanks for the detailed logs, @carl-mempool - It's helpful in making a few things pretty clear. It appears to me that this was unauthorized access to your node's admin RPC, not a peer action or an RTL bug. The key line in your logs is: The decisive part: ~90 seconds after the close, your logs show a One more thing worth highlighting about how the sweep might have happened: in RTL, sending the full balance ( This wasn't something that could happen without an attacker holding admin-level access. From your description it appears that you have a pretty locked down access to your device. I am not in a position to comment on how your macaroon or device access has been compromised. One thing worth clearing up though: a macaroon can't be intercepted over Tor/onion. That traffic is end-to-end encrypted (and LND adds TLS on top), so passive eavesdropping isn't a viable route. The realistic exposure for a macaroon is at the endpoints, not the wire. Regardless of the exact vector, I'd treat this node as fully compromised and act accordingly. Don't add any more funds to this device and don't reuse the seed. |
|
Thank you.
…On 6/7/2026 10:50 PM, Suheb wrote:
Thanks for the detailed logs, @carl-mempool
<https://github.com/carl-mempool> - It's helpful in making a few
things pretty clear.
It appears to me that this was unauthorized access to your node's
admin RPC, not a peer action or an RTL bug.
The key line in your logs is: |Local close channel request is going to
be delivered to the peer|.
That string only appears when the close is initiated from your own
node via the CloseChannel RPC. A peer-initiated cooperative close logs
differently.
The decisive part: ~90 seconds after the close, your logs show a
|sendcoins| call with |send_all=true| sweeping the entire on-chain
balance to |bc1qgweedzg37umuh4j76tt477uxut0hn8guu0cquh|. Two
privileged calls in sequence — |CloseChannel| → |sendcoins| — is the
signature of someone holding a working admin macaroon with reachable
access to your LND RPC/REST. There's no software path where a peer or
a normal channel event produces a sendcoins.
*One more thing worth highlighting about how the sweep might have
happened*: in RTL, sending the full balance (|send_all=true|) through
the UI requires you to re-enter your RTL password before the
transaction is broadcast. Which leads me to believe that *the sweep
bypassed RTL entirely* and was issued directly against LND's RPC/REST
using probably a leaked |admin.macaroon| — in which case RTL's
password prompt was never in the path.
This wasn't something that could happen without an attacker holding
admin-level access. From your description it appears that you have a
pretty locked down access to your device, I am not in a position to
comment on how your macaroon or device access has been compromised.
One thing worth clearing up though: a macaroon *can't be intercepted
over Tor/onion*. That traffic is end-to-end encrypted (and LND adds
TLS on top), so passive eavesdropping isn't a viable route. The
realistic exposure for a macaroon is at the *endpoints*, not the wire.
Regardless of the exact vector, I'd treat this node as fully
compromised and act accordingly. Don't add any more funds to this
device and don't reuse the seed.
—
Reply to this email directly, view it on GitHub
<#1608?email_source=notifications&email_token=B4BCAZQHK3DHGBAFNCDBXLT46ZAY5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSGE2TEMZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSWGM33PORSXEX3DNRUWG2Y#discussioncomment-17215235>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/B4BCAZWFF7KCNK6PJJPTOYT46ZAY5AVCNFSM6AAAAACZ5YIVWSVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTOMRRGUZDGNI>.
Triage notifications, keep track of coding agent tasks and review pull
requests on the go with GitHub Mobile for iOS
<https://github.com/notifications/mobile/ios/B4BCAZVJJ7TXEZRCRV47FKL46ZAY5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSGE2TEMZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSVGM33PORSXEX3JN5ZQ>
and Android
<https://github.com/notifications/mobile/android/B4BCAZUEQENC4YGCLGHHAZ346ZAY5A5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZSGE2TEMZVUZZGKYLTN5XKO3LFNZ2GS33OUVSXMZLOOSXGM33PORSXEX3BNZSHE33JMQ>.
Download it today!
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Thanks for the detailed logs, @carl-mempool - It's helpful in making a few things pretty clear.
It appears to me that this was unauthorized access to your node's admin RPC, not a peer action or an RTL bug.
The key line in your logs is:
Local close channel request is going to be delivered to the peer.That string only appears when the close is initiated from your own node via the CloseChannel RPC. A peer-initiated cooperative close logs differently.
The decisive part: ~90 seconds after the close, your logs show a
sendcoinscall withsend_all=truesweeping the entire on-chain balance tobc1qgweedzg37umuh4j76tt477uxut0hn8guu0cquh. Two privileged calls in sequence —CloseChannel→sendcoins—…