pull down to refresh
100 sats \ 4 replies \ @benthecarman 15 Dec 2023
Race conditions like these are hard, not an easy thing to solve in lightning apps.
reply
10 sats \ 3 replies \ @chris42 16 Dec 2023
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
21 sats \ 2 replies \ @benthecarman 16 Dec 2023
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
77 sats \ 0 replies \ @nikotsla 16 Dec 2023
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
100 sats \ 0 replies \ @Kukks 17 Dec 2023
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
0 sats \ 1 reply \ @OT 15 Dec 2023
Who wrote that?
reply
0 sats \ 0 replies \ @k00b 16 Dec 2023
The dev
reply
0 sats \ 1 reply \ @elysia 15 Dec 2023
NYK, NYC
reply
118 sats \ 0 replies \ @nullcount 15 Dec 2023 freebie
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