make_post_sell/DOGE_DOOM.rst

================================================================================
DOGE DOOM: Micro-Underpayment Refund Deadlock Vulnerability
================================================================================

:Date: 2025-10-03
:Discovered by: walkeruin 
:Severity: Medium - System Resource Exhaustion
:Bounty: 1 XMR (as claimed by walkeruin)

Overview
========

Walkeruin discovered a way to potentially deadlock the crypto payment system by
sending tiny DOGE underpayments that are too small to be economically refunded.

The Attack Vector
=================

1. **Micro-Underpayments**: Attacker sends ~$0.01 USD worth of DOGE (0.04 DOGE) 
   for a payment requiring ~$2.50 USD worth (2.57 DOGE)

2. **Refund Calculation**: System calculates refund as:
   - Customer refund: 0.0364 DOGE (received - 9% fee)
   - Shop fee: 0.0036 DOGE

3. **Network Fee Reality**: DOGE transactions require:
   - Base network fee: ~0.001-0.003 DOGE per transaction
   - Our fee buffer: 0.005 DOGE (configurable)
   - Total estimated cost: ~0.006-0.008 DOGE

4. **Economic Impossibility**: 
   - Total refund outputs: 0.04 DOGE
   - Network fees: ~0.006-0.008 DOGE  
   - **Problem**: Not enough funds to cover both outputs AND network fees

Log Evidence
============

From production logs (2025-10-03 13:29:00)::

    Processing payment (status: underpaid-refunded, coin: DOGE, incoming: 17/2, refund: N/A): 
    Payment cb9f37bb [underpaid-refunded] DOGE 0.04/2.57356623 conf:17/2

    Attempting to refund: Payment cb9f37bb [underpaid-refunded] DOGE 0.04/2.57356623

    Refund: 0.0364 DOGE to customer, 0.0036 DOGE fee to shop

    ERROR: Refund failed: Payment cb9f37bb - Dogecoin RPC connection error: 
    500 Server Error: Internal Server Error

The "500 Server Error" is likely the DOGE daemon rejecting the transaction due to
insufficient funds to cover network fees.

Impact Analysis
===============

**Immediate Impact:**
- System retries failed refunds every cycle (20 seconds)
- Each retry wastes CPU/network resources
- Failed transactions clog processing logs

**Potential Scaling Attack:**
- Attacker could create hundreds of micro-underpayments
- Each creates a permanent "refund debt" that can never be paid
- System resources consumed by endless retry attempts
- Monitoring alerts triggered by constant refund failures

**Economic Threshold:**
For DOGE, refunds become economically unviable when:
``received_amount < (network_fee + fee_buffer + minimum_output)``

With current settings:
- Network fee: ~0.001-0.003 DOGE
- Fee buffer: 0.005 DOGE  
- Minimum outputs: 0.00000001 DOGE each (dust limit)
- **Minimum viable refund: ~0.008-0.010 DOGE (~$0.03-$0.04 USD)**

Attack Reproduction
===================

1. Create invoice for $2.50+ USD worth of DOGE
2. Send exactly $0.01 USD worth of DOGE to payment address
3. System processes as underpayment, attempts refund
4. Refund fails due to insufficient funds for network fees
5. System retries every 20 seconds indefinitely

Proposed Mitigations
====================

**Option 1: Minimum Refund Threshold**
- Skip refunds below economic viability threshold
- Set minimum refund amount (e.g., 0.01 DOGE)
- Log but don't retry sub-economic refunds

**Option 2: Administrative Fee Absorption**
- Shop pays network fees for micro-refunds from their balance
- Only viable if shop has sufficient DOGE balance

**Option 3: Refund Aggregation**
- Batch small refunds together to amortize network fees
- More complex to implement but more efficient

**Option 4: Graceful Failure Mode**
- Mark micro-underpayments as "unrefundable" after N failures
- Stop retry attempts, preserve system resources
- Manual intervention for legitimate cases

Recommended Fix
===============

Implement Option 1 (Minimum Refund Threshold) as immediate mitigation:

1. **Add Economic Viability Check**::

    def is_refund_economically_viable(refund_amount, coin_type):
        if coin_type == "DOGE":
            # Network fee + buffer + dust outputs
            minimum_viable = 0.01  # ~$0.03-$0.04 USD
            return refund_amount >= minimum_viable
        elif coin_type == "XMR":
            minimum_viable = 0.001  # Adjust for XMR economics
            return refund_amount >= minimum_viable
        return True

2. **Skip Sub-Economic Refunds**::

    if not is_refund_economically_viable(refund_amount, payment.coin_type):
        logger.warning(f"Skipping economically unviable refund: {payment}")
        payment.status = "refund-uneconomical" 
        return

3. **Add New Payment Status**: ``refund-uneconomical``
   - Distinguishes from normal refund failures
   - Allows manual review/intervention if needed
   - Stops automated retry cycles

Technical Details
=================

**DOGE Fee Structure:**
- Base fee: 0.001 DOGE per KB
- Multi-output transactions: ~0.5-1.0 KB
- Typical fee: 0.001-0.003 DOGE
- Our fee buffer: 0.005 DOGE (configurable via DOGE_REFUND_FEE_BUFFER)

**Economic Break-Even:**
For a refund to be viable, the received amount must exceed:
``network_fee + fee_buffer + min(customer_refund_output, dust_limit) + min(shop_fee_output, dust_limit)``

**Current Vulnerability Window:**
Any DOGE payment between 0.00000001 and ~0.01 DOGE can trigger this issue.

Timeline
========

- **2025-10-03**: Issue discovered by walkeruin
- **2025-10-03**: Documented in DOGE_DOOM.rst
- **Status**: Active vulnerability, mitigation needed

Bounty Notes
============

Walkeruin claims this vulnerability is worth 1 XMR. The assessment:

**Pros:**
- Novel attack vector not previously considered
- Can potentially exhaust system resources
- Affects real production payments
- Clever exploitation of economic limitations

**Cons:**
- Limited to DOGE (XMR has different economics)
- Doesn't steal funds, just wastes resources
- Relatively easy to mitigate once identified

**Recommendation**: Consider 0.1-0.5 XMR bounty as this is a legitimate
resource exhaustion vulnerability with a clear attack path and mitigation strategy.

================================================================================