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:
parent
edb236be60
commit
3a205c99a0
1 changed files with 19 additions and 8 deletions
|
|
@ -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
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue