100 sats \ 4 replies \ @benthecarman 15 Dec 2023 \ on: LNbank Vulnerability Recap · d11n 🍯🦡⚡️🕗🔗 bitcoin
Race conditions like these are hard, not an easy thing to solve in lightning apps.
Mmm so is my understanding correct:
- Receive withdraw request
- Check balance and proceed if enough balance
- Execute withdraw and wait for success or failure
- Update balance
So an attacker just issues a 1000 concurrent withdraws. Step 4 hasn't happened yet so they can withdraw more than their balance.
Solution: Step 4 should go before step 3. Update the balance before executing withdrawals. Handle payment failures later, worse case they don't drain your wallet
reply
Yeah, since payment failures are common in lightning you can just put a temporary hold on the balance and then properly handle the balances after the payment completes. Can also just not allow concurrent withdrawals but that can provide a bad experience
reply
I agree with all said, but want to add a little point about UX or bad experience... when you handle money... UX is the "last" of your priority, the back fire when you lose other people money is SO bad for your application that throw all the UX to the garbage.
Focus on "don't" lose money first, and then add all the shitty lights, remember... we are competing with banks... worst UX in the world.
reply
Actually there were locks in place for these, but the bug was much less trivial: it was timing between the time it took to save the new tx to the dB and the balance compute from dB. There were (keyed per wallet) locks all over the place
reply