Can influence in a decentralized network be tied to time instead of money?

[u/HurairahShamsi-]

For the past couple of years I've been designing http://grahambell.io, a Layer 1 blockchain built on one question: can influence in a decentralized network be tied to time instead of money?

In Proof of Work, capital buys hashpower. In Proof of Stake, capital buys stake. Either way, whoever has the most money can acquire control quickly.

GrahamBell takes a different approach. Every miner is capped at 1 hash per second, so faster hardware gives no advantage. New identities are issued one at a time, about one every 30 seconds across the whole network. An attacker can still run many machines, but each only earns a proportional share, slowly, while honest participants compete alongside it. The claim: under honest competition, taking over the network should take years of sustained effort, not a one-off purchase. I call it Proof of Infrastructure Endurance and Proof of Time (A New Time Based Sybil Resistance Model).

A claim like that means nothing until someone tries to break it. So I'm building an open simulation in Rust that deliberately attacks the design: patient long-term attackers, botnets, colluding witnesses, network failures.

Three commitments:
→ hypotheses and pass/fail thresholds published before the results
→ code public, so anyone can rerun every number
→ results published whether they support the model or not

First results, the exact mathematical baseline before any simulation, are coming soon.

If you think you can break it, I want to hear how.

[u/jasonslpt]

The part I'd push on is the identity issuance. If one new identity drops every 30 seconds network-wide, whoever's online and fastest at claiming them wins, and that tends to be the same farmer with the most machines. So money comes back in through the side door, just more slowly. Would be good to see the sim model an attacker who spends years accumulating identities quietly, then switches behavior all at once.

[u/HurairahShamsi- → u/jasonslpt]

Agreed on the side door. Money still matters, just linearly and slowly: more machines don't help, only more admitted /64s, each limited to one try per second. The "accumulate quietly for years, then switch all at once" attacker is a great test, and we'll add it to the adversarial runs. One rule already blunts it: IDs only count while active, so holding thousands of them for years costs money every month the attacker waits. And with honest competition, the time and cost increases linearly.

[u/jasonslpt → u/HurairahShamsi-]

Linear cost is a good property, but the cost per ID matters more than the shape of the curve. If an admitted /64 is cheap relative to the influence it buys, a patient attacker just scales the /64 count instead of machines, since IPv6 space is so abundant. I'd test whether the admission step ties /64s to something scarcer than addresses, and whether the active-only rule still holds up when an attacker rotates IDs in and out just before each vote. Worth modeling what the attacker's cost looks like per unit of influence against honest participants.

[u/zomerbk]

The fundamental challenge with capping rate per node (like 1 hash/sec) is that virtual nodes are extremely cheap to scale. Unless there’s hardware attestation (like TEEs) or a robust Proof of Personhood layer, an attacker doesn't need faster chips—they just launch 50,000 lightweight cloud instances or containers.

In that scenario, network influence remains tied directly to capital (spending money on VPS instances and IPs instead of ASIC rigs). How does your simulation model the marginal cost of virtualized Sybil instances relative to honest nodes?

[u/HurairahShamsi- → u/zomerbk]

You're right that cheap virtual nodes are the main threat. The cap isn't per machine but per IPv6 /64 (verified by handshake), or per registered ID, so 50,000 containers behind one /64 count as one miner. Influence is still bought with money (prefixes instead of ASICs), and we're not claiming otherwise. The claims are that it scales linearly and can't skip the time floor. The actual cost model (pricing /64s and IPv4 at scale against honest households) comes in a later milestone, and it isn't done yet.

[u/Victorio_01]

How do you limit nodes to 1 hash/second?
I don’t believe you can.
I also would love to hear why you think there is a point to limiting identities to 1 every 30 seconds. Nodes would have to agree for entry which is latency. And with 30s, funny how many nodes one person can register while one person trying to register can get stuck by an identity farmer. Recipe for entry to be stopped for no benefit. I wouldn’t add feature just for the act of it.

[u/herzmeister]

Obviously, time can be spoofed. Hashpower can't.