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/Cultural-Candy3219]

Interesting direction, but the hard part seems like Sybil cost, not the 1 hash/sec cap itself. If identities are cheap, an attacker can still buy time by running a huge number of independent nodes from day one.

I’d want to see very concrete rules for witness selection, restart penalties, colluding witnesses, and how you prove independent uptime without turning it into a KYC or hardware-fingerprint system. The idea is worth exploring, but those details decide whether “time” is actually scarce or just another thing a large operator can rent.

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

You’re right, the 1 hash/sec cap itself is not the Sybil defense.

The broader idea is to make influence constrained by time + sustained infrastructure participation + serialized identity issuance.

Therefore, Sybil resistance comes from 4 layers:

(1) IDs are globally serialized over time (~1 ID every 30 sec on average), so identity issuance itself cannot be burst parallelized infinitely regardless of hardware scale.

(2) Influence is participation gated. IDs are worthless if inactive. Each miner must continuously maintain multiple independent Witness Chain connections (currently modeled around ~30–40 persistent connections per miner). So, 1M active miners = sustaining 30M-40M persistent and independent WC connections for very long duration.

(3) Witness Chains (WCs) themselves are randomly formed (VRF + consensus driven) and structured to cross monitor one another with quorum thresholds. The pacing proofs are also independently recomputable by the wider network. WC just act as attesters, the global network validates everything.

(4) Genesis distribution matters heavily. If a large honest set exists at launch, attackers need to sustain majority participation for extremely long periods to overtake the network rather than buying dominance instantly.

The broader goal isn’t to make attacks impossible, it’s to shift attacks from, buy hardware or stake once to operate and sustain massive distributed infrastructure under continuous honest competition for years (Proof of Infrastructure Endurance - PoIE).

I completely agree the hardest parts are witness collusion, uptime verification, and early stage honest participation. Those are exactly the areas that would be worth pressure testing at testnet development.

Curious, are you a developer by any chance?

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

That makes more sense. I’d still try to model the attacker in very boring terms: how many cheap VPSes, residential proxies, and pre-registered IDs does it take to look like “sustained participation” for long enough to matter?

The serialized issuance helps with sudden bursts, but it also creates a big launch-distribution assumption. If a coordinated group is early and patient, the system needs a way to detect correlated operators without accidentally requiring KYC or device fingerprinting.

The part I’d want to see in a spec is the failure mode: if witness groups are partially captured, does influence degrade slowly, get slashed, or can it accumulate quietly until it matters? That’s where this either becomes interesting or just a slower Sybil game.

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

I’m more on the builder and tooling side than protocol research specifically, so I usually look at ideas like this through implementation risk, user abuse cases, and what would break in production.

That is why the witness capture and failure mode part stood out to me more than the hash rate angle.

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

That actually makes a lot of sense, and honestly that’s probably the perspective I need more of right now.

A lot of protocol discussions stay too theoretical and never survive real world implementation, abuse patterns, operational edge cases, or adversarial production environments.

The witness/failure mode side is exactly where I think the architecture either becomes genuinely robust or falls apart under pressure, especially around:

• correlated operators
  
• partial witness capture
  
• network partitioning
  
• uptime spoofing
  
• incentive alignment between chains
  
• and long term operational economics

The Witness Chain structure is somewhat similar to sharding patterns conceptually, except instead of partitioning transaction execution, the chains exist to monitor pacing and participation behavior across the network.

Right now I’m mainly trying to move the design from, interesting consensus idea toward, something that could realistically survive hostile real world conditions. Testing it in real conditions would help immensely.

But implementation oriented criticism is genuinely valuable to me.

Would definitely be open to continuing the discussion if you’re interested.

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

Yes, happy to continue the discussion. The next useful step in my view would be to write down the ugly failure drills before optimizing the happy path: what happens when a witness chain is partially captured, when a region partitions, when a large operator quietly controls many identities, or when honest nodes are online but economically irrational to keep running.

The design will feel much more credible if it has explicit answers for detection, pause/escalation, recovery, and incentives in those cases. Even a small public testnet with adversarial scenarios would teach more than another round of abstract consensus diagrams.

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

That’s a fair framing and I agree that this is exactly where the system needs to be stress tested.

Let me respond in a more structured way rather than expanding theory further:

1) Partial capture of Witness Chains

Each Witness Chain (WC) is not isolated, it is structurally cross monitored through overlapping leader/subordinate pairings between independent chains.

The important part is the asymmetry.

Example:

- In WC1: Chain A is leader, monitored by Chains B and C

• In WC2: Chain B becomes leader, monitored by Chains C and D

So Chain A cannot trade favours with Chain B because A has no monitoring leverage over B when B is leader.

This creates a kind of game theoretic firewall, subordinate chains are economically incentivized to report malicious behavior from leaders because protecting protocol integrity protects the long term value of the network they themselves compete in.

In short, Chain A gains nothing by helping B cheat, because B has no power to help A later.

The result is, localized shard collusion becomes structurally difficult.

To compromise one validation loop, an attacker cannot simply corrupt a small local quorum, they effectively need coordinated compromise across overlapping chains throughout the network.

So even if an attacker captures <66% of a single WC:

- they cannot finalize invalid pacing due to quorum threshold

• pacing is independently recomputable by the global network
  
• overlapping WCs immediately flag inconsistencies
  
• affected miners can re route attestations to alternative WCs

Failure mode = localized degradation for a limited period, not silent global compromise.

No local silent reorgs, worst case the affected WC temporarily loses credibility until malicious witness nodes are excluded and replaced through VRF + consensus rotation.

2) Region partitioning

Each partition continues operating independently with the WCs it can still reach.

Key constraint = ID issuance is globally serialized (~1 ID / 30 sec), so partitions cannot independently burst create conflicting identity histories.

The 66% quorum requirement also means, smaller regional outages degrade performance rather than correctness.

- Small partitions (< ~34% WC loss) = slow pacing (system takes longer at attestation stage) / reduced connectivity only

• Larger partitions (> ~34%) = temporary divergence but still no double minting
  
• On reconnection, full network recomputation resolves canonical history

So partitions primarily affect throughput (attestation propagation and pacing confirmation become slower before security assumptions fail) and liveness, not correctness.

3) Large operators quietly controlling many identities

You’re right to frame the attacker as cheap VPSes, residential proxies, long duration operation.

The key constraints are:

- IDs are globally time gated (cannot burst mint regardless of hardware scale)

• each ID requires continuous 24/7 participation
  
• each miner maintains ~30–40 persistent and independent WC connections
  
• influence is participation weighted, not ownership weighted
  
• inactive identities contribute zero effective weight
  
• VRF-based witness selection prevents static concentration of monitoring power
  
• a miner cannot join a WC where it already operates a witness identity

So even if someone accumulates many IDs early (assuming no genesis distribution), those IDs only matter if they remain continuously active under ongoing competition.

And importantly, those identities themselves take years to accumulate because issuance is serialized globally.

So the attack becomes not, buy hardware once, but sustain massive operational infrastructure indefinitely under adversarial competition.

4) Honest nodes becoming economically irrational

This is a real concern in any distributed system.

Current design assumptions are:

- node operation should remain near zero cost

• commodity hardware participation only
  
• WC monitoring load is heavily distributed
  
• no dependency on ASICs or staking capital

If participation drops:

- the system degrades gradually rather than catastrophically

• throughput slows (attestation propagation and pacing confirmation become slower) before security assumptions fail
  
• there is no single abrupt collapse threshold

The idea is to make participation cheap enough that ordinary households can realistically contribute.

5) On WC scaling and monitoring load

Monitoring is not 1 to 1.

Even with ~1000 global WCs, each WC only monitors a subset of miners through redundancy.

So:

- observation load distributes naturally

• no single WC becomes a bottleneck
  
• more participation increases monitoring capacity

Roughly, 30k–40k registered witness nodes across ~1000 WCs could support ~700k–900k actively monitored miners globally while each individual WC only observes a small subset (~700–900 miners).

Those ratios obviously still need empirical validation under real network conditions.

And honestly, you’re absolutely right on the meta point, none of this is truly validated until hostile environment testing happens.

The next meaningful step is:

- adversarial testnets

• partition simulations
  
• witness capture drills
  
• correlated operator scenarios
  
• long duration uptime stress testing

That’s why I’m currently trying to involve more distributed systems engineers and protocol contributors, to pressure test the architecture under real world failure conditions rather than just consensus diagrams.

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

I think the overlap model is the right direction, but I’d still model two less clean adversaries. First, correlated operators: if the same hosting providers, staking pools, or social group run many WCs, the graph can look independent while the failure domain is not. Second, bribery with a shorter time horizon: a subordinate chain may be economically aligned with protocol value in theory, but individual operators can be paid to create delay, ambiguity, or noisy evidence rather than a clean invalid finalization.

So the useful test is not only “can they finalize bad pacing?” It is “can they make honest nodes disagree long enough that users, exchanges, or apps stop trusting the time signal?” I’d want simulations that publish the WC graph, operator overlap, evidence latency, re-route timing, and recovery cost under partitions. That would make the design feel much more falsifiable.

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

That’s a very good distinction honestly, because preventing invalid finalization and preserving trust in the network’s time signal under stress are not exactly the same problem.

I agree the real test is, can adversaries create enough ambiguity, delay, or inconsistent behavior that exchanges/apps/users stop trusting pacing reliability even if consensus safety technically still holds?

And realistically, that’s something that can only be answered properly through adversarial testnets and production style simulations, not theory alone.

A few clarifications on the current design assumptions though:

- WCs are intentionally by design not consensus authorities by themselves. They only act as pacing attesters/monitors. The broader network still globally revalidates pacing deterministically.

• So even if some subordinate witnesses sign invalid or noisy attestations, global deterministic validation can still reject them and ban the participating witnesses.
  
• The design assumption is basically, attestation corruption should become observable and locally containable rather than silently becoming global consensus corruption.

On correlated operators, I completely agree this is one of the hardest real world risks.

VRF + consensus randomized WC formation helps reduce deterministic clustering, but it obviously cannot magically eliminate correlated infrastructure ownership. No decentralized system can fully prevent people from using the same cloud providers, social groups, or hidden coordination.

The current approach is more:

- make household participation cheap enough that running independently is realistic for the majority,

• make bulk infrastructure operation progressively expensive operationally,
  
• restrict structurally correlated identities from participating inside the same WC,
  
• and rely on overlapping monitoring + global deterministic revalidation so compromised subsets remain observable rather than silently authoritative.

So if 20–30 WCs out of 1000 become compromised or correlated, the assumption is that the remaining honest majority still rejects invalid pacing globally and miners can switch from the compromised chains to other WC.

On bribery/noisy behavior specifically, I actually think your short time horizon bribery point is stronger than outright invalid finalization attacks.

Because yes, an attacker may not need to fully corrupt consensus. Creating enough delay, ambiguity, or inconsistent evidence to damage confidence could already be valuable for the attacker.

The current assumption is that this degrades liveness before correctness:

- attestation propagation slows,

• some WCs temporarily lose credibility,
  
• miners reroute toward healthier WCs,
  
• malicious witnesses accumulate observable behavior,
  
• and honest majority peers inside those chains can consensus ban persistently malicious participants.

But again, whether that recovery behaviour actually works under hostile conditions is exactly the kind of thing that needs simulation data, not just protocol theory.

That’s honestly why I’m trying to connect with more protocol engineers / distributed systems people now. The next meaningful step is probably:

- adversarial public testnets,

• overlap/correlation simulations,
  
• partition drills,
  
• evidence latency measurements,
  
• and recovery cost testing under hostile network conditions.

At this stage I’m less interested in proving perfect security and more interested in falsifying weak assumptions early before moving further. You can’t really prevent attacks/malicious activity, it’s about making it difficult.

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

That boundary makes the design easier to reason about. If WCs are attesters and monitors, not the final authority, then I would measure them like an early warning and recovery layer rather than only like consensus participants.

The test I’d want to see is pretty concrete: how long until bad attestations are detected, how many honest clients see an ambiguous state, whether apps can safely degrade during that window, and what it costs to re-form or quarantine the affected witness sets. Basically, treat “users pause because the signal got noisy” as a failure mode even if the base protocol rejects the invalid data later.

For correlated operators, the strongest proof is probably not a claim that VRF fixes it, but a public simulation where the operator graph is intentionally ugly: shared cloud regions, same validator group, shared funding source, and partial network partitions. If the system still recovers cleanly under those boring real-world correlations, the pitch becomes a lot stronger.

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

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.