Bulletproofs: Zero-Knowledge Range Proofs

What Problem Do Bulletproofs Solve?

The Challenge:

DERO needs to verify:
  ✓ Amount is positive (not negative)
  ✓ Amount is reasonable (not 999 trillion)
  ✓ Sender has enough balance
  
But WITHOUT revealing:
  ✗ The actual amount
  ✗ The sender's balance
  ✗ Any private information

The Solution: Bulletproofs

• ✅ Prove combined 128-bit value is valid (transfer + remaining balance, each 64-bit)
• ✅ Never reveal the amount value
• ✅ Logarithmic-size proof (7 rounds for 128-bit range)
• ✅ No trusted setup needed

How It Works (Simple Analogy)

The Bouncer Problem:

You: "I'm 25 years old"
Bouncer: "Show me your ID"

Bouncer learns:
  ✓ You're over 21
  ✗ Your exact age (25)
  ✗ Your address
  ✗ Your full name
  ✗ Your photo
  ✗ Everything else on ID

Privacy: ❌ Zero

For DERO:

• Bulletproof proves: "Combined 128-bit value is valid (transfer amount in lower 64 bits, remaining balance in upper 64 bits)"
• Network learns: ✅ Both values are valid (in [0, 2^64))
• Network learns: ❌ What either value actually is

The Proof Flow

What Network Sees:

• ✅ Commitment (encrypted amount)
• ✅ Bulletproof (logarithmic-size proof)
• ✅ Proof is valid
• ❌ Actual amount (hidden)

Protection Against Negative Transfers

Three-Layer Defense

DERO uses three cryptographic layers to prevent negative transfers:

Layer 1: Bit Decomposition Protection

What Happens with Negative Values:

From Source Code (cryptography/crypto/proof_generate.go:473-487):

// Bit decomposition process
number_string := reverse("0000...000" + number.Text(2))
 
// For negative values:
// Go's BigInt.Text(2) returns "-1100100" (with minus sign)
// Bit loop expects only '0' or '1' characters
// Minus sign ('-', ASCII 45) is invalid
// Proof generation fails → Transaction rejected

Technical Guarantee:

• Go's BigInt.Text(2) always returns "-[binary]" for negatives
• This is standard library behavior (cannot be bypassed)
• Bit processing loop expects only '0' (48) or '1' (49)
• Minus sign '-' (45) breaks the proof generation

Layer 2: Range Proof (A_t)

What A_t Validates:

DERO constructs a combined 128-bit value where the lower 64 bits represent the transfer amount and the upper 64 bits represent the remaining balance. This is created by: value = transfer_amount + (remaining_balance << 64).

A_t Range Proof checks:
  ✓ Combined 128-bit value is valid
  ✓ Transfer amount (lower 64 bits) is in range [0, 2^64)
  ✓ Remaining balance (upper 64 bits) is in range [0, 2^64)
  ✓ All 128 bit commitments are valid (0 or 1)

If Layer 1 fails (has - character):

• Bit commitments cannot be created
• A_t proof generation fails
• Transaction rejected

Source: cryptography/crypto/proof_generate.go:471 - Combined value construction: btransfer.Add(btransfer, bdiff.Lsh(bdiff, 64))

Layer 3: Inner Product Proof - The Cryptographic Fail-Safe

Layer 3 is the cryptographic fail-safe that ensures complete integrity across all proof components. Using a recursive halving algorithm, it creates cryptographic commitments at each step, making it mathematically impossible to have invalid bit vectors or any form of manipulation.

What It Validates:

Inner Product Proof cryptographically verifies:
  ✓ Bit commitments match amount commitment
  ✓ Mathematical consistency across all components
  ✓ No manipulation possible at any level
  ✓ Integrity of entire proof structure

From Source Code (cryptography/crypto/proof_innerproduct.go):

// Inner product proof verifies:
// - Bit vectors (aL, aR) match commitments
// - Final inner product equals committed value
// - All recursive steps are cryptographically consistent
 
// If ANY layer fails:
if P_calculated.String() != P.String() {
    // Verification fails
    // Transaction rejected
}

The Fail-Safe Guarantee:

Even if Layers 1 and 2 were somehow bypassed (mathematically impossible), Layer 3 would still reject the transaction because invalid bit vectors create inconsistent inner products, and the recursive structure cryptographically binds all components. The final verification checks mathematical consistency - any corruption is detected and rejected.

The Six Sigma Proofs

DERO uses six interconnected proofs that all must pass:

All Bound Together:

Challenge hash (c) = hash(A_y || A_D || A_b || A_X || A_t || A_u || ...)

If ANY proof fails:
  → Challenge hash is different
  → Verification fails
  → Transaction rejected

Source: cryptography/crypto/proof_verify.go - Verifies all six sigma proofs + inner product

Inner Product Proof (The Core Algorithm)

Recursive Halving - How Logarithmic Scaling Works

The Algorithm:

Iterations:

• Start: 128 elements
• Iteration 1: 64 elements
• Iteration 2: 32 elements
• Iteration 3: 16 elements
• Iteration 4: 8 elements
• Iteration 5: 4 elements
• Iteration 6: 2 elements
• Iteration 7: 1 element

Total: log₂(128) = 7 iterations

Source: cryptography/crypto/proof_innerproduct.go - Recursive halving algorithm

Zero-Knowledge Property Explained

What "Zero-Knowledge" Means

After seeing a valid bulletproof, verifier learns:

Formal Properties:

• ✅ Completeness: Valid proofs always verify
• ✅ Soundness: Invalid proofs never verify
• ✅ Zero-knowledge: No information leaked

Where Bulletproofs Are Used

Three Core Applications:

All three use the same bulletproof mechanism:

• ✅ Prove value is in valid range
• ✅ Never reveal the actual value
• ✅ Cryptographic guarantee

Key Takeaways

What You Get

What You're Protected From

The Bottom Line:

Related Pages

Privacy Suite:

• Ring Signatures - Sender anonymity
• Homomorphic Encryption - Amount encryption
• Transaction Privacy - Complete privacy model

Technical Details:

• DERO Tokens - How bulletproofs secure token balances
• Transaction Structure - Bulletproof integration

Learn More:

• Privacy Features Overview - Full privacy suite
• Private Smart Contracts - Contract privacy