Billots: The Cryptocurrency That Treats Money Like Cash Instead of a Ledger

Hook

What if preventing double-spending didn't require a blockchain, mining, or global consensus—just a network of servers that agree on who owns what right now?

Context

Bitcoin's blockchain was invented to solve one fundamental problem: preventing double-spending in a trustless network. The solution—a globally replicated, append-only ledger verified through proof-of-work—came with massive computational overhead, storage requirements, and transaction latency. Every full node stores the entire transaction history, miners burn electricity to secure the network, and users wait for block confirmations.

Billots asks a provocative question: what if we modeled digital currency like physical cash instead? A dollar bill has a serial number, a fixed denomination, and can only be in one person's possession at a time. You don't need to know the bill's entire ownership history—just who currently holds it. This mental model led Billy Chasen to create Billots, a cryptocurrency that replaces blockchain's global consensus with a simpler architecture: unique coin identifiers, server-maintained ownership tables, and client-side trust decisions. It's an experiment in minimalism that reveals exactly why Bitcoin's complexity exists.

Technical Insight

Billots' architecture centers on individual coins called 'billots', each with a unique identifier and fixed denomination determined by its prefix. A billot starting with 'B1' is worth 1 unit, 'B10' is worth 10 units, and so on—mimicking how physical currencies have different denominations. The server infrastructure is remarkably simple: each server runs a LevelDB instance mapping billot IDs to owner hashes (SHA-512 of public keys).

Here's how ownership transfer works in practice:

# Client generates RSA key pair
from Crypto.PublicKey import RSA
from Crypto.Signature import PKCS1_v1_5
from Crypto.Hash import SHA512
import base64

# Create transaction to transfer billot ownership
def transfer_billot(billot_id, private_key, new_owner_pubkey):
    # Hash the new owner's public key
    new_owner_hash = SHA512.new(new_owner_pubkey.encode()).hexdigest()
    
    # Create message: billot_id + new_owner_hash
    message = f"{billot_id}:{new_owner_hash}"
    
    # Sign with current owner's private key
    key = RSA.importKey(private_key)
    h = SHA512.new(message.encode())
    signer = PKCS1_v1_5.new(key)
    signature = base64.b64encode(signer.sign(h))
    
    # Broadcast to trusted servers
    transaction = {
        'billot_id': billot_id,
        'new_owner': new_owner_hash,
        'signature': signature
    }
    
    return transaction

When servers receive this transaction, they verify the signature against the current owner's public key hash stored in their database. If valid, they update the ownership record atomically. There's no transaction history, no merkle trees, no consensus algorithm—just a key-value update.

The genius and fatal flaw both lie in the same mechanism: double-spend prevention through coin invalidation. If a malicious user broadcasts conflicting transactions (attempting to send the same billot to two different recipients), servers detect the conflict and mark that billot as permanently invalid. The coin is destroyed rather than awarded to either party. This is economically rational in theory—no one profits from cheating—but catastrophic in practice. Network delays, accidental re-broadcasts, or griefing attacks can destroy coins, creating deflationary pressure.

Clients verify transactions by polling multiple servers from their 'trusted server list'—a manually curated set of endpoints they believe to be honest. If 80% of queried servers agree on ownership, the client considers the transaction valid. This shifts the entire security model from cryptographic proof-of-work to social proof-of-trust:

# Client verifies billot ownership
def verify_ownership(billot_id, expected_owner_hash, trusted_servers):
    confirmations = 0
    
    for server in trusted_servers:
        response = requests.get(f"{server}/billot/{billot_id}")
        if response.json()['owner_hash'] == expected_owner_hash:
            confirmations += 1
    
    # Require 80% consensus from trusted servers
    threshold = len(trusted_servers) * 0.8
    return confirmations >= threshold

The fixed-denomination design creates another interesting challenge: making exact-value payments. If you want to buy something worth 47 billots but only have denominations of 50, 20, and 10, you need a 'change server'—essentially a bank that exchanges your large-denomination billots for smaller ones. This reintroduces centralization and trust dependencies that the system aimed to eliminate.

Storage requirements are impressively minimal. With just current ownership state and no transaction history, a server can handle millions of billots in under 100MB. Transaction finality happens in seconds—as fast as HTTP requests complete—versus Bitcoin's 10-minute block times. For closed systems where all participants know and trust specific servers, this performance is compelling.

Gotcha

The trusted server model collapses under adversarial conditions. Unlike Bitcoin, where attacking the network requires 51% of global hash power (an expensive, observable threshold), attacking Billots requires controlling a majority of servers in a single user's trust list. An attacker can trivially create hundreds of Sybil nodes, and if a naive user adds these to their trusted servers list, they've handed over complete control. There's no network-wide consensus to protect them—each user independently decides their security model, and most users will choose poorly.

The coin invalidation mechanism turns every network hiccup into potential money destruction. Imagine a merchant's server is briefly unreachable, so a customer's transaction times out and they retry—accidentally broadcasting a double-spend that invalidates the billot. Or a malicious actor systematically attempts double-spends on low-value billots to grief the network, reducing money supply. The system treats money as expendable rather than sacred, which might work for game tokens but is unacceptable for real currency. Additionally, the change-server requirement for exact payments creates centralization chokepoints and transaction friction that defeats the purpose of a decentralized system.

Verdict

Use if: You're building a closed-loop token system for a gaming environment, corporate rewards program, or educational blockchain alternative where all participants are semi-trusted and you control the server infrastructure. The simplicity and transaction speed are genuine advantages when security threats are minimal. It's also valuable for learning—implementing Billots from scratch teaches you exactly which problems blockchain's complexity solves.

Skip if: You need actual cryptocurrency functionality, adversarial resistance, or decentralization guarantees. The trusted-server model is fundamentally incompatible with trustless networks. The coin invalidation mechanism creates unacceptable money destruction risk. For production use, choose Bitcoin/Ethereum for true decentralization, Nano for fast feeless transactions with better security, or Stellar for federated consensus with mature tooling. Billots is an academic curiosity that highlights why we can't have nice things—the blockchain's overhead isn't bureaucratic bloat, it's the minimum viable cost of trustless money.