Chronicle is a general-purpose proof-of-cost protocol with persistent public memory. Somewhat like Hashcash that remembers who spent what cost and where.
Hashcash prevents spam and denial-of-service attacks by essentially slowing everyone down, which also makes for a poor user experience and is the main reason it’s not adopted more widely.
Can we design a system where legitimate users experience less friction than the attackers?
When we walk into a store, we don’t have to prove cost before entering. We put our credibility on the line instead. If we smash up the store, there will be consequences: legal, financial, potentially even physical. We might be prevented from walking into that store in the future and potentially any other store.
Civilization makes things frictionless for credible people and imposes friction on those that do harm. Proof-of-work methods like Hashcash impose friction on legitimate users and attackers alike, because they don’t recognize credibility.
Civilization recognizes credibility because it remembers prior actions. Hashcash doesn’t remember prior actions. It always asks the same question regardless of the context: “Show me that you’ve put this much cost on the line.” If Hashcash remembered previous actions, servers could ask a second question: “Show me that you have this much credibility at stake.” Since proving credibility comes down to proving the ownership of a public key, it doesn’t require recurring costs with every access. It’s also very fast.
In Chronicle a user backs their public key with some amount of Bitcoin, say 10k sats. A server can use that data point when deciding whether to give the pubkey access or not. In the happy path the pubkey gains access and leaves without doing damage. However, if the pubkey gains access and spams the server, the server can publish a second data point: a counter signal that associates say 100 sats with the pubkey. Other servers can use that second data point to deny access to the pubkey or raise the barrier. This means that the pubkey has essentially lost its original 10k sats. It can start from scratch using a new pubkey or commit more Bitcoin to the existing one, and repeat the process. Spam is still possible, but it becomes expensive.
This is the basic idea for how to impose friction on the attackers while allowing credible users frictionless passage through cyberspace. Don’t treat all users on equal ground. Keep a track record of costly signals attached to a pubkey, then gate access by credibility.
Chronicle goes much further than DoS prevention. A server deciding whether to interact with the client is only a special case of a broader principle. The same logic can be applied to other kinds of online interaction: whether to open an email from an unknown sender, answer a call from an unknown number, enter payment details on an unknown domain, read a social media comment from an account one doesn’t follow. These all boil down to the same decision-making process: does the other person have enough credibility on the line to justify a trustworthy interaction?
In Chronicle a person can verify their email address, phone number, domain name, and other digital subjects with their pubkey. These are the vehicles through which the person acts in cyberspace. Email clients, smartphones, and web browsers don’t have a principled way of judging one vehicle from another, and so spam and scams are to some degree unavoidable. Once a Chronicle pubkey is attached to these entities, however, these clients can — like the server — decide who and what to interact with based on the credibility the pubkey has on the line.
At the heart of Chronicle is a cost-bearing event that specifies the kind of action a user wishes to perform (like backing a pubkey, domain, or email address) and the amount of Bitcoin the user wants to attach to this action. This Bitcoin is eventually burned through the process described below, which proves the user gave up irreversible cost for performing this action.
This is how the event format looks on the wire (for more detail see CIP-01):
[kind, subject, amount, pubkey, created_at, sig]Clients publish these events to the Chronicle node they’ve opened an account with. An account can be opened by topping up money via Lightning, Bitcoin or any payment method accepted by the node operator. An intermediary service can be used to top up an account for a specific pubkey or even to forward a client’s events. The protocol is designed so the average user doesn’t need to own Bitcoin or even interface with a Chronicle node directly.
A Chronicle node debits the user’s account by the amount specified in the event, immediately broadcasts it to other clients that are subscribed, and accepts the responsibility for anchoring its cost to the Bitcoin chain later. This is how the network operates in real-time despite the 10-minute block times.
The node batches many events together and burns the total amount of Bitcoin in a verifiable Bitcoin transaction. The batch’s Merkle tree root is placed into the OP_RETURN field and the transaction has to burn a sufficient amount of Bitcoin to cover the cost of all the events. The events aren’t stored on the chain. Bitcoin is used only for anchoring cost.
After anchoring, the node publishes the batch of events, which the clients can then verify. The published batches are the node’s proof of operational history.
CIP-01 defines the protocol for clients and nodes.
The registry includes specs for individual actions like: chronicle:pubkey, web:domain, email:address, nostr:event.
The whitepaper outlines the broader technical landscape, the incentives and the recursive reputation model for computing credibility from the record of events.
This protocol is still under research & development. Ready for small-scale experimentation, but not ready for wider deployment. The registry specs show the current shape of the project, but shouldn’t be considered final.
There is a prototype implementation, mathematical models, and a recursive reputation algorithm. See the essays for research published to date.
This project needs funding. Chronicle is open source, but developing the protocol properly will require sustained R&D across protocol design, mathematics, software, and real-world experimentation. For funding, introductions, or collaboration, please reach out: team@chronicle-network.org.
- Mathematical model: https://cartographersguild.substack.com/p/geometry-of-action
- Cyberdefense: https://bitcoinfixesthis.substack.com/p/how-bitcoin-fixes-ai-threats
- Trust: https://bitcoinfixesthis.substack.com/p/how-bitcoin-fixes-trust
CC0-1.0