feat: track mobile hd paths for coinjoin

[PastaPastaPasta]

mobile uses specific hd paths for coinjoin funds. We should at least be able to find and view these funds. We should consider using these paths for coinjoin funds.

[HashEngineering]

https://github.com/dashpay/dips/blob/master/dip-0009/assignments.md

In the example below
9' is means a Dash feature
5' is DASH mainnet (testnet would use 1 instead)
4' is CoinJoin
0' is account 0
0 is external
0 is the first index

For example, the first key of Account 0 for CoinJoin would be at m/9'/5'/4'/0'/0/0.

[PastaPastaPasta]

Implementation Plan: Mobile HD Paths for CoinJoin

Based on my analysis of the codebase and DIP-0009 specifications, here's a detailed plan to implement mobile HD path support for CoinJoin funds in Dash Core.

Background

Currently, Dash Core uses standard BIP44 paths (m/44'/5'/account'/change/index) for all addresses, including CoinJoin. Mobile wallets use DIP-0009 specified paths (m/9'/5'/4'/0'/0/index) for CoinJoin funds. This incompatibility prevents Core from recognizing CoinJoin funds from mobile wallets.

Implementation Overview

Phase 1: Core HD Path Infrastructure

1. Extend HD Chain Support

   • Modify hdchain.h/cpp to support multiple HD purposes (currently hardcoded to 44')
   • Add support for feature-specific derivation paths
   • Implement path type enumeration (BIP44_STANDARD, DIP9_COINJOIN, etc.)

2. Update Key Generation

   • Modify scriptpubkeyman.cpp to accept HD path type parameter
   • Update DeriveNewChildKey() to use appropriate derivation path based on type
   • Extend GenerateNewKey() to support CoinJoin-specific paths

Phase 2: CoinJoin Integration

1. CoinJoin-Specific Key Management

   • Modify CKeyHolder in coinjoin/util.cpp to specify HD path type
   • Update ReserveDestination to accept path type parameter
   • Add CoinJoin-specific keypool management

2. Address Discovery

   • Implement scanning for both standard and DIP-0009 CoinJoin addresses
   • Add wallet rescan functionality to detect mobile CoinJoin funds
   • Update gap limit handling for CoinJoin paths

Phase 3: Configuration and Migration

1. User Configuration

   • Add wallet flag to enable mobile HD path compatibility
   • RPC commands to control HD path behavior
   • GUI options for HD path preferences

2. Migration Support

   • Tool to migrate existing CoinJoin funds to new paths
   • Backward compatibility for existing CoinJoin addresses
   • Clear upgrade path for users

Detailed Technical Changes

1. New Constants (src/wallet/wallet.h)

enum class HDPurpose : uint32_t {
    BIP44_STANDARD = 44,
    DIP9_FEATURES = 9
};

enum class DIP9Feature : uint32_t {
    COINJOIN = 4
};

2. Modified DeriveChildExtKey (src/wallet/hdchain.cpp)

void DeriveChildExtKey(uint32_t nAccountIndex, bool fInternal, uint32_t nChildIndex, 
                       CExtKey& extKeyRet, KeyPurpose purpose = KeyPurpose::BIP44_STANDARD,
                       uint32_t feature = 0);

3. Updated ScriptPubKeyMan (src/wallet/scriptpubkeyman.cpp)

• Add path type parameter to key generation methods
• Maintain separate keypools for different HD paths
• Update address generation logic

4. CoinJoin Modifications (src/coinjoin/)

• Update PrepareDenominate to use DIP-0009 paths when configured
• Modify CKeyHolder to specify CoinJoin path type
• Add path type awareness to mixing logic

5. Wallet Scanning (src/wallet/wallet.cpp)

• Extend ScanForWalletTransactions to check multiple HD paths
• Add logic to detect and import mobile CoinJoin addresses
• Update balance calculation to include all paths

Testing Plan

1. Unit tests for new HD derivation logic
2. Functional tests for CoinJoin with mobile paths
3. Migration testing from standard to mobile paths
4. Cross-wallet compatibility tests
5. Performance impact assessment

User Impact

• Positive: Full compatibility with mobile wallets, unified CoinJoin experience
• Minimal disruption: Opt-in feature, existing functionality preserved
• Clear upgrade path: Tools and documentation for migration

Timeline Estimate

• Phase 1: 2-3 weeks (core infrastructure)
• Phase 2: 2-3 weeks (CoinJoin integration)
• Phase 3: 1-2 weeks (configuration and migration)
• Testing: 1-2 weeks
• Total: 6-10 weeks

Open Questions

1. Should mobile HD paths be default for new wallets?
2. How to handle mixed path usage in single wallet?
3. Performance implications of scanning multiple paths?

I'm ready to begin implementation upon approval. Please provide feedback on this plan.

[PastaPastaPasta]

Updated Implementation Plan: Mobile HD Path Support for CoinJoin (v2)

After further analysis of the codebase and requirements, here's an updated and more detailed implementation plan:

1. Core HD Path Infrastructure Enhancements

1.1 Derivation Path Abstraction

// New classes to add:
class DerivationPath {
    enum Purpose { BIP44 = 44, DIP0009 = 9 };
    enum Feature { NONE = 0, COINJOIN = 4 };
    
    uint32_t purpose;
    uint32_t coin_type;
    uint32_t feature;
    uint32_t account;
    uint32_t change;
    uint32_t index;
};

class DerivationStandard {
    virtual DerivationPath GetPath(uint32_t account, bool internal, uint32_t index) = 0;
    virtual bool SupportsFeature(uint32_t feature) = 0;
};

1.2 Refactor CHDChain::DeriveChildExtKey

// Current: Hardcoded BIP44
void DeriveChildExtKey(uint32_t nAccountIndex, bool fInternal, uint32_t nChildIndex, 
                      CExtKey& extKeyRet, KeyOriginInfo& key_origin);

// New: Support multiple standards
void DeriveChildExtKey(const DerivationPath& path, CExtKey& extKeyRet, 
                      KeyOriginInfo& key_origin);

2. Multi-Path Key Management

2.1 Enhanced Key Pool Architecture

• Separate key pools per derivation standard
• Configurable pre-generation thresholds
• Lazy loading to minimize memory usage

class MultiPathKeyPool {
    std::map<DerivationStandard*, KeyPool> m_pools;
    size_t m_default_size{1000};
    size_t m_coinjoin_size{2000}; // Larger for CoinJoin
};

2.2 Wallet Database Schema Updates

-- New tables
CREATE TABLE wallet_derivation_paths (
    id INTEGER PRIMARY KEY,
    standard TEXT NOT NULL,  -- 'BIP44' or 'DIP0009'
    purpose INTEGER NOT NULL,
    feature INTEGER,
    enabled BOOLEAN DEFAULT 1
);

CREATE TABLE address_derivation_info (
    address TEXT PRIMARY KEY,
    path_id INTEGER REFERENCES wallet_derivation_paths(id),
    account INTEGER,
    is_change BOOLEAN,
    address_index INTEGER
);

3. Optimized Scanning Strategy

3.1 Parallel Path Scanning

class ParallelPathScanner {
    // Scan multiple derivation paths concurrently
    std::vector<std::future<ScanResult>> ScanPaths(
        const std::vector<DerivationStandard*>& standards,
        const CBlockIndex* pindexStart,
        const CBlockIndex* pindexStop
    );
    
    // Intelligent ordering based on wallet history
    std::vector<DerivationStandard*> GetScanOrder();
};

3.2 Performance Optimizations

• Gap limit optimization: Stop scanning a path after N consecutive unused addresses
• Bloom filter pre-check: Quick elimination of irrelevant transactions
• Cached derivation: Store frequently used derived keys
• Lazy DIP-0009 activation: Only scan mobile paths if CoinJoin is/was active

4. CoinJoin Integration Details

4.1 Path Selection Logic

DerivationPath CCoinJoinClientSession::GetNextCoinJoinPath(bool use_mobile_path) {
    if (use_mobile_path && wallet->IsMobilePathEnabled()) {
        // m/9'/5'/4'/account'/0/index
        return DerivationPath{9, 5, 4, GetAccountIndex(), 0, GetNextIndex()};
    }
    // Fallback to BIP44: m/44'/5'/account'/0/index
    return DerivationPath{44, 5, 0, GetAccountIndex(), 0, GetNextIndex()};
}

4.2 Change Address Handling

• CoinJoin doesn't typically use change addresses (internal chain)
• Validate that mobile paths only use external chain (change=0)
• Add warnings if internal CoinJoin addresses are detected

5. Migration Tools

5.1 Migration RPC Commands

// Analyze current CoinJoin usage
coinjoin_analyzemigration
{
    "bip44_coinjoin_utxos": 150,
    "total_value": "1234.5",
    "migration_recommended": true,
    "estimated_fee": "0.001"
}

// Perform migration (with dry-run option)
coinjoin_migrate "dry_run"=false "fee_rate"=1000
{
    "migrated_utxos": 150,
    "new_addresses": [...],
    "transaction_ids": [...],
    "backup_created": "/path/to/backup"
}

5.2 Safety Measures

• Automatic wallet backup before migration
• Dry-run mode to preview changes
• Progressive migration (batches to avoid large transactions)
• Rollback capability within 24 hours

6. Configuration and RPC Updates

6.1 New Configuration Options

-enablemobilecoinjoinpaths=<bool>  # Enable DIP-0009 path scanning
-coinjoinderivationstandard=<std>  # "bip44", "dip0009", or "both"
-coinjoinmigrationprompt=<bool>    # Prompt user to migrate on startup
-maxderivationgap=<n>              # Gap limit for address scanning (default: 20)

6.2 Enhanced RPC Commands

// Get derivation path info
getaddressinfo "address"
{
    ...
    "hdkeypath": "m/9'/5'/4'/0'/0/5",  // Full path
    "derivation_standard": "DIP0009",   // Standard used
    "is_coinjoin": true,                // Address purpose
    ...
}

// List supported standards
listderivationstandards
[
    {
        "standard": "BIP44",
        "purpose": 44,
        "enabled": true,
        "address_count": 1523
    },
    {
        "standard": "DIP0009",
        "purpose": 9,
        "feature": 4,
        "enabled": true,
        "address_count": 245
    }
]

7. Testing Strategy

7.1 Unit Tests

• hdchain_tests.cpp: Multi-standard derivation tests
• coinjoin_hdpath_tests.cpp: CoinJoin-specific path tests
• migration_tests.cpp: Migration logic validation

7.2 Integration Tests

• Full wallet scan with both path types
• CoinJoin mixing with mobile paths
• Migration scenarios (success/failure/rollback)
• Performance benchmarks

7.3 Testnet Deployment

• Extended testnet testing period (2-4 weeks)
• Community testing bounty program
• Mobile wallet integration testing

8. Implementation Timeline

Phase 1 (Weeks 1-3): Foundation

• Implement DerivationPath abstraction
• Refactor CHDChain for multi-standard support
• Update wallet database schema

Phase 2 (Weeks 4-6): Path Management

• Implement multi-path key pools
• Add parallel scanning logic
• Create performance optimizations

Phase 3 (Weeks 7-8): CoinJoin Integration

• Update CoinJoin client for path selection
• Implement mobile path preference logic
• Add validation for proper path usage

Phase 4 (Weeks 9-10): Migration & Tools

• Create migration RPC commands
• Implement safety measures
• Add configuration options

Phase 5 (Weeks 11-12): Testing & Polish

• Comprehensive test suite
• Performance optimization
• Documentation updates

9. Backward Compatibility

• Existing wallets continue using BIP44 by default
• No changes required for non-CoinJoin users
• Gradual opt-in to mobile paths
• Full compatibility with existing CoinJoin infrastructure

10. Security Considerations

• Path derivation must be deterministic and secure
• Prevent accidental key reuse across standards
• Validate all path components against specifications
• Audit trail for migration operations

This updated plan addresses the technical details, performance considerations, and safety measures needed for successful implementation of mobile HD path support in Dash Core.

🤖 Generated with Claude Code

Co-Authored-By: Claude noreply@anthropic.com