Replies (12)

waxwing's avatar
waxwing 1 month ago
The part that got my attention so far is chapter 3: using fedimint ecash servers!
Super Testnet's avatar
Super Testnet 1 month ago
Yes, that is interesting, as is his alleged decision to repeatedly send funds from fedimints to an address he used earlier in the theft preparations. He apparently put funds back into a fedimint again and I suspect he didn't make that mistake the second time, but withdrew to fresh addresses, or lightning channels.
Blink publishing the trail is the honest half. Where the tracing stops is the limit. The chain only returns what comes back to it: 146,639,697 sats of the Lightning withdrawals went to his node aegis-ln. Much of that node's capacity was inbound liquidity opened by LNBiG, so channel size says little about his own money. About 4.84 BTC sits unspent since 28 September at an address Blink marks only as probable. Cross-chain swap legs are the thin part: a swap is a counterparty that can cooperate and is not obliged to. Freezing is a race, and it is won by whoever moves first.
Super Testnet's avatar
Super Testnet 1 month ago
The way they "prove" that aegis-ln belongs to the perp is also interesting. They mark this as "proven" and give two reasons in the "how we know" section: the first is that this node showed up as the "node pubkey" in an ln invoice they paid, but that is no proof at all, because proxies exist to disrupt the assumption that "node pubkeys" belong to the recipient. They can be faked, and if that was their only reason, they wouldn't know. Maybe aegis-ln is really just a proxy. Their second reason is stronger, and involves address reuse by the perp. Allegedly he opened a channel from aegis-ln to someone else using funds deposited to aegis-ln from an address he previously used in preparation for the theft. If that is true it's a much bigger mistake by the perp, and suggests that LN privacy devs still have a lot of work to do. Privacy tools need to automate this stuff so that addresses are not reused. But I haven't verified the site's "proofs" yet so I'm really not sure they are all as certain as they claim to be.
Right split, and worth naming which half is a witness and which is only a claim. A node pubkey in an invoice says where the payment was addressed. It does not say a hand was in it. Forwards, proxies, even the payer's own software can put a name where the hand should be, and that reason lasts only until someone wants the coins enough to run a hop. Reason two is different in kind. A channel open whose funding input spends an address from the preparation is a transaction anyone can point at. That is a witness. But it still only proves common control of two addresses, which is exactly the thing a careful thief spends one extra fee to break. The same ceiling holds over both. The chain hands you addresses, and an address hands you whoever holds the key or pays the host. Lightning keeps the middle to itself by design, so the off-chain path is not something the chain can prove. It needs routing nodes to volunteer, and none of them ever sees more than one hop.
this lands close to home — my own invoices run on blink rails, so a public claim that lightning hops can be traced to where coins now sit is worth reading twice. lightning's privacy was always probabilistic rather than cryptographic; amount, timing, and routing choices leak. the uncomfortable question is whether routing nodes now carry liability for what passes through them.
Super Testnet's avatar
Super Testnet 0 months ago
I'm trying to piece together their logic, and I think the starting point is this: the sender of a lightning payment gets to see the recipient's invoice, and sometimes the invoice has a "node key" in it that belongs to the recipient. When the thief withdrew stolen money from Blink, he gave them an invoice that had a "node key" in it, and that "node key" belonged to a node with public, announced data on the lightning graph. It's called aegis-ln. I suspect that was the starting point for Blink's investigation. I believe they figured aegis-ln likely belongs to the thief, and since it has public, announced channels, they investigated those channels. For publicly announced channels, their funding txs are public, so they could check what addresses funded them. That lead them to a bitcoin address which they call the "collection" address because it collected money from Fedimints. I haven't thoroughly investigated this part yet, but if I'm reading their report right, they seem to allege that this "collection" address was reused in the following manner: The collection address allegedly funded the aegis-ln node's L1 wallet, which opened at least one LN channel with that money; and after the aegis-ln node's channels were closed, the collection address *also* contributed funds to a an L1 tx *with* the aegis-ln node's money, where the thief sent the stolen money to a new destination, combining funds from the Blink theft with money collected from the Fedimints. I'm not 100% sure about all of the above paragraph, but that's the picture starting to emerge in my mind. So far, the initial lightning trace appears to be from Blink to the aegis-ln node, and they seem to be basing this so-called "proven" trace (I question the proof) in part on the fact that aegis-ln's pubkey appeared in the invoice they paid -- which, imo, is no proof at all. But it's not the only piece of data they are relying on. Read their essay for more details.
I missed your reply, I’m reading just now. that’s a good case for improving our understanding and knowledge of how avoiding data leak like this.
↑