Update CRYPTO_PROBLEMS.rst with MONERO DOOM learnings

- Document resolved multiple duplicate payment scenario
- Explain min(balance, expected_fee) restocking fee solution
- Clarify auto-sweep uses exact amounts, not sweep_all
- Add details about fund theft prevention mechanisms
This commit is contained in:
Russell Ballestrini 2025-09-30 22:47:45 -04:00
parent edb236be60
commit 3a205c99a0

View file

@ -91,17 +91,27 @@ Transaction Failure Scenarios
**Current Behavior**:
- First payment completes order
- Second payment automatically swept to shop's cold wallet (✓ RESOLVED)
- Second payment automatically refunded minus 9% restocking fee (✓ RESOLVED)
- Multiple duplicate payments handled correctly (✓ RESOLVED - see "The MONERO DOOM Scenario")
**Implemented Solutions**:
- ✓ Refund address collected at checkout for potential refunds
- ✓ Auto-sweep prevents duplicate payments from accumulating
- ✓ Duplicate payments detected and marked as STATUS_DOUBLEPAY_REFUND
- ✓ Automatic refund minus 9% restocking fee
- ✓ Safe restocking fee collection using min(balance, expected_fee) logic
- ✓ Priority system ensures refunds complete before fee collection
**The MONERO DOOM Scenario (✓ RESOLVED)**:
Multiple duplicate payments to same address exposed a critical design flaw where restocking fee sweeps
could steal funds from other payments sharing the same subaddress. The solution implemented:
- Each restocking fee sweep only takes min(balance, expected_fee)
- Prevents fund theft between payments
- 9% fee is exact (network fees deducted from refund, not restocking)
- Priority 4 (lowest) for restocking sweeps with mid-tier confirmation requirements
**Remaining Solutions Needed**:
- Detect and flag duplicate payments within time window
- Auto-refund second payment if refund address known
- **WANT**: Email notification about duplicate payment
- Add "payment already received" status check
- Add "payment already received" status check in UI
6. Network/Mempool Congestion
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@ -258,11 +268,12 @@ General Solutions Architecture
**Auto-Sweep Process**:
- Executes immediately after required confirmations are reached
- Uses "sweep_all" to transfer entire account balance to cold wallet
- Sweeps exact payment amounts to cold wallet (not entire balance)
- Each shop has dedicated Monero account (prevents cross-shop fund mixing)
- Account isolation: Shop A uses account 0, Shop B uses account 1, etc.
- Each payment swept individually using subaddress isolation
- 1:1 payment-to-sweep mapping for clear audit trail and accounting
- Each payment swept individually using precise amount accounting
- 1:1 payment-to-sweep mapping for clear audit trail
- Restocking fees use min(balance, expected_fee) to prevent fund theft
- Insufficient balance handling: Payment retries later until funds unlock
- Failed sweeps are logged but don't block order fulfillment