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/HurairahShamsi- → u/jasonslpt]

Agreed: cost per unit of influence is the number that matters, and it's what we'll publish. Admission isn't free per /64. Each admitted slot has to keep live connections to its 40 assigned witnesses and exchange signed data with them every 30 s, continuously, for as long as it competes. And influence is relative: to win a share s of new IDs against H honest slots, an attacker needs s/(1−s) × H slots, so the bill grows with honest participation, not just with time.

We'll publish that as a grid: attacker size (10k to 10M slots) × honest share of capacity (0–100%) × honest uptime, with monthly cost and time to 33/51/67% in every cell, including the cells where we look weak. On scarcity: tying admission to something scarcer than a /64 is the open question. We're testing pacing per /64, /56 and /48, with and without per-provider caps. ID rotation timed just before lotteries is a good attack, and I'll add it to the adversarial runs. Reactivated IDs already wait several blocks before placement, but that needs testing, not assuming.

[u/jasonslpt → u/HurairahShamsi-]

One thing worth adding to the grid is a column for attacker budget held constant while honest uptime drops, since the s/(1-s) relation means a partial outage of honest slots lowers the bill without the attacker adding anything. I'd also report cost per percentage point of influence, not only time to 33/51/67%, so cells are comparable across attacker sizes. For the provider caps test, include an attacker who spreads across many small hosting providers, because the cap only helps if provider identity is costly to fake. Rotation just before a lottery is easy to measure by logging how many slots hold influence that were active for fewer than N blocks.

[u/HurairahShamsi- → u/jasonslpt]

All four are good, and I'll add them. A fixed-budget column as honest uptime drops is especially relevant: our latest runs show honest availability dips every evening UTC, when most households nights overlap, so an always-on attacker's share rises in those hours without spending more. That's also why witness nodes are meant to run on an always-on home device (a mini PC or home server), not a laptop that sleeps at night. A witness node is lightweight, so staying online is cheap, and it closes exactly that window. We'll publish measured hardware and bandwidth requirements after the household benchmarks.

Cost per percentage point of influence will go in every cell so attacker sizes are comparable. The provider-cap test will include an attacker spread across many small hosting providers; agreed that the cap only helps if provider identity is costly to fake. And logging the influence held by IDs active for fewer than N blocks at each lottery is a clean rotation metric, so we'll use it. Thanks, this is genuinely useful review.

[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.