Oddbean new post about | logout
▲ ▼
Minibits | 14 days ago (raw) | root | parent | reply | flag 
 Wallet issue than. Head to recovery and press Remove spent ecash. It will fix it.

Will need to simulate the issue, for now seems like final cleaning at the end of tx does not complete, preventing further transactions. Lastly tried 10 zaps with killed app in real hurry but dev env / device seem resilient and they all passed along trace-level logging.

Need to try harder.
▲ ▼
Vitor Pamplona | 14 days ago (raw) | root | parent | reply | flag 
 So, I had a single 100 sat token and was spending 1 sat in each of the 20 payments. Maybe there is a race condition when updating the token?
▲ ▼
Minibits | 14 days ago (raw) | root | parent | reply | flag 
 You're right that a race condition could lead to the same or similar other issues. 

Your original 100sats were represented by ^2 set of proofs (ecash notes) at the beginning - 64,32,4. To get 1sat, (let's ignore fee reserve for simplicity) wallet takes 64 proof and swaps it with the mint for 32,16,8,1,1 and uses 1sat proof to settle payment.
For lightning fee reserve, mint retutns unused fees as a fresh ecash back to wallet.

So plenty room to race inside the wallet state or get out of sync with the mint in case of parallel/async processes.

Minibits internally uses synchronous queue for all ecash ops to prevent that + locks during network requests (so it can e.g. recover back sent ecash when mint response won't come at all).

Even technically prevented, I still might have some logical issue leading to race condition but was not so far able to pin it. As it happens much more often with nwc, background procesessing is suspicious to me as well.

Will repeat your exact 20x1sat zaps test case on dev device.