I've always thought of preimages as secrets that should only be revealed after payment, but given that a payment needs to be in route to update channel states, I can't easily imagine how it leads to stolen funds.
Anyone know?
5,000 sats paid
pull down to refresh
zaps forwarded to @WeAreAllSatoshi (50%)
21 sats \ 4 replies \ @TonyGiorgio 13 Oct 2023
If you're revealing preimages, it means you are not securing preimages. You are exposing your payers to loss of funds, so by extension you're on the hook for that.
You also lose all ability to provide the user with proof of payment. You have to assume they made the payment to you. Software bugs exist and the funds can be stolen, so how are you going to check if a payment made it to you or not or if they lost funds or not when the payer already has the proof?
reply
21 sats \ 3 replies \ @k00b OP 13 Oct 2023
Would it be correct to say the motivation for the payee not revealing preimages are:
- preserving their proof of payment property
- protecting payers from loss of funds (which the payee becomes liable for)
Are there other reasons that I'm missing or are those the main ones?
reply
5031 sats \ 2 replies \ @TonyGiorgio 13 Oct 2023
There's potentially something there with payers constructing their own route through you with that same preimage, reminds me of this: https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-October/002857.html
Browsing it again, there could also be something there with altering amounts and having it route through you, though I'm not sure if it would result in payee loss of funds. It might be uncharted territory since it's kind of a taboo thing to do.
reply
0 sats \ 1 reply \ @k00b OP 13 Oct 2023
That's mostly what I was I looking for. Some confirmation that as a rule it shouldn't be done even if there may be exceptions.
I know preimages better now yay!
reply
0 sats \ 0 replies \ @WeAreAllSatoshi fwd 13 Oct 2023
Cool, great read. I’ll update the PR to only reveal the preimage once the invoice has been confirmed paid
reply
0 sats \ 2 replies \ @WeAreAllSatoshi fwd 13 Oct 2023
Just to be clear, we are talking about revealing the pre image to the payee, right? Not the payer? At least, in the context of the PR where this originated
reply
21 sats \ 1 reply \ @k00b OP 13 Oct 2023
The payee is ultimately SN given that we're custodial. Rather than imagining someone sending your account money, imagine someone malicious funding their account and looking for a way to steal money.
reply
100 sats \ 0 replies \ @WeAreAllSatoshi fwd 13 Oct 2023
Got it, thank you for the analogy!
reply
0 sats \ 3 replies \ @WeAreAllSatoshi fwd 12 Oct 2023
I found this: https://bitcoin.stackexchange.com/a/117139 but I'm not sure if it really answers it or not.
reply
0 sats \ 2 replies \ @k00b OP 12 Oct 2023
This seems to imply that it isn't the payee who can lose funds - only the payer.
If we assume we have this payment route: Alice -> Bob -> Carol. Carol generates an invoice and reveals the preimage before Alice has sent the payment. If Bob somehow learns the preimage and Alice pays Carol through Bob, Bob can claim Alice's funds without passing along the payment to Carol. Carol will assume Alice never paid.
It seems like there's no risk to Carol and there's no harm in telling Alice the preimage ahead of time, but it is important Bob does not see it ahead of time.
reply
10 sats \ 1 reply \ @WeAreAllSatoshi fwd 12 Oct 2023
Right, basically the payment can be intercepted before the intended recipient gets it. So the payer would need to pay another invoice once the payee asserts they didn’t receive the funds from the original invoice
reply
21 sats \ 0 replies \ @k00b OP 12 Oct 2023
I recall this happening to Saifedean in Austin when he was selling books reusing a printed out bolt11 invoice. People were paying him but he didn't end up receiving the money iirc.
reply