[ANN] GRAHAMBELL — Time = Power - A New Time-Based Sybil Resistance Model

[Hurairah Shamsi]

[ANN] GRAHAMBELL — Time = Power - A New Time-Based Sybil Resistance Model with Capped PoW

In traditional Proof of Work, influence is accumulated using hardware and energy, in Proof of Stake, more capital results in more influence within the network. In both cases money (a resource very few have) can buy power/influence almost instantly, which is why we see power concentrated in the hands of a few in Proof of Work and Proof of Stake algorithms, causing centralisation concerns.

The Marathon Digital case, where its mining pool temporarily filtered certain transactions, is one example of the centralisation and censorship concerns surrounding mining infrastructure. Whenever a solo miner mines a bitcoin block successfully it makes international headlines. In a system designed around decentralisation, this should arguably be ordinary news.

But what if we tied sybil resistance to a resource everyone has which cannot be bought, accelerated, parallelised, manipulated, or compressed?

This is where GrahamBell's Time-based Sybil resistance model comes into play. Influence here only grows through time and infrastructure endurance.

For example:

• Generating 1 ID = 30 seconds + sustaining infrastructure for 30 seconds
• Generating 1,000,000 IDs = roughly 1 year + sustaining infrastructure for that period (assuming no competition).

If 1M honest genesis IDs already exist and an attacker controls 52% of new identity issuance under honest competition, mathematically it would take decades of sustained majority participation to exceed 51% total influence. At 51% of new issuance, the attacker would only asymptotically approach 51% total influence.

And if attacker participation drops, dilution immediately starts reducing their influence again as new IDs continue being minted elsewhere, meaning the attacker would have to constantly grow its infrastructure proportionally to the size of the network to maintain influence.

The protocol also includes a capped PoW model (1 hash attempt per second per node), allowing ordinary devices to compete on equal footing with specialized hardware (i.e., ASICs), increasing mass participation, which helps improve the security and decentralization of the network.

Yes, you can run a million miners in parallel, but parallelism does not accelerate the sequential issuance clock or create shared work. Each additional miner is an independent participant and adds infrastructure and uptime requirements proportionally.


You can check the demo on Capped PoW: https://youtu.be/i5gzzqFXXUk?si=T8gT2e3kx93MLpsH

You can check the browser MVP on Capped PoW: https://grahambell.io/mvp/Proof_of_Witness.html

We're currently giving away Genesis IDs (~225 already claimed purely organically) to help decentralise the network before launch. Genesis IDs effectively grant participation time that would otherwise need to be accumulated after launch. Claiming your ID early therefore gives you a time-based head start. The same ID may require significantly more time to obtain later as competition and network participation increase:

https://grahambell.io/claim-id


Murphy — live today, not a roadmap promise

Murphy is GrahamBell's first real product: a free, browser-based calling app built on reverse billing. Instead of paying to call, you earn Shamsi, GrahamBell's native reward currency, for every second you're actively connected. No install, no wallet setup required. It's free, just open it in your browser and go.

If you claim your Genesis ID using the same email as your Murphy account, you also unlock a real Shamsi earning boost from day one.

Try Murphy: https://murphy.grahambell.io


Links:

Discord (join the community): https://discord.gg/4WMf2vJUcy
Full site: https://grahambell.io
Litepaper: https://grahambell.io/Whitepaper_v0.1_Pakistan.pdf
X: https://x.com/GbellOfficial
YouTube: https://www.youtube.com/@GbellOfficial
Github: https://github.com/HurairahShamsi/grahambell-simulation

If you're interested in funding GrahamBell, contributing as a developer or protocol researcher, operating infrastructure, or helping build the network together, please contact us at info@grahambell.io.

Happy to answer any real questions below.

[Hurairah Shamsi]

(1) Update in reply 5 — I have started working on the simulation to test the system aggressively under real world conditions. If you have tests in mind that you wanna see me perform to test this system, please reply below!

(2) Update in reply 6 — Milestone 1: Im publishing the first results of testing it in the open: an exact mathematical baseline, cross-checked 130 ways and reproducible by anyone.

(3) Update in reply 7 — Milestone 2 results (cryptographic core) and M2.1

(4) Update in reply 8 — Milestone 3: 100,000 simulated miners, real network delays, household outages, and what held, what broke, and what we changed.

[BoozyTalking]

When mainnet?

[Hurairah Shamsi]

When mainnet?

Working on it.

Currently working on testing it in a simulation. Then ill launch a controlled testnet, if you wanna participate claim your ID here: https://grahambell.io/claim-id

Also working on launching murphy on android for now... But you can use the webapp here: https://murphy.grahambell.io

[Hurairah Shamsi]

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.

[Hurairah Shamsi]

Update: Milestone 1 The mathematical baseline for Proof of Infrastructure Endurance (PoIE)

Can time, instead of money, secure a blockchain?

Most blockchains give influence to whoever can spend the most right now: hash power or stake. Im building GrahamBell, a Layer 1 that tests a different idea. New identities are issued at a fixed global rate, one every 30 seconds, no matter how much hardware joins, and each participant is limited to one hash per second. If that holds, control cant be bought quickly. It has to be built up over years.

I call it Proof of Infrastructure Endurance (Proof of Time). Today Im publishing the first results of testing it in the open: an exact mathematical baseline, cross-checked 130 ways and reproducible by anyone.

What holds up:
- An attacker that wins a share of new identities approaches that share and never passes it while honest participants stay online. Winning 30% of new IDs never reaches 51%.
- Even an attacker that wins every new identity needs 2.87 years to reach 51%.

What the math broke, and we fixed:
- A restart exploit worth 150–182× the honest rate is now worth exactly 1×.
- Committee capture odds fell from over 99.9% to about 2 in a million.

Whats still open:
- Honest uptime is part of the security model. Groups of witnesses need members online 81.5–90.75% of the time, depending on the quorum rule.
- An attacker can stall some witness groups by refusing to sign. Thats local and recoverable, and the protocol bans it, but the next stage has to show the ban is enough.
- Everything assumes the rate limit holds. Thats the next thing we test.

Publishing the weak spots alongside the strong ones is deliberate. If the idea is going to fail, Id rather find out now.

Code, results and assumptions (open source, Apache-2.0):
https://github.com/HurairahShamsi/grahambell-simulation

Full write-up:
https://medium.com/@hurairahshamsi/can-time-instead-of-money-secure-a-blockchain-first-results-from-grahambell-630fbae27e60?sharedUserId=hurairahshamsi

[Hurairah Shamsi]

Update: Milestone 2 results (cryptographic core) and M2.1

Milestone 1 (the exact maths) assumed the 1 hash/s/miner cap cannot be gamed. Milestone 2 tests that with real SHA-256 hash chains and real BLS12-381 signatures (min-pk, the Ethereum PoP ciphersuite, via blst).

Pacing, in one paragraph
Each round, the miner's header is locked with entropy E = SHA256(BLS aggregate of the miner's and every online witness's signature over the header ‖ signer bitfield). Attempt n is h(n) = H(h(n-1) ‖ … ‖ t0+n ‖ n ‖ E), with t0 = previous block timestamp + 1 s. The miner can compute the whole chain instantly, but witnesses sign the PoWit only when their own clock reaches t0+N (tolerance δ), validators recompute the chain, reject blocks received before their own timestamp, and accept only the first winning step. Faster hardware means knowing your result sooner, not publishing sooner.

Grinding (best of G tries; speed-up vs an honest miner; 1,000 trials per point)

• Old flow, miner signs last with a non-unique signature: 3.7× (G=4), 14.0× (G=16), 39.0× (G=64)
• Miner chooses which witness subset to aggregate: 3.8×, 14.0×, 40.1×
• Colluding last witness, old flow: 4.0×, 14.7×, 40.7×
• Independent-tries formula for comparison: 3.9×, 14.3×, 40.6×
• Current flow (unique BLS signatures, every online witness signs): 1.012× (95% CI 0.93–1.09)
  

Other results

• Header equivocation (two headers, one key, one height): 500/500 detected, 0 false positives
• Old "sort fields by hex before hashing" rule: every swap of two same-width fields collides; 36 headers share each sorted hash. Replaced by fixed field order (0 collisions)
• Beacon withholding (seat placement / committee lottery): favourable outcome q → q/(1 − s(1 − q)), i.e. ×1.10 at s = 10% of blocks, up to ×1.33 at 25%, costing the withheld block. Committee offset k (1, 3, 6, 12) makes no difference
• Placement grinding: zero leverage (the seat beacon does not exist when the ID is minted)
• Uniform random entropy stand-in is statistically equivalent to real BLS entropy (p ≈ 0.37 on every test), so the M3 simulator can scale without real crypto

Weakness found: online status as a grinding lever
With entropy from every online witness, a colluding witness can sign or withhold after seeing the honest signatures, giving the miner 2 entropies (measured 1.88×), up to 2^c for c colluders. Currently bounded by One Chance (refusal after a second chance is penalised). Fix: threshold BLS entropy, t = ⌈2n/3⌉, where any qualifying subset yields the identical signature. Joint-Feldman DKG prototype (benchmark only, unaudited): 0.30 s / 29 KB per member at n = 30, 0.54 s / 52 KB at 40, 1.2 s / 115 KB at 60, 3.4 s / 322 KB at 100; membership changes ~49×/yr. Leading candidate for M4.

Costs (Intel i5-8257U, one core)
BLS sign 0.42 ms · verify 1.1 ms · SHA-256 chain step 1.08 µs · 40-member entropy verify 5.0 ms. A 3-witness server: ~2 cores at 5k miners, ~4 at 10k, ~12 at 30k (excluding networking).

M2.1: locked before any simulation

• Pass/fail thresholds for H1–H9 fixed in SPEC v0.6, dated 2026-10-09
• Fork choice: longest valid chain → earlier timestamp at equal height → lower block hash at equal timestamp (closes a loophole where the race loser could win ~50% of ties)
• Witness double-signing (PoWits for two blocks of one miner at one height) is equivocation evidence and bannable
• Only the first winning step is valid (now covered by a dedicated test)

277 tests, 35 crypto cross-checks, byte-identical rerun on a second machine (different OS and rustc). Test vectors for any future implementation are in the repo.

Code, results, SPEC and assumptions (Apache-2.0): github.com/HurairahShamsi/grahambell-simulation
Full write-up: Medium

Next: M3, the issuance simulator (network latency, household outages, patient attackers, botnets). Critique welcome, especially on the pacing enforcement and the online-status lever.

[Hurairah Shamsi]

Update: Milestone 3 results (issuance simulator, M3a and M3a.1)

M1 gave the exact maths and M2 tested the cryptography, both in an ideal world. M3 simulates issuance on a realistic network: 1,000 to 100,000 miners, measured latency between 8 regions (RIPE Atlas), packet loss, partitions, clock skew, and household outages correlated by power feeder and ISP. H1–H9 thresholds were locked before M3.

What held

• Validation against M1: 51% of active IDs at block 11,362 vs 11,336 (closed form); long-run share 0.6816 vs 0.6818; tie rate 0.01660 vs 0.01656; seat tails exact. 178 of 210 checks pass, 30 reference-limited, 2 fail (both comparison settings).
• Issuance: 30.23 s mean interval under realistic churn (daily SD 0.87%).
• Block withholding: a 10% withholder's amplification is ~0.15 in every placement tested (~0 with a 10 s PoWit deadline).
• Restart attack: under 0.1 of an honest slot's yield (per-round entropy).
• Difficulty hopping: max gain 1.017 with the default correction, inside H5's 1.02.
• Honest losses: 0% under "unreachable is not refusal"; offline points ladder at n = 24 h costs ≤0.50%/yr in every region (H7 ≤ 1%).

SPEC v0.7 changes

• Start rule (r): steps count from the KWC's attested entropy issue time (removes catch-up under the old parent+1 rule).
• Fork choice: longest chain, then first-seen at equal height, then lower hash.
• Entropy: threshold BLS, t = ⌈2n/3⌉ = 27 of 40; any qualifying subset yields the identical signature (closes the M2 online-set lever).
• Early blocks: re-evaluated when the local clock reaches the timestamp (0 of 101 validators split at σ = 2 s skew, vs 16 under permanent rejection).
• Difficulty: issued-entropy count with a P2 correction bounded at ×1.1. No PoWit deadline by default; 10 s soft stays proposed for M3b.

Simulator bugs found and fixed: region-wide feeders and providers (the cause of M3a's "11-hour stall"), entropy issued below quorum (made stalls look shorter), rounds that ran out of draws, test groups placed in one region, late blocks closing rounds. One limitation documented, not fixed (SIM-25).

Known limits

• ~11 h blackout of a region holding ~38% of witnesses: issuance pause at its start, median ~7.6 min over 100 runs (41% > 10 min, 6% > 30 min, longest 49 min); a second gap > 10 min later in about a third of runs (longest 39 min).
• Correlated outages: 6.1–6.6% of issuance groups below quorum, vs < 1% under M1's independence assumption.
• Regional win share: 0.981 to 1.027 at 100k miners.
• PoWit deadline: the pre-set criteria flipped four times between "none" and "10 s soft"; all readings published.

Reproducibility: seeded runs; an independent rebuild on a different machine reproduced four full-size sections byte for byte.

Code, results, SPEC and assumptions (Apache-2.0): github.com/HurairahShamsi/grahambell-simulation
Brief: M3_PUBLIC_BRIEF.md
Full write-up: Medium
Claim Your ID (reserve an identity before launch and help build the honest genesis base): grahambell.io/claim-id
GrahamBell on X: @GbellOfficial | Discord: discord.gg/BGTYQ6ZSfu

Next: M3b, the attackers (datacenter attackers, sleeper accumulation, ID rotation, within-round difficulty relaxation). Critique welcome, especially on the limits.

Research, not an offering or financial advice. Results may change as testing continues; every change is recorded in the SPEC changelog.