Race conditions like these are hard, not an easy thing to solve in lightning apps.
reply
Mmm so is my understanding correct:
  1. Receive withdraw request
  2. Check balance and proceed if enough balance
  3. Execute withdraw and wait for success or failure
  4. 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
Who wrote that?
reply
The dev
reply
NYK, NYC
reply
This was more of a #reckless than a "No keys no cheese" situation.
Affected users had their keys. The issue was that they delegated those keys to an algorithm that automates signing. A bug in the algorithm allowed attackers to "trick" the software into signing wallet draining transactions.
Only delegate signing to audited or time tested code. Or mitigate loss by only delegating keys with minimal funds.
reply