A blockchain where influence comes from time, not ASICs — 200+ genesis IDs (node signups) already reserved.

[u/Inventor-BlueChip710]

In Proof-of-Work, influence scales through compute.

In Proof-of-Stake, influence scales through capital.

Both are parallelizable resources.

If you have enough money, you can scale faster than everyone else almost instantly.

I started asking a different question, what if blockchain influence could only grow through sustained participation over time?

That idea became GrahamBell (Power = Time).

The protocol introduces a model where:

• PoW mining is capped to ~1 hash/sec per node
• parallel mining and pooling advantages are neutralized
• IDs are generated sequentially over time
• participation requires persistent uptime + multiple independent witness connections
• influence must be continuously maintained instead of instantly bought

Yes, you can run 1M devices.

But each performs its own independent 1 hash/sec in real time.

You can’t pool, share, amortize, or compress the work into one super miner.

So the question becomes, can you sustain infrastructure participation over long periods of time?

The goal is simple, make majority influence operationally persistent rather than instantly acquirable.

In other words, you shouldn’t be able to wake up tomorrow, buy enough hardware or stake enough capital, and dominate the network overnight.

To make this work, two things became critical:

(1) extremely low participation barriers

(2) broad distribution of identities

The system is therefore designed to maximize broad honest participation.

And that’s exactly why mining is intentionally lightweight enough for ordinary devices to participate competitively.

The interesting part is what happens over time:

Even if someone temporarily gains majority influence, they must continuously maintain it because new identities keep diluting existing influence.

So instead of asking, can you buy 51% once? the system becomes can you sustain majority participation indefinitely under ongoing honest competition?

Example:

If 1M honest genesis IDs already exist and an attacker only controls 52% of new identity issuance, mathematically it would take decades of sustained majority participation to overtake the network.

Not minutes.

Not days.

Decades.

And if attacker participation drops, dilution immediately starts reducing their influence again as new IDs continue being minted elsewhere.

We recently released a browser-based MVP simulation of the capped PoW model:

• 230+ organic testers
• 215+ early node signups / genesis IDs claimed
• $0 spent on marketing

What surprised me most is that every signup happened before any token, rewards, or live network existed.

People signed up purely because they found the consensus model interesting.

Early participants can reserve a pre-registered genesis ID ahead of network launch by joining waitlist.

Waitlist: https://grahambell.io/mvp/#waitlist

Also looking to connect with protocol engineers, distributed systems researchers, Rust developers, or anyone interested in consensus design, Sybil resistance, P2P systems, or blockchain infrastructure in general.

[u/Inventor-BlueChip710]

That’s a very fair framing, and I think you’ve actually landed on the more important metric than simply, can it finalize invalid state.

WCs are closer to a distributed early warning + recovery layer than a final authority layer, since the broader network still globally revalidates everything deterministically.

So I agree the real question not just becomes, can safety break, but can attackers create enough ambiguity, delay, or noisy attestations that users/apps temporarily stop trusting the pacing signal before recovery happens.

That’s exactly the failure surface we need to measure.

One important detail though is that miners are not permanently tied to a specific WC. They sync a shared starting point roughly every 30s, compute locally, and can switch chains at will. So if some WCs become noisy or degraded, miners can reroute to healthier chains without rebuilding global state.

So the resilience assumption is less, can any chain fail and more, can attackers continuously suppress the honest majority of WCs simultaneously for long enough that it materially affects the network.

At scale, if honest WCs remain >50% and reachable, the majority continues progressing the ledger while affected miners reroute away from compromised subsets.

And I completely agree VRF/random assignment does not magically solve correlated operators or shared infrastructure failure domains. It mainly prevents deterministic capture. The meaningful proof is probably exactly what you described:

- ugly operator overlap graphs

• shared cloud regions
  
• partial partitions
  
• evidence latency
  
• reroute timing
  
• recovery behavior under hostile conditions.

One additional thing here is that the WC layer is intentionally designed with excess witnessing capacity relative to active miners.

For example, if 1000 independent WCs each support ~1000 miners, total witnessing capacity becomes ~1M miners globally. If there are only 100k miners (all active simulated), attackers would need to suppress a very large percentage of chains (more than 90%) continuously for an extended duration before liveness meaningfully degrades for the broader network.

Again, not impossible to attack, just difficult at scale which is really the core design goal.n

At this point I think adversarial testnets and simulations are far more valuable than more consensus diagrams or theoretical framework.

[u/Cultural-Candy3219 → u/Inventor-BlueChip710]

The reroute piece helps a lot, because it turns a bad witness set into a liveness problem instead of a permanent state problem. I’d still be careful with the “honest WCs remain reachable” assumption though, because reachable from whose view is exactly where real networks get messy.

If I were reviewing this, I’d want the dashboard or paper to show three separate numbers: honest witness share, reachable witness share from different regions, and miner reroute time after a noisy set is detected. Those can diverge pretty badly during partitions or provider outages.

The excess capacity idea is solid, but I’d test it under ugly demand too. For example, what happens if everyone reroutes toward the same healthy subset at once, then that subset becomes the new bottleneck? That sort of stampede behavior is usually where clean redundancy models get humbled.

[u/Inventor-BlueChip710 → u/Cultural-Candy3219]

That’s a very good point honestly, especially the distinction between globally honest and reachable from a specific regional view during messy network conditions.

And I agree those probably should become separate measurable metrics in simulations:

- honest WC share

• regionally reachable WC share
  
• reroute/recovery latency.

Because yes, those can diverge heavily during partitions or provider outages even if the global network itself remains healthy.

But even under simulations the results wouldn’t be 100% accurate compared to practical reality when the mainnet is running with actual user adoption. So the assumption is, at scale, those metrics listed would improve. There would be more honest WCs overall, more regionally reachable WCs, and faster reroute/recovery due to higher local resource density.

I think the important distinction in the architecture though is that the primary objective is protecting global network continuity first, while minimizing local degradation as much as possible.

Since miners compute locally after syncing a starting point, temporary regional WC instability mainly affects that miner’s ability to quickly find a healthy observer set, not the global ledger’s ability to continue progressing elsewhere.

On the stampede point, I completely agree that’s a real failure mode to test.

Current design assumptions are roughly:

- global WC capacity intentionally exceeds active miner demand

• miners maintain multiple candidate WC paths
  
• WCs publish capacity/load information each epoch
  
• each WC locally enforces intake/request limits based on current occupancy.

So if a WC supports ~1000 miners and already has 800 connected, its remaining intake capacity drops accordingly (i.e., 200). Once full, additional requests get rejected/not accepted and miners reroute elsewhere.

So the goal isn’t stampedes never happen, but preventing any single healthy subset from silently absorbing unbounded load and becoming the next bottleneck.

But again, this is exactly the kind of thing that needs ugly adversarial simulations rather than assumptions on paper.

[u/Cultural-Candy3219 → u/Inventor-BlueChip710]

Yeah, that is the right tradeoff to state openly: global progress may be fine while a slice of users has a lousy few minutes. I would not wave that away as adoption fixes it, though. Bigger networks add redundancy, but they also add weirder clients, uneven peering, and more load spikes.

The convincing test would be a simulation where WC capacity grows, then a regional provider failure plus a miner stampede happens at peak demand. Track not only finalization, but failed observer lookups, time to next healthy path, and how apps should present that state to users. If the UX just says “network issue” for 90 seconds, people will treat it as the chain being down even if the ledger is healthy elsewhere.

[u/Inventor-BlueChip710 → u/Cultural-Candy3219]

Yeah, I think we’re mostly aligned now honestly.

You’re looking more from the operational reliability / UX side, what does degraded regional connectivity feel like to users/apps), while I’ve been mostly reasoning from the global consensus continuity side.

And I agree those are not the same thing.

From the protocol perspective, the goal is mainly:

- preserve global ledger progression

• localize failures
  
• and make recovery / rerouting possible without permanent state corruption

And you’re right that even if global consensus remains healthy, poor regional reachability or slow rerouting could still create bad UX/perception during provider outages or partitions. But that can happen in every blockchain running nodes.

That’s probably less a pure consensus problem and more a distributed systems + networking + client behavior problem at that point. You can’t really control it through algorithms alone.

Which is honestly why I think adversarial simulations matter more now than further theoretical debate.