This tool allows you to steal funds from nodes that attempt to pay an invoice a second time after the first succeeds. Soon we will add the wormhole attack in it so that routing nodes can get more money by shortcuting other routing nodes in the middle. You can safely run this and sit back and watch your node get more sats than it was getting before. There's also a mode that doesn't steal in case you want to see if you could have stolen funds.

This tool allows you to steal funds from nodes that attempt to pay an invoice a second time after the first succeeds.

Paying an invoice a second time has to be a mistake most of the time. If thats the case you made a tool to steal sats from people who make this mistake? What im missing

Conceivably, this could be combined with an invoice replay attack in niche situations where the invoice is being presented by a 3rd party, but either the destination is validated, or the skimmer wants to be discrete.

If you're using an LNURL bridge for example, this would be reason to have a short TTL on your invoices.

Thanks for the comment, but im kinda sad that i barely understood what you are saying but i upvoted anyway

I've done it when I get a payment that takes too long. I test out new lightning wallets all the time, and not all of them are very reliable. So when I try to pay an invoice, it often gets "stuck" for several minutes trying to pay without either failing or succeeding -- just "pending." When that happens I usually switch to a different wallet and try to pay the same invoice with that one. In other words, without making a mistake, I try to pay the same invoice twice. I did not consider that I can lose sats doing this but now I will take that into consideration.

Very cool! Need to add something like this to LNsploit too. If you get any major routing nodes or LSPs to run this in watch mode, I'd be very curious what their results are. I'm not sure how often they'd see the same payment hash again after it was paid.

Also I think PTLCs fix wormhole attacks but haven't heard of it being exploited before so that'll be cool when you add that.

Is there a known solution that removes this attack vector then?

IIRC BOLT12 gets rid of this since invoices are directly requested.

PTLCs also fix this.

Is it fair to interpret this as a hacking tool? I think I initially thought it was to prevent theft, but it looks rather like its enabling theft now that I've given it a second read through?

No hacking involved. Lightning payments are locked to a secret (preimage) so if you know the secret then you can get the funds. This tool allows you to redeem payments by checking your storage to see if your nodes know that secret. A few cases like double payments and wormholes exist that this can be leveraged against to unlock funds that nodes normally don't act on.

Wow wtf.. ok. Kan you explain for idiots like how this works?

ELI5: Carol tells Alice she'll give Alice a picture of a cat, if Alice sends Carol money through Bob. Bob has saved this picture of this cat because Carol showed it to him before, so when Alice pays Bob, Bob shows Alice the picture of a cat (settling the payment) and Bob doesn't have to pass the money along to Carol.

A lightning invoice is a cryptographic hash of a secret (i.e. anyone with the secret knows the hash of the secret, but if you just have the hash you can't determine the secret). A lightning invoice is settled when the payer gets this secret from the payee. In lightning payment route, the hops are like payers chained to together - all waiting to settle the payment with their channel partners (and collect fees) when the payee releases the secret.

If you're an intermediate hop on the route from the payer to the payee and the payee reuses a secret known to you, you can settled funds without routing the payment to the payee, effectively stealing funds.

This tools saves secrets it's seen before, waiting for them to be reused so it can steal funds.

how often are payees reusing secrets?

Probably not very often. Only likely if they have buggy code or something afaik

Is this an example where I'm at risk?

Let's say I try to withdraw from SN, and the max fee I entered is tow low, so eventually I get a message saying failed "timed out finding route", and to "try increasing max fee".

If I increase the max fee and try again with the same invoice, is my second attempt vulnerable to this preimage stealer?

no i don't believe so as the payment never found a route during the probing process.

if i understand correctly this is related to invoice reuse after a prior successful payment

yes the main concern is someone paying an invoice successfully and then someone (maybe same person or other) paying that invoice again from another wallet.

another concern is if a payment looks stuck and making the payment again on another wallet.

if a payment fails and you make the payment again then you are fine.

there's a wormhole attack here too that users dont need to worry about too much it's mostly a router level attack

This is a cool tool

Your sharing is much appreciated

very interesting

Love to see it

Well that’s fun