pull down to refresh

548 sats \ 1 reply \ @optimism 1 Oct \ parent \ on: Potential Core Lightning Attack - 8 Suspicious Closes Today lightning

I review all software I run and sometimes it takes me a couple of days to get through it. That's clearly too long now. I don't really know how to help because you can't ever say that something is safe; only that you didn't find anything. But that doesn't mean its safe. Nothing that is online and reachable is safe.

Having always-online liquidity is hard right now. I was rebuilding my (private channel only) LND and I simply shut it down a few weeks ago because of all the crap going on. No point in risking it right now.

I did spend some time to build up a framework to quickly simulate CLN and LND error scenarios, but it was no use because they took it before the timelock enabled you. I did get to do the sweep with CLN key inputs:

chantools sweepremoteclosed \
  --hsm_secret <hexdump from cln> \
  --peers <nodeid1>,<..nodeidN> \
  --sweepaddr <from bitcoin core getnewaddress> \
  --apiurl <some esplora capable electrs http endpoint>

it'll give you txs that you can then use with bitcoin-cli sendrawtransaction or add --publish and it'll use the esplora pushtx.

I'm sorry this happened to you. I've not much to offer but sympathy, which makes me even more sorry.

write
compose
127 sats \ 0 replies \ @ZezzebbulTheMysterious OP 2 Oct

chantools doesn't have great support for core lightning. I ran sweepremoteclosed but it didnt find anything at all with all the attacker public keys. I also tried it with a legit channel that I am waiting to timeout to claim a force close. It found nothing -- not even that there was a cooldown and could be claimed later.

I notice the attacker has not claimed the remainder of the channel, so I should at least be able to claw the old state balance back. The node has 'dropped' all references to these txs after 100 blocks. What I am seeing in all the attacker force closes is an old state, and my node got confused and was not able to broadcast the justice transactions. The client reported that it did, but the node got confused and dropped the references in listpeerchannels.

I am concerned that there are more attacker transactions that I have missed.

There is one pending local close with a large cooldown (1000 blocks) that I was hoping to try to recover with this tool, but it doesn't look like this will work. I might have to fire up the node in a week to sweep that one.

I might be able to derive something with hsmtool?

Core Lightning appears to be missing some essential tools that allow recovery from the database+hsm when the cheating transaction is sent via a force close.

reply