235 lines
8.2 KiB
Markdown
235 lines
8.2 KiB
Markdown
# Proof of Work Algorithm Analysis
|
|
|
|
## Overview
|
|
|
|
This document analyzes various Proof of Work (PoW) algorithms considered for the Word of Wisdom protocol and provides detailed justification for the chosen approach.
|
|
|
|
## PoW Algorithm Alternatives
|
|
|
|
### 1. SHA-256 Hashcash (CHOSEN)
|
|
|
|
**Description**: Bitcoin-style hashcash requiring hash output with specific number of leading zero bits.
|
|
|
|
**Pros**:
|
|
- Widely tested and battle-proven in Bitcoin
|
|
- Simple to implement and verify
|
|
- CPU-bound computation (fair across hardware)
|
|
- Adjustable difficulty through leading zero bits
|
|
- Fast verification (single SHA-256 hash)
|
|
- No memory requirements
|
|
- Deterministic verification time
|
|
|
|
**Cons**:
|
|
- Vulnerable to ASIC mining (specialized hardware advantage)
|
|
- Power consumption scales with difficulty
|
|
- Brute force approach (no early termination)
|
|
|
|
**Our Mitigation**:
|
|
- DDOS protection doesn't require ASIC resistance (temporary challenges)
|
|
- Difficulty kept low (3-6 bits) to minimize power consumption
|
|
- Server-controlled difficulty prevents client-side optimization attacks
|
|
|
|
### 2. Scrypt
|
|
|
|
**Description**: Memory-hard function designed to resist ASIC mining.
|
|
|
|
**Pros**:
|
|
- ASIC-resistant design
|
|
- Memory-hard computation
|
|
- Battle-tested in Litecoin
|
|
- Configurable memory and time parameters
|
|
|
|
**Cons**:
|
|
- Complex implementation
|
|
- Memory requirements may disadvantage mobile clients
|
|
- Slower verification than simple hashing
|
|
- Parameter tuning complexity
|
|
- Potential denial-of-service on client memory
|
|
|
|
**Why Not Chosen**:
|
|
- Unnecessary complexity for DDOS protection use case
|
|
- Memory requirements create client hardware discrimination
|
|
- Verification overhead impacts server performance under attack
|
|
|
|
### 3. Equihash
|
|
|
|
**Description**: Memory-hard algorithm based on birthday paradox, used in Zcash.
|
|
|
|
**Pros**:
|
|
- ASIC-resistant through memory requirements
|
|
- Mathematically elegant approach
|
|
- Proven in production cryptocurrency
|
|
- Configurable memory parameters
|
|
|
|
**Cons**:
|
|
- Very complex implementation
|
|
- High memory requirements (150+ MB typically)
|
|
- Slow verification process
|
|
- Not suitable for lightweight clients
|
|
- Complex parameter selection
|
|
|
|
**Why Not Chosen**:
|
|
- Excessive complexity and resource requirements
|
|
- Poor fit for anti-DDOS use case requiring quick challenges
|
|
- Would exclude mobile and embedded clients
|
|
|
|
### 4. Argon2
|
|
|
|
**Description**: Modern password hashing function winner, memory-hard with multiple variants.
|
|
|
|
**Pros**:
|
|
- Designed for modern security requirements
|
|
- Multiple variants (Argon2i, Argon2d, Argon2id)
|
|
- Configurable time/memory trade-offs
|
|
- Resistant to side-channel attacks
|
|
- ASIC-resistant design
|
|
|
|
**Cons**:
|
|
- Primarily designed for password hashing, not PoW
|
|
- Memory requirements create client inequality
|
|
- Complex implementation with many parameters
|
|
- Slower than simple hashing functions
|
|
- Not optimized for network protocols
|
|
|
|
**Why Not Chosen**:
|
|
- Over-engineered for DDOS protection scenario
|
|
- Memory requirements discriminate against resource-constrained clients
|
|
- Verification overhead impacts server scalability
|
|
|
|
### 5. CryptoNight
|
|
|
|
**Description**: Memory-hard algorithm designed for CPU mining, used in Monero.
|
|
|
|
**Pros**:
|
|
- CPU-optimized design
|
|
- ASIC-resistant through memory requirements
|
|
- Ring buffer memory pattern
|
|
- Proven in cryptocurrency applications
|
|
|
|
**Cons**:
|
|
- 2MB memory requirement per instance
|
|
- Complex implementation
|
|
- Slower verification than simple hashing
|
|
- Memory requirements exclude lightweight clients
|
|
- Frequent algorithm updates needed for ASIC resistance
|
|
|
|
**Why Not Chosen**:
|
|
- Memory requirements too high for general clients
|
|
- Complexity outweighs benefits for anti-DDOS use case
|
|
- Algorithm instability due to frequent updates
|
|
|
|
### 6. Cuckoo Cycle
|
|
|
|
**Description**: Graph-theoretic PoW based on finding cycles in random graphs.
|
|
|
|
**Pros**:
|
|
- Memory-hard through graph traversal
|
|
- Mathematically interesting approach
|
|
- ASIC-resistant design
|
|
- Adjustable memory requirements
|
|
|
|
**Cons**:
|
|
- Very complex implementation
|
|
- High memory requirements
|
|
- Slow verification process
|
|
- Limited production experience
|
|
- Complex parameter tuning
|
|
|
|
**Why Not Chosen**:
|
|
- Excessive complexity for simple DDOS protection
|
|
- Memory requirements create client barriers
|
|
- Unproven in high-throughput server scenarios
|
|
|
|
### 7. X11/X16R (Multi-Hash)
|
|
|
|
**Description**: Combines multiple hash functions in sequence or rotation.
|
|
|
|
**Pros**:
|
|
- ASIC-resistant through algorithm diversity
|
|
- Harder to optimize with specialized hardware
|
|
- Proven in some cryptocurrencies
|
|
|
|
**Cons**:
|
|
- Complex implementation requiring multiple hash functions
|
|
- Slower than single-hash approaches
|
|
- More attack surface (multiple algorithms)
|
|
- Difficult to verify implementation correctness
|
|
- Higher CPU usage for verification
|
|
|
|
**Why Not Chosen**:
|
|
- Unnecessary complexity for anti-DDOS use case
|
|
- Multiple algorithms increase implementation risk
|
|
- Verification overhead impacts server performance
|
|
|
|
## Decision Matrix
|
|
|
|
| Algorithm | Complexity | Speed | Memory | ASIC Resistance | Implementation Risk | Server Impact |
|
|
|-----------|------------|-------|--------|-----------------|-------------------|---------------|
|
|
| **SHA-256 Hashcash** | Low | High | None | Low | Low | Low |
|
|
| Scrypt | Medium | Medium | High | High | Medium | Medium |
|
|
| Equihash | High | Low | Very High | High | High | High |
|
|
| Argon2 | High | Low | High | High | Medium | Medium |
|
|
| CryptoNight | High | Low | High | High | High | High |
|
|
| Cuckoo Cycle | Very High | Low | High | High | Very High | High |
|
|
| X11/X16R | High | Medium | Low | Medium | High | Medium |
|
|
|
|
## Final Decision: SHA-256 Hashcash
|
|
|
|
### Primary Justifications
|
|
|
|
1. **Simplicity**: Single, well-understood hash function with minimal implementation complexity
|
|
2. **Performance**: Fast computation and near-instant verification enable high server throughput
|
|
3. **Universality**: No memory requirements ensure compatibility across all client types
|
|
4. **Proven Reliability**: Battle-tested in Bitcoin with 15+ years of production experience
|
|
5. **Adjustable Difficulty**: Fine-grained control through leading zero bits (3-10 bits practical range)
|
|
|
|
### ASIC Resistance Not Required
|
|
|
|
For DDOS protection, ASIC resistance is unnecessary because:
|
|
|
|
- **Temporary Challenges**: Each challenge is unique and expires within minutes
|
|
- **Cost vs. Benefit**: ASIC development cost far exceeds potential attack value
|
|
- **Dynamic Difficulty**: Server can adjust difficulty faster than ASIC deployment
|
|
- **Legitimate Use**: No financial incentive for specialized hardware development
|
|
|
|
### Enhanced Security Through HMAC Integration
|
|
|
|
Our implementation addresses SHA-256 hashcash limitations:
|
|
|
|
- **Stateless Operation**: HMAC signatures eliminate server storage requirements
|
|
- **Replay Protection**: Timestamp + HMAC prevents challenge reuse
|
|
- **Forgery Prevention**: Server secret prevents challenge generation attacks
|
|
- **Scalability**: No server state enables horizontal scaling without coordination
|
|
|
|
### Addressing SHA-256 Cons
|
|
|
|
1. **ASIC Advantage**: Mitigated by low difficulty and temporary challenges
|
|
2. **Power Consumption**: Limited by max 6-bit difficulty (average 64 attempts)
|
|
3. **Brute Force**: Acceptable for anti-DDOS where work proof is the goal
|
|
|
|
### Alternative Deployment Scenarios
|
|
|
|
If future requirements change, our architecture supports algorithm swapping:
|
|
|
|
- **Mobile-Heavy Clients**: Reduce difficulty to 2-3 bits
|
|
- **High-Security Environments**: Increase difficulty to 8-10 bits
|
|
- **Algorithm Migration**: Protocol supports algorithm field for future updates
|
|
- **Hybrid Approach**: Different algorithms per client capability
|
|
|
|
## Implementation Recommendations
|
|
|
|
### Difficulty Scaling Strategy
|
|
|
|
- **Start Conservative**: Begin with 4-bit difficulty (16 attempts average)
|
|
- **Monitor Performance**: Track client success rates and completion times
|
|
- **Adjust Dynamically**: Increase difficulty under attack, decrease during normal operation
|
|
- **Client Feedback**: Monitor error rates to avoid excluding legitimate clients
|
|
|
|
### Future Evolution Path
|
|
|
|
1. **Phase 1**: SHA-256 hashcash with HMAC (current)
|
|
2. **Phase 2**: Optional client capability negotiation
|
|
3. **Phase 3**: Multi-algorithm support for different client classes
|
|
4. **Phase 4**: Machine learning-based difficulty adjustment
|
|
|
|
The chosen SHA-256 hashcash approach provides the optimal balance of simplicity, performance, and security for our anti-DDOS use case while maintaining flexibility for future enhancement. |