diff --git a/Jericho Consensus.md b/Jericho Consensus.md index 3f14649..cfbc972 100644 --- a/Jericho Consensus.md +++ b/Jericho Consensus.md @@ -10,6 +10,349 @@ Jericho is a Byzantine fault-tolerant consensus mechanism combining CPU-equivale Miners compete using a proof-of-work hash function based on large integer long division—an operation that cannot be meaningfully accelerated by specialized hardware. This ensures fair token issuance where acquisition cost is equivalent regardless of participant scale. +### Proof of Work Function + +The proof of work uses iterative squaring with long division, expanding the working number until it exceeds 128 MB. This creates memory-hard, CPU-bound computation that resists ASIC acceleration. + +#### Algorithm + +``` +function proof_of_work(block_header, nonce) -> hash: + // Initialize from block header + seed = SHA3-256(block_header || nonce) + N = big_int_from_bytes(seed) // 256-bit initial value + D = extract_divisor(seed) // 128-bit divisor from least significant bits + + // Expansion loop: square and divide until size exceeds 128 MB + while byte_length(N) < 134,217,728: // 2^27 bytes = 128 MB + N = N * N // Square (doubles bit length) + D = extract_divisor(N) // Update divisor from LSB 128 bits + (Q, R) = divmod(N, D) // Long division + N = Q ^ R // XOR quotient and remainder + + // Final hash of expanded state + return SHA3-256(N.to_bytes()) +``` + +#### Divisor Extraction + +The divisor is derived from the least significant 128 bits of the current number, with safeguards against trivial division: + +``` +function extract_divisor(N) -> D: + raw = N & ((1 << 128) - 1) // Extract LSB 128 bits + D = raw | (1 << 127) // Set high bit (ensures D >= 2^127) + D = D | 1 // Set low bit (ensures D is odd) + return D +``` + +Setting the high bit guarantees the divisor is always at least 2^127, preventing degenerate cases where division barely reduces the number. Setting the low bit ensures the divisor is odd, maximizing the information mixed by the remainder. + +#### Expansion Dynamics + +Each iteration approximately doubles the bit length through squaring, then the XOR of quotient and remainder preserves most of the entropy: + +``` +Iteration | Approximate Size | Operations +----------|------------------|--------------------------- +0 | 256 bits | Initial seed +1 | 512 bits | Square → divide → XOR +2 | 1 KB | Square → divide → XOR +3 | 2 KB | Square → divide → XOR +... | ... | ... +17 | 32 MB | Square → divide → XOR +18 | 64 MB | Square → divide → XOR +19 | 128 MB | Square → divide → XOR (terminal) +``` + +The algorithm completes in approximately 19-20 iterations, each requiring: +- One large integer multiplication (squaring) +- One large integer division +- One XOR operation + +#### Memory Hardness + +The working number N must be held entirely in memory during computation: +- Cannot be streamed or computed in chunks (squaring requires full number) +- Division requires random access across the full dividend +- Peak memory: ~128 MB per proof attempt + +This memory requirement makes the algorithm hostile to: +- **ASICs**: Would need 128 MB on-chip memory per parallel unit +- **GPUs**: Limited by memory bandwidth for large integer operations +- **FPGAs**: Same memory constraints as ASICs + +Standard CPUs with large L3 caches and system RAM handle this workload efficiently, equalizing hardware advantage. + +#### CPU Equivalence + +Long division of large integers is inherently sequential: +- Each digit of the quotient depends on the running remainder +- Cannot be parallelized beyond word-level operations +- Modern CPUs are highly optimized for this pattern (DIV instructions, branch prediction) + +Custom hardware gains minimal advantage because: +1. Memory bandwidth dominates (128 MB working set) +2. Division is already near-optimal on CPUs +3. Squaring uses standard multiplication circuits + +#### Difficulty Adjustment + +The proof is valid if the final hash meets the difficulty target: + +``` +valid = (SHA3-256(N.to_bytes()) < difficulty_target) +``` + +**Difficulty target encoding:** + +The difficulty target is encoded as a variable-length integer using a floating-point-like representation that provides uniform relative precision across the entire difficulty range: + +``` +encoded_difficulty = (exponent << mantissa_bits) | mantissa + +where: + mantissa_bits = 24 + exponent: 8 bits (0-255) + mantissa: 24 bits (0 to 2^24 - 1) + +decoded_target = (2^24 + mantissa) × 2^(exponent - 24 - 24) + = (2^24 + mantissa) × 2^(exponent - 48) + +Encoded size: 32 bits (4 bytes) fixed +``` + +This encoding provides: +- **Uniform relative error**: Each mantissa increment changes the target by ~0.000006% (1/2^24) +- **Full range coverage**: From 2^-48 to 2^231 (exponent 0-255) +- **No wasted precision**: Unlike fixed-point, precision scales with magnitude + +**Encoding/decoding functions:** + +``` +function encode_target(target) -> uint32: + if target == 0: + return 0 + + // Find exponent: position of highest bit + exp = floor(log2(target)) + + // Extract 24-bit mantissa (excluding implicit leading 1) + if exp >= 24: + mantissa = (target >> (exp - 24)) & 0xFFFFFF + else: + mantissa = (target << (24 - exp)) & 0xFFFFFF + + // Adjust exponent for encoding offset + encoded_exp = exp + 48 - 24 + + // Clamp to valid range + if encoded_exp < 0: + return 0 + if encoded_exp > 255: + return 0xFFFFFFFF + + return (encoded_exp << 24) | (mantissa & 0xFFFFFF) + + +function decode_target(encoded) -> uint256: + if encoded == 0: + return 0 + + exp = encoded >> 24 + mantissa = encoded & 0xFFFFFF + + // Reconstruct: (2^24 + mantissa) × 2^(exp - 48) + significand = (1 << 24) | mantissa + + shift = exp - 48 + if shift >= 0: + return significand << shift + else: + return significand >> (-shift) +``` + +**Adjustment with asymptotic damping:** + +The proportional difficulty adjustment uses asymptotic damping rather than hard clamping. Large deviations produce diminishing adjustments, preventing both liveness failures and mercenary mining exploits: + +``` +function adjust_difficulty(current_encoded, actual_time, expected_time) -> uint32: + // Compute raw ratio + raw_ratio = expected_time / actual_time + + // Apply asymptotic damping: large ratios are compressed + // Uses tanh-like function that approaches ±1 asymptotically + damped_ratio = dampen(raw_ratio) + + // Decode current target + current_target = decode_target(current_encoded) + + // Apply adjustment + new_target = current_target × damped_ratio + + // Re-encode + return encode_target(new_target) + + +function dampen(ratio) -> float: + // Convert ratio to log scale for symmetric handling + // ratio > 1 means blocks too fast (decrease target) + // ratio < 1 means blocks too slow (increase target) + + log_ratio = ln(ratio) + + // Asymptotic compression using scaled tanh + // k controls the "knee" where damping begins + // max_log controls the asymptotic limit + k = 0.5 // damping begins around 1.6× or 0.6× + max_log = 1.5 // asymptotic limit ~4.5× or ~0.22× + + damped_log = max_log × tanh(log_ratio / k) + + return e^damped_log +``` + +**Damping curve properties:** + +``` +Raw Ratio | Log Ratio | Damped Log | Damped Ratio | Effective Adjustment +----------|-----------|------------|--------------|--------------------- +0.10 | -2.30 | -1.46 | 0.23 | +77% easier (was +900%) +0.25 | -1.39 | -1.28 | 0.28 | +72% easier (was +300%) +0.50 | -0.69 | -0.87 | 0.42 | +58% easier (was +100%) +0.75 | -0.29 | -0.47 | 0.63 | +37% easier (was +33%) +1.00 | 0.00 | 0.00 | 1.00 | No change +1.33 | 0.29 | 0.47 | 1.60 | -38% harder (was -25%) +2.00 | 0.69 | 0.87 | 2.39 | -58% harder (was -50%) +4.00 | 1.39 | 1.28 | 3.60 | -72% harder (was -75%) +10.00 | 2.30 | 1.46 | 4.31 | -77% harder (was -90%) +``` + +**Asymmetric protection:** + +The damping function is symmetric in log-space, providing balanced protection against both failure modes: + +| Threat | Without Damping | With Damping | +|--------|-----------------|--------------| +| Mercenary spike (10× hashrate for one period) | Difficulty increases 10×, then 90% of honest miners can't find blocks | Difficulty increases ~4.3×, honest miners remain viable | +| Hashrate collapse (90% miners leave) | Difficulty stays high, blocks take ~100 minutes | Difficulty decreases ~4.3×, blocks recover to ~23 minutes | +| Sustained 2× hashrate | Full 2× adjustment per period | ~2.4× adjustment, slightly faster convergence | +| Sustained 0.5× hashrate | Full 0.5× adjustment per period | ~0.42× adjustment, slightly faster recovery | + +**Liveness guarantee:** + +The asymptotic limit ensures that even with complete hashrate collapse, difficulty eventually decreases enough for any remaining miners to produce blocks: + +``` +Worst case: 99.9% hashrate disappears instantly + +Without damping (4× clamp): + Period 1: 4× easier, blocks still 250× too slow + Period 2: 4× easier, blocks still 62× too slow + Period 3: 4× easier, blocks still 15× too slow + Period 4: 4× easier, blocks still 4× too slow + Period 5: 4× easier, blocks approach normal + Recovery: 5 periods × 2016 blocks × (avg ~25 min) = ~175 days + +With asymptotic damping: + Period 1: 4.3× easier, blocks ~230× too slow + Period 2: 4.3× easier, blocks ~53× too slow + Period 3: 4.3× easier, blocks ~12× too slow + Period 4: 4.3× easier, blocks ~3× too slow + Period 5: ~3× easier, blocks approach normal + Recovery: Similar duration but smoother, no discontinuities + + Crucially: damping applies per-period, so recovery accelerates + as the ratio shrinks back toward 1.0 +``` + +**Anti-mercenary properties:** + +Mercenary miners who briefly contribute massive hashrate to manipulate difficulty are countered: + +``` +Attack: Mercenary adds 9× network hashrate for one period + +Without damping: + Period N: Blocks 10× faster, difficulty increases 10× + Period N+1: Mercenary leaves, honest miners face 10× difficulty + Period N+2: Blocks 10× slower, difficulty decreases (clamped to 4×) + Period N+3: Still 2.5× too hard + Period N+4: Still too hard... + Result: Extended period of slow blocks, chain vulnerable + +With asymptotic damping: + Period N: Blocks 10× faster, difficulty increases ~4.3× + Period N+1: Mercenary leaves, honest miners face 4.3× difficulty + Period N+2: Blocks 4.3× slower, difficulty decreases ~3.6× + Period N+3: Blocks ~1.2× slower, difficulty decreases ~1.15× + Period N+4: Near equilibrium + Result: Faster recovery, reduced attack profitability +``` + +**Fixed sampling window:** + +The adjustment uses a fixed 2016-block sampling window (not dynamic): + +``` +adjustment_trigger = (block_height % 2016 == 0) + +actual_time = timestamp[block_height] - timestamp[block_height - 2016] +expected_time = 2016 × 600 seconds + +Control properties: + - Fixed window: predictable, not gameable by timestamp manipulation + - No integral term: prevents windup from sustained deviations + - No derivative term: avoids oscillation from noise + - Asymptotic damping: prevents both liveness failure and mercenary exploitation +``` + +**Adjustment error analysis:** + +| Adjustment Size | Encoding Error | Damping Distortion | Combined Error | +|-----------------|----------------|-------------------|----------------| +| 1% change | ±0.000006% | < 0.1% | < 0.1% | +| 10% change | ±0.000006% | < 1% | < 1% | +| 50% change | ±0.000006% | ~8% | ~8% | +| 100% change | ±0.000006% | ~20% | ~20% | +| 400% change | ±0.000006% | ~40% | ~40% | + +The damping distortion is intentional—it prevents extreme adjustments while still responding proportionally to moderate deviations. The 24-bit mantissa ensures encoding error remains negligible at all scales. + +**Comparison with Bitcoin's encoding:** + +| Property | Bitcoin (nBits) | Jericho | +|----------|-----------------|---------| +| Mantissa bits | 23 (with sign) | 24 | +| Exponent bits | 8 | 8 | +| Relative precision | ~0.00001% | ~0.000006% | +| Negative values | Possible (invalid) | Not representable | +| Zero handling | Special case | Clean encoding | +| Byte order | Little-endian quirks | Big-endian, clean | + +The Jericho encoding eliminates Bitcoin's historical quirks while providing slightly better precision. + +#### Verification + +Verifying a proof requires re-executing the expansion loop—there is no shortcut. However, verification is deterministic and completes in the same time as mining one attempt. Since valid blocks are rare (one per 10 minutes network-wide), verification cost is negligible compared to mining cost. + +``` +function verify_proof(block_header, nonce, claimed_hash) -> bool: + computed_hash = proof_of_work(block_header, nonce) + return computed_hash == claimed_hash AND computed_hash < difficulty_target +``` + +#### Security Properties + +| Property | Guarantee | +|----------|-----------| +| Progress-free | Each nonce attempt is independent | +| Memory-hard | 128 MB working set required | +| CPU-equivalent | No significant ASIC advantage | +| Deterministic | Same inputs always produce same output | +| Non-reversible | Cannot work backwards from hash to nonce | + ### Token Denomination Tokens are represented as 128-bit unsigned fixed-point integers: @@ -542,6 +885,270 @@ Jericho sacrifices the passive security of capital hostage-taking (Bitcoin's ASI The work-bond identity mechanism ensures that validator creation always costs real resources—computation early, capital later—eliminating both Sybil attacks and privileged genesis distribution. Early and late participants face equivalent barriers in different currencies. +## Collusion Resistance and Protocol Ossification + +The protocol is designed to resist capture by cartels seeking to modify consensus rules, inject arbitrary data, or expand scripting capabilities. These defenses promote eventual ossification—a stable end-state where the protocol becomes immutable. + +### No On-Chain Governance + +Protocol changes cannot be enacted through on-chain voting or stake-weighted governance: + +- **No upgrade mechanism**: The protocol has no built-in facility for rule changes +- **No signaling bits**: Block headers contain no version bits or feature flags +- **No admin keys**: No privileged keys can modify consensus parameters + +Any protocol change requires a hard fork—a new software release that honest nodes must independently choose to adopt. Cartels cannot use captured trust weight or bonded capital to amend rules; they can only propose forks that the network may reject. + +### Minimal Transaction Format + +Transactions follow a fixed schema with no extension points: + +``` +transaction = { + version: 1 (fixed, no upgrade path) + inputs: [input, ...] + outputs: [output, ...] + lock_time: absolute block height or timestamp + witnesses: [witness, ...] +} + +input = { + prev_tx: transaction hash + prev_index: output index + sequence: relative timelock (if enabled) +} + +output = { + amount: token amount (128-bit fixed-point) + script: locking script (restricted grammar) +} + +witness = { + signatures: [signature, ...] + preimages: [hash preimage, ...] (for HTLCs) +} +``` + +**No arbitrary data fields**: There is no OP_RETURN equivalent, no memo field, no metadata extension. Every byte must conform to the transaction schema. + +### Restricted Script Grammar + +Locking scripts use a minimal, non-Turing-complete grammar supporting only payment operations: + +``` +script := pubkey_lock + | multisig_lock + | timelock_wrapper(script) + | hashlock_wrapper(script) + +pubkey_lock := CHECK_SIG(pubkey) +multisig_lock := CHECK_MULTISIG(threshold, [pubkey, ...]) +timelock_wrapper := IF block_height >= N THEN script +hashlock_wrapper := IF SHA256(witness) == hash THEN script +``` + +**Supported operations (exhaustive list):** + +| Operation | Function | +|-----------|----------| +| CHECK_SIG | Verify single signature against pubkey | +| CHECK_MULTISIG | Verify n-of-m signatures | +| CHECK_TIMELOCK_ABS | Require minimum block height | +| CHECK_TIMELOCK_REL | Require minimum blocks since input confirmed | +| CHECK_HASHLOCK | Require preimage of specified hash | + +**Explicitly excluded:** + +- Loops or recursion +- Arithmetic beyond comparison +- String manipulation +- External data references (oracles) +- Dynamic script generation +- Stack manipulation beyond witness consumption + +This grammar supports all necessary payment patterns: +- Simple transfers (single signature) +- Joint custody (multisig) +- Vesting/escrow (timelocks) +- Atomic swaps and HTLCs (hashlocks) +- State channel operations (multisig + timelocks + hashlocks) + +Complex smart contracts are not possible and cannot be added without a hard fork that redefines the script grammar. + +### Content-Addressed Block Structure + +Every byte in a block is accounted for: + +``` +block = { + header: block_header + transactions: [transaction, ...] +} + +block_header = { + version: 1 (fixed) + prev_block: hash of previous block header + merkle_root: merkle root of transaction hashes + timestamp: unix timestamp + difficulty: current difficulty target + nonce: proof of work nonce +} + +Validity requires: + merkle_root == compute_merkle_root(transactions) + + No additional space exists outside header + merkle-committed transactions +``` + +Miners cannot include arbitrary data without either: +1. Creating invalid transactions (rejected by all nodes) +2. Wasting transaction outputs (economically costly, limited by restricted script) + +### Strict Standardness Rules + +Nodes enforce standardness at the mempool level, not just block validity: + +``` +standardness_rules = { + // Transaction structure + max_transaction_size: 100 KB + max_inputs: 1000 + max_outputs: 1000 + + // Script restrictions + max_script_size: 520 bytes + max_multisig_keys: 20 + max_timelock_height: 500,000,000 (far future) + + // Witness restrictions + max_signature_size: 73 bytes (DER + sighash) + max_preimage_size: 32 bytes + + // Economic minimums + min_output_amount: 1 token (prevents dust) + min_fee_rate: 1 token per KB +} +``` + +Non-standard transactions: +- Are not relayed between nodes +- Are not included in mempools +- May be valid if mined, but miners have no way to receive them + +Even a cartel-controlled miner cannot populate blocks with non-standard transactions because they cannot propagate through the network. + +### Economic Deterrents + +Block space is scarce and fee-driven: + +``` +data_storage_cost = size × fee_rate × (1 / utility) + +For a 1 KB arbitrary data payload at mature network: + - Competes with ~3 actual payment transactions + - Pays same fee as those transactions + - Provides no utility (cannot be spent or referenced) + - Must be wrapped in valid transaction structure (overhead) +``` + +The restricted script grammar means "data storage" outputs are unspendable, permanently consuming UTXO set space. Rational miners prefer fee-paying transactions that will eventually be spent. + +### Trust Attestation Decay + +Cartel formation requires accumulating trust weight, but attestation effectiveness decays: + +``` +Cartel accumulation timeline: + Week 0: Cartel begins acquiring identities + Week 12: First identity completes work-bond + Week 12+: Cartel members must continuously bond to maintain weight + + If cartel stops bonding to coordinate attack: + activity_factor drops + attestation_weight of cartel members decays + honest validators' relative weight increases +``` + +Cartels cannot accumulate dormant power. Trust weight requires ongoing capital commitment, creating continuous cost for maintaining attack capability. + +### Identity Cost Barrier + +Capturing 33% of network trust requires: + +``` +At N honest validators with average mass M: + cartel_identities_needed = N × 0.5 (to reach 33% of total) + cartel_cost = cartel_identities_needed × identity_cost + + identity_cost = ~12 weeks CPU OR equivalent token bond + +Example with 1000 honest validators: + Need ~500 cartel identities + Cost: 6000 weeks CPU time (~115 years single-threaded) + OR 500 × token_bond +``` + +The identity cost creates a slow, expensive barrier. Cartels cannot rapidly acquire influence; they must either: +- Spend years computing identity proofs +- Acquire massive token holdings (visible, market-moving) + +Both approaches are detectable long before reaching capture threshold. + +### Ossification Path + +The protocol is designed to reach a stable end-state: + +| Component | Ossification Trigger | Final State | +|-----------|---------------------|-------------| +| Block size | Approaches 8 MB terminal | Fixed at 2^23 bytes | +| Emission | Approaches zero | No new issuance | +| Script grammar | Already minimal | No expansion possible | +| Transaction format | Already fixed | No versioning | +| Difficulty adjustment | Continues indefinitely | Self-regulating | + +**Post-ossification operation:** + +Once the network reaches sufficient channel density and emission becomes negligible: + +1. **Base layer**: Processes only channel opens, closes, and disputes +2. **Fee market**: Validators compensated entirely by transaction fees +3. **State channels**: Handle all regular payment volume off-chain +4. **Protocol changes**: Effectively impossible (no governance, no upgrade path) + +The protocol becomes a minimal, stable settlement layer—resistant to feature creep, regulatory capture, and cartel manipulation. + +### Soft Fork Resistance + +Even "soft" forks (tightening rules) face resistance: + +``` +soft_fork_attempt: + 1. Cartel tightens rules in their blocks + 2. Honest nodes accept these blocks (valid under old rules) + 3. But honest miners produce blocks cartel rejects + 4. Network splits along cartel/honest boundary + 5. Cartel must maintain >50% hash power indefinitely + 6. Any lapse allows honest chain to overtake +``` + +Without a coordination mechanism (upgrade signaling, governance), even soft forks require permanent majority control—economically unsustainable. + +### Collusion Detection + +The trust attestation system includes collusion detection: + +``` +cluster_penalty(C) = 1 - (internal_edges(C) / (internal_edges(C) + external_edges(C)))^2 +``` + +Highly interconnected groups with few external attestations receive reduced weight. This makes cartel formation visible and penalized: + +- Cartels naturally attest heavily to each other (coordination requirement) +- External attestations require trust from honest validators (who won't attest to suspicious clusters) +- Cluster penalty reduces cartel's effective trust weight + +Cartels face a dilemma: tight coordination (detectable, penalized) or loose coordination (ineffective). + ## Triangular State Channels Jericho implements off-chain payment channels using hash time-locked contracts (HTLCs) with a three-party triangular geometry that improves routing efficiency over traditional two-party channels.