[ANN] GRAHAMBELL - Capped PoW Mining to 1 Hash/Sec/Node | No Parallel Mining

[zee47]

Yes you did. Your interactive demo validates it. Trying to figure out how!

[Hurairah Shamsi]

Updated the post body.

[Hurairah Shamsi]

Added an explainer video on YouTube that shows how the Local Client works and how Proof of Witness and Witness Chains work together to reject PoW mining attempts that exceed 1 hash per second per node:

https://youtu.be/i5gzzqFXXUk

[Hurairah Shamsi]

Added another video link: Visual representation of PoW mining during audio/video calls.

https://youtu.be/gPz7d3lGz1k

[Hirarchy]

Just watched the demo. Pretty impressive to see the project prioritizing decentralization. This initiative has massive potential; with 1 hash per sec per node, the low barrier to entry could enable widespread participation. With everyone running full nodes, it avoids centralization concerns of blockchain.

[Hurairah Shamsi]

We are now live on Product Hunt.
Would appreciate support and feedback from the community.

Link: https://www.producthunt.com/products/grahambell?utm_source=other&utm_medium=social

[Hurairah Shamsi]

Q/A

I got asked the following question:

Interesting approach.
If each node is capped at 1 hash/sec, how do you prevent Sybil scaling (running many low-cost nodes) from reintroducing parallel advantage at the network level?
Is identity or resource binding required, and if so, what enforces it?

It’s a fair question, so sharing the answer here as well.

Registration itself is a Proof of Work process.

Before a node can mine transaction blocks, it must first mine a registration block containing unique metadata. The hash of that block becomes the node’s ID. Without a valid ID, the node cannot propose transactions and peers (registered) will not connect to it. Registration is therefore enforced by consensus.

Registration blocks follow the same global throughput constraints as the rest of the network. They are bounded by block time, not by local hardware.

Similar to how you cannot mine 1 million Bitcoin blocks instantly just by adding machines, you cannot generate unlimited node IDs in parallel beyond the network’s registration throughput.

If registration averages ~1 minute per block (example here), then producing 1 million valid IDs would take ~1 million minutes (~694 days) on average, assuming zero competition.

Sybil scaling therefore becomes a time bottleneck rather than a hardware bottleneck.

Witness chains then restrict parallel connectivity both during and after registration, but that is a separate mechanism from the registration throughput constraint.

[Hurairah Shamsi]

Executive Summary — Neutralising the Advantage of Parallel Mining

Most Proof-of-Work systems reward parallelism. More hardware = more influence.
Proof-of-Stake systems reward capital concentration. More tokens = more influence.

This paper introduces a third model:

Influence scales only linearly with admitted subnet participation share and time under a fixed global issuance cap. Proof of Endurance (PoEnd), Proof of Presence (PoP) and Proof of Internet (PoI).

Uniqueness is enforced at the externally visible subnet allocation layer, not at the individual IP address or routing-sovereignty level.

Core Design Principles

1. Global Issuance Serialization

Identity issuance is globally serialized at a fixed rate (~1,050,000 IDs/year).

No participant can increase total issuance.
They can only compete for fractional probability share.

There is no burst capture.
There is no parallel minting.
There is no shard-level amplification.

Total issuance R is fixed at the protocol level through Proof of Work ID (PoW-ID) blocks (1 valid PoW-ID block = 1 Registered ID).

2. Per-Prefix Throughput Cap

Each externally visible IPv6 /64 public subnet allocation is capped at:

1 hash per second for Proof of Work computations.

Hardware acceleration, ASICs, multi-threading, and parallel compute provide no advantage per prefix.

Mining power scales only with the number of admitted externally visible /64 subnet allocations.

While IPv6 address space itself is abundant, the protocol does not rely on address scarcity as a security assumption. Security derives from the operational requirement to sustain large numbers of concurrent, stateful, deterministic mining sessions. Each admitted /64 subnet must maintain persistent multi-node connectivity and continuous pacing compliance. Influence scales with sustained operational participation, not with address ownership alone.

This eliminates vertical scaling advantage and makes horizontal scaling economically burdensome, as required persistent connections and uptime scale proportionally with participation and time.

2.1 Global Admission & Uniqueness Enforcement

Before any miner becomes eligible to compute PoW-ID or transaction blocks, participation must pass a global uniqueness check coordinated across Witness Chains.

When a miner attempts to join:

• A join request is submitted to a Witness Chain
• The externally visible /64 subnet or registered ID is announced network-wide via a lightweight claim broadcast after 1st validation
• All Witness Chains globally validate the request and verify that no active or pending claim already exists (2nd validation)

If duplication is detected:

• The join is rejected, or
• A deterministic canonical ordering rule selects a single valid claim and invalidates competing attempts

Only after global verification and convergence under deterministic canonical ordering does the prefix or ID become active and bound to its assigned Witness Chain.

This prevents:

• Simultaneous multi-chain participation
• Duplicate joins across shards
• Race-condition amplification
• Self-witnessing conflicts

A registered identity that controls a Witness Node within a chain may not join that same Witness Chain as a miner.

Uniqueness is enforced before pacing begins.

Deterministic hash pacing operates only after global admission succeeds.

Admission pressure is isolated from productive consensus: join validation is capacity-bounded at the shard level and processed independently of mining execution, ensuring that onboarding latency does not affect block production, issuance rate, or pacing enforcement. Only canonically admitted and activated participants influence the chain.

3. Infrastructure-Bound Identity Creation

During registration:

• 1 externally visible /64 subnet identity allocation = 1 mining connection
• Each accepted connection competes to mint exactly one non-transferable identity (ID).
• Each ID corresponds to exactly one allowed mining connection within the internal network.
• The externally visible /64 subnet allocation serves solely as the external registration (PoW-ID) constraint; identity issuance (validation) and mining (transactions) occur entirely within the protocol’s internal network.
• Each connection must maintain ~30 persistent witness connections
• Continuous uptime required
• Loss of connectivity forfeits registration eligibility

Large-scale participation therefore requires sustained multi-million persistent connections.

Subnet allocation alone is insufficient; sustained external reachability, uptime continuity, and persistent Witness connectivity determine eligibility.

Identity Finalization Rule

An unregistered miner may propose a PoW-ID block only after satisfying deterministic pacing compliance and obtaining majority Witness Chain signatures.

Identity issuance is finalized exclusively through full-network consensus validation of the proposed block.

Witnesses attest.
Global consensus finalizes.

The attack surface becomes:

Long-duration infrastructure endurance, not compute bursts.

Confirmation and Maturity

A PoW-ID block becomes a valid Registered ID only after reaching protocol-defined confirmation depth.

If competing PoW-ID blocks are proposed at the same height, the canonical chain is determined by longest-chain consensus. Only identities on the canonical chain after maturity are considered valid.

4. Deterministic Hash Pacing

Mining attempts are deterministically recomputed in parallel by Witness Chains at 1 hash per second.

If a miner attempts to accelerate or parallelize computation:

• Witness recomputation diverges
• Signed hash mismatch occurs
• The block is rejected

Acceptance requires deterministic equivalence across quorum Witness validation.

The pacing rule is enforced through a dual-consensus mechanism combined with sequential cryptographic chaining.

First, Witness Chains independently recompute each nonce attempt at exactly 1 hash per second beginning from a shared starting PoW state and consensus-injected unpredictable event. A PoW-ID or PoW-Transaction block is not eligible unless a quorum of Witness Nodes derives the identical valid hash under deterministic rules and signs the corresponding Proof-of-Witness (PoWit) block.

Second, all nonce attempts are sequentially chained within the PoWit block body. Each hash state depends on the previous state, beginning from nonce 0, timestamp n + 1, etc and progressing step-by-step until the valid PoW difficulty target is reached. The final PoWit root hash commits to the complete ordered history of attempts.

Because each step depends on the prior state, no valid future state can be computed without computing all intermediate states in exact sequence. Skipped attempts, accelerated computation, or fabricated histories produce a mismatched PoWit root and PoWit block hash and are rejected during global validation.

Witness Chains execute and attest to deterministic nonce progression.

Global consensus verifies the attested commitment and quorum signatures and validates by replaying the full nonce sequence.

Pacing enforcement is therefore:
• Operational (through independent Witness recomputation)
• Structural (through sequential PoWit root dependency)
• Canonical (through full-network deterministic validation)

Parallel hardware may compute locally at higher speed, but issuance (Transactions and IDs) remains cryptographically bound to serialized sequential verification and quorum Witness equivalence. Precomputation and time compression therefore provide no issuance acceleration.

4.1 Witness Load Partitioning

Witness re-computation responsibility is partitioned across bounded Witness Chains.

Each Witness Chain consists of ~30 registered nodes and is assigned a fixed identity validation capacity (e.g., 100 unregistered identities and 200 registered identities per chain at any given time).

A Witness Chain recomputes deterministic pacing only for the identities assigned to it, not for the entire network.

Scaling therefore follows:

• 1 chain → 100 unregistered identities and 200 registered identities = 300 total
• 2 chains → 200 unregistered identities and 400 registered identities = 600 total
• 1,000,000 chains → 100,000,000 unregistered and 200,000,000 registered identities = 300,000,000 total

No single Witness Node or Chain recomputes for all identities.

Total re-computation load grows linearly with network participation and is horizontally distributed across chains.

The protocol therefore preserves proportional scaling:

Registered identity growth increases total Witness capacity symmetrically, preventing quadratic re-computation growth.

Witness enforcement remains O(N), not O(N²).

5. Linear Economic Model

Let:

A = attacker-controlled admitted /64 subnet identities
N = total active admitted subnet identities
R = global issuance rate
P = probability share
T = time (duration of active mining)
Iₐ(T) = Expected identity accumulation over time T

Probability share:

P = A / N

Expected accumulation:

Iₐ(T) = (A / N) × R × T

No superlinear gain exists.

Influence scales strictly linearly with subnet participation share and time.

5.1 Dynamic Participation Effect

In practice, N (total admitted subnet identities) is a dynamic variable.

As network participation increases, N grows.

If an attacker’s infrastructure share A remains static while N expands, their proportional influence declines over time:

P(T) = A / N(T)

As N(T) → ∞, P(T) → 0 for any fixed A.

Network growth therefore dilutes static attackers.

Security scales with adoption.

Only proportional infrastructure expansion preserves influence share.

Improvements in hardware efficiency, networking stacks, or automation reduce absolute infrastructure cost per identity over time. However, required operational capacity scales with total network participation. Maintaining a fixed percentage share requires sustaining a proportional percentage of total active identities.

If future technology allows a participant to maintain millions of connections more efficiently, overall network participation capacity increases as well. The number of identities required to preserve the same influence share grows as N grows. Technological progress increases global capacity symmetrically and does not alter the protocol’s proportional security model.

6. Influence Dilution

Iₜ(T) = total global identity supply over time T

Total identities grow linearly:

Iₜ(T) = R × T

If acquisition stops:

P(T) → 0 over time.

Even majority positions decay unless proportional scaling continues.

Dominance is not one-time capture.
It is continuous maintenance.

7. Operational Activation Requirement

Holding a large number of registered identities does not automatically grant network control.

Influence over:

• Transaction ordering
• Block production
• Chain reorganization attempts

requires active mining participation under protocol rules.

Each active identity identity must:

• Maintain one mining connection
• Maintain ~30 persistent Witness connections
• Adhere to deterministic 1 hash/sec pacing

Operational scaling therefore follows:

N identities → N mining connections → ~30N witness connections

At scale, this produces linear connection growth:

• 10,000 identities → ~300,000 witness connections
• 100,000 identities → ~3,000,000 witness connections
• 1,000,000 identities → ~30,000,000 witness connections

Each connection exchanges protocol messages continuously (≈295 bytes per 30 seconds for unregistered nodes, excluding transport overhead).

This requirement is independent of transport protocol. Whether implemented over TCP, UDP, QUIC, or multiplexed transports, each identity must maintain independent logical session state, deterministic pacing compliance, and periodic Witness exchange. Transport substitution does not reduce identity cardinality or proportional bandwidth requirements.

Operational scaling therefore grows linearly with influence share and must be sustained indefinitely for continued control.

Registered identity accumulation without active mining confers no control.

To influence the ledger, identities must actively propose blocks under the same deterministic constraints that govern all participants.

Importantly, the 1 hash/sec rule applies uniformly to:

• Unregistered miners proposing PoW-ID blocks
• Registered miners proposing transaction blocks

There is no privileged acceleration pathway.

Control requires sustained infrastructure endurance, not passive identity possession.

8. Historical Inertia

H₀ = total number of pre-existing (historical + genesis) registered identities at T = 0

If H₀ identities already exist:

Time to majority ≈ H₀ / R

An attacker must effectively replay (out-accumulate) network history at scale.

Security strengthens with age.

Mature networks become temporally resistant to takeover.

With a non-zero Genesis base, even an attacker sustaining exactly 51% of annual issuance asymptotically approaches 51% total influence but never reaches it in finite time. Majority capture therefore requires sustained issuance dominance strictly greater than 51% for extended multi-year or multi-decade periods.

What This Model Does NOT Claim

• It does not make Sybil attacks impossible
• It does not rely on IPv6 scarcity
• It does not assume honest routing
• Temporary routing manipulation or short-term exposure of additional subnet allocations does not bypass serialized issuance or deterministic pacing enforcement. All join requests are globally propagated prior to mining eligibility, and duplicate /64 or registered ID claims are rejected at the network level. Even if a subnet becomes temporarily externally visible, it must independently sustain persistent Witness connectivity and continuous protocol-compliant participation over time. Influence accrues only through uninterrupted operational endurance. Loss of connectivity immediately halts accumulation and results in proportional dilution as total identities expand. Network exposure alone cannot accelerate issuance or compress time-bound accumulation.
• It does not prevent state-level actors

It ensures instead:

Sybil accumulation scales linearly in cost and time.

Parallel mining remains possible.

Parallel advantage does not.

Structural Outcome

Influence ∝ Admitted Subnet Participation Share × Time

Since:

• Issuance is fixed
• IDs are non-transferable
• Influence cannot be purchased
• Dominance decays without scaling

Majority capture becomes:

• Operationally intensive
• Multi-year sustained
• Linearly expensive
• Self-diluting under growth

This transforms consensus security from:

Hardware race (PoW)
or
Capital concentration (PoS)

into:

Time-compounded infrastructure endurance under perpetual dilution.

Parameterization Notice

All numeric values referenced in this summary (e.g., issuance rate, witness count, prefix granularity, pacing intervals) are provisional protocol parameters intended to demonstrate proportional behavior. Final values will be empirically determined through adversarial simulation and testnet validation. Security derives from proportional scaling properties, not fixed constants.

Full paper with formal model, economic assumptions, and detailed network-layer security analysis:

Releasing soon.

[Levi621]

Executive Summary — Neutralising the Advantage of Parallel Mining

Most Proof-of-Work systems reward parallelism. More hardware = more influence.
Proof-of-Stake systems reward capital concentration. More tokens = more influence.

This paper introduces a third model:

Influence scales only linearly with admitted subnet participation share and time under a fixed global issuance cap. Proof of Endurance (PoEnd), Proof of Presence (PoP) and Proof of Internet (PoI).

Uniqueness is enforced at the externally visible subnet allocation layer, not at the individual IP address or routing-sovereignty level.

Core Design Principles

1. Global Issuance Serialization

Identity issuance is globally serialized at a fixed rate (~1,050,000 IDs/year).

No participant can increase total issuance.
They can only compete for fractional probability share.

There is no burst capture.
There is no parallel minting.
There is no shard-level amplification.

Total issuance R is fixed at the protocol level through Proof of Work ID (PoW-ID) blocks (1 valid PoW-ID block = 1 Registered ID).

2. Per-Prefix Throughput Cap

Each externally visible IPv6 /64 public subnet allocation is capped at:

1 hash per second for Proof of Work computations.

Hardware acceleration, ASICs, multi-threading, and parallel compute provide no advantage per prefix.

Mining power scales only with the number of admitted externally visible /64 subnet allocations.

While IPv6 address space itself is abundant, the protocol does not rely on address scarcity as a security assumption. Security derives from the operational requirement to sustain large numbers of concurrent, stateful, deterministic mining sessions. Each admitted /64 subnet must maintain persistent multi-node connectivity and continuous pacing compliance. Influence scales with sustained operational participation, not with address ownership alone.

This eliminates vertical scaling advantage and makes horizontal scaling economically burdensome, as required persistent connections and uptime scale proportionally with participation and time.

2.1 Global Admission & Uniqueness Enforcement

Before any miner becomes eligible to compute PoW-ID or transaction blocks, participation must pass a global uniqueness check coordinated across Witness Chains.

When a miner attempts to join:

• A join request is submitted to a Witness Chain
• The externally visible /64 subnet or registered ID is announced network-wide via a lightweight claim broadcast after 1st validation
• All Witness Chains globally validate the request and verify that no active or pending claim already exists (2nd validation)

If duplication is detected:

• The join is rejected, or
• A deterministic canonical ordering rule selects a single valid claim and invalidates competing attempts

Only after global verification and convergence under deterministic canonical ordering does the prefix or ID become active and bound to its assigned Witness Chain.

This prevents:

• Simultaneous multi-chain participation
• Duplicate joins across shards
• Race-condition amplification
• Self-witnessing conflicts

A registered identity that controls a Witness Node within a chain may not join that same Witness Chain as a miner.

Uniqueness is enforced before pacing begins.

Deterministic hash pacing operates only after global admission succeeds.

Admission pressure is isolated from productive consensus: join validation is capacity-bounded at the shard level and processed independently of mining execution, ensuring that onboarding latency does not affect block production, issuance rate, or pacing enforcement. Only canonically admitted and activated participants influence the chain.

3. Infrastructure-Bound Identity Creation

During registration:

• 1 externally visible /64 subnet identity allocation = 1 mining connection
• Each accepted connection competes to mint exactly one non-transferable identity (ID).
• Each ID corresponds to exactly one allowed mining connection within the internal network.
• The externally visible /64 subnet allocation serves solely as the external registration (PoW-ID) constraint; identity issuance (validation) and mining (transactions) occur entirely within the protocol’s internal network.
• Each connection must maintain ~30 persistent witness connections
• Continuous uptime required
• Loss of connectivity forfeits registration eligibility

Large-scale participation therefore requires sustained multi-million persistent connections.

Subnet allocation alone is insufficient; sustained external reachability, uptime continuity, and persistent Witness connectivity determine eligibility.

Identity Finalization Rule

An unregistered miner may propose a PoW-ID block only after satisfying deterministic pacing compliance and obtaining majority Witness Chain signatures.

Identity issuance is finalized exclusively through full-network consensus validation of the proposed block.

Witnesses attest.
Global consensus finalizes.

The attack surface becomes:

Long-duration infrastructure endurance, not compute bursts.

Confirmation and Maturity

A PoW-ID block becomes a valid Registered ID only after reaching protocol-defined confirmation depth.

If competing PoW-ID blocks are proposed at the same height, the canonical chain is determined by longest-chain consensus. Only identities on the canonical chain after maturity are considered valid.

4. Deterministic Hash Pacing

Mining attempts are deterministically recomputed in parallel by Witness Chains at 1 hash per second.

If a miner attempts to accelerate or parallelize computation:

• Witness recomputation diverges
• Signed hash mismatch occurs
• The block is rejected

Acceptance requires deterministic equivalence across quorum Witness validation.

The pacing rule is enforced through a dual-consensus mechanism combined with sequential cryptographic chaining.

First, Witness Chains independently recompute each nonce attempt at exactly 1 hash per second beginning from a shared starting PoW state and consensus-injected unpredictable event. A PoW-ID or PoW-Transaction block is not eligible unless a quorum of Witness Nodes derives the identical valid hash under deterministic rules and signs the corresponding Proof-of-Witness (PoWit) block.

Second, all nonce attempts are sequentially chained within the PoWit block body. Each hash state depends on the previous state, beginning from nonce 0, timestamp n + 1, etc and progressing step-by-step until the valid PoW difficulty target is reached. The final PoWit root hash commits to the complete ordered history of attempts.

Because each step depends on the prior state, no valid future state can be computed without computing all intermediate states in exact sequence. Skipped attempts, accelerated computation, or fabricated histories produce a mismatched PoWit root and PoWit block hash and are rejected during global validation.

Witness Chains execute and attest to deterministic nonce progression.

Global consensus verifies the attested commitment and quorum signatures and validates by replaying the full nonce sequence.

Pacing enforcement is therefore:
• Operational (through independent Witness recomputation)
• Structural (through sequential PoWit root dependency)
• Canonical (through full-network deterministic validation)

Parallel hardware may compute locally at higher speed, but issuance (Transactions and IDs) remains cryptographically bound to serialized sequential verification and quorum Witness equivalence. Precomputation and time compression therefore provide no issuance acceleration.

4.1 Witness Load Partitioning

Witness re-computation responsibility is partitioned across bounded Witness Chains.

Each Witness Chain consists of ~30 registered nodes and is assigned a fixed identity validation capacity (e.g., 100 unregistered identities and 200 registered identities per chain at any given time).

A Witness Chain recomputes deterministic pacing only for the identities assigned to it, not for the entire network.

Scaling therefore follows:

• 1 chain → 100 unregistered identities and 200 registered identities = 300 total
• 2 chains → 200 unregistered identities and 400 registered identities = 600 total
• 1,000,000 chains → 100,000,000 unregistered and 200,000,000 registered identities = 300,000,000 total

No single Witness Node or Chain recomputes for all identities.

Total re-computation load grows linearly with network participation and is horizontally distributed across chains.

The protocol therefore preserves proportional scaling:

Registered identity growth increases total Witness capacity symmetrically, preventing quadratic re-computation growth.

Witness enforcement remains O(N), not O(N²).

5. Linear Economic Model

Let:

A = attacker-controlled admitted /64 subnet identities
N = total active admitted subnet identities
R = global issuance rate
P = probability share
T = time (duration of active mining)
Iₐ(T) = Expected identity accumulation over time T

Probability share:

P = A / N

Expected accumulation:

Iₐ(T) = (A / N) × R × T

No superlinear gain exists.

Influence scales strictly linearly with subnet participation share and time.

5.1 Dynamic Participation Effect

In practice, N (total admitted subnet identities) is a dynamic variable.

As network participation increases, N grows.

If an attacker’s infrastructure share A remains static while N expands, their proportional influence declines over time:

P(T) = A / N(T)

As N(T) → ∞, P(T) → 0 for any fixed A.

Network growth therefore dilutes static attackers.

Security scales with adoption.

Only proportional infrastructure expansion preserves influence share.

Improvements in hardware efficiency, networking stacks, or automation reduce absolute infrastructure cost per identity over time. However, required operational capacity scales with total network participation. Maintaining a fixed percentage share requires sustaining a proportional percentage of total active identities.

If future technology allows a participant to maintain millions of connections more efficiently, overall network participation capacity increases as well. The number of identities required to preserve the same influence share grows as N grows. Technological progress increases global capacity symmetrically and does not alter the protocol’s proportional security model.

6. Influence Dilution

Iₜ(T) = total global identity supply over time T

Total identities grow linearly:

Iₜ(T) = R × T

If acquisition stops:

P(T) → 0 over time.

Even majority positions decay unless proportional scaling continues.

Dominance is not one-time capture.
It is continuous maintenance.

7. Operational Activation Requirement

Holding a large number of registered identities does not automatically grant network control.

Influence over:

• Transaction ordering
• Block production
• Chain reorganization attempts

requires active mining participation under protocol rules.

Each active identity identity must:

• Maintain one mining connection
• Maintain ~30 persistent Witness connections
• Adhere to deterministic 1 hash/sec pacing

Operational scaling therefore follows:

N identities → N mining connections → ~30N witness connections

At scale, this produces linear connection growth:

• 10,000 identities → ~300,000 witness connections
• 100,000 identities → ~3,000,000 witness connections
• 1,000,000 identities → ~30,000,000 witness connections

Each connection exchanges protocol messages continuously (≈295 bytes per 30 seconds for unregistered nodes, excluding transport overhead).

This requirement is independent of transport protocol. Whether implemented over TCP, UDP, QUIC, or multiplexed transports, each identity must maintain independent logical session state, deterministic pacing compliance, and periodic Witness exchange. Transport substitution does not reduce identity cardinality or proportional bandwidth requirements.

Operational scaling therefore grows linearly with influence share and must be sustained indefinitely for continued control.

Registered identity accumulation without active mining confers no control.

To influence the ledger, identities must actively propose blocks under the same deterministic constraints that govern all participants.

Importantly, the 1 hash/sec rule applies uniformly to:

• Unregistered miners proposing PoW-ID blocks
• Registered miners proposing transaction blocks

There is no privileged acceleration pathway.

Control requires sustained infrastructure endurance, not passive identity possession.

8. Historical Inertia

H₀ = total number of pre-existing (historical + genesis) registered identities at T = 0

If H₀ identities already exist:

Time to majority ≈ H₀ / R

An attacker must effectively replay (out-accumulate) network history at scale.

Security strengthens with age.

Mature networks become temporally resistant to takeover.

With a non-zero Genesis base, even an attacker sustaining exactly 51% of annual issuance asymptotically approaches 51% total influence but never reaches it in finite time. Majority capture therefore requires sustained issuance dominance strictly greater than 51% for extended multi-year or multi-decade periods.

What This Model Does NOT Claim

• It does not make Sybil attacks impossible
• It does not rely on IPv6 scarcity
• It does not assume honest routing
• Temporary routing manipulation or short-term exposure of additional subnet allocations does not bypass serialized issuance or deterministic pacing enforcement. All join requests are globally propagated prior to mining eligibility, and duplicate /64 or registered ID claims are rejected at the network level. Even if a subnet becomes temporarily externally visible, it must independently sustain persistent Witness connectivity and continuous protocol-compliant participation over time. Influence accrues only through uninterrupted operational endurance. Loss of connectivity immediately halts accumulation and results in proportional dilution as total identities expand. Network exposure alone cannot accelerate issuance or compress time-bound accumulation.
• It does not prevent state-level actors

It ensures instead:

Sybil accumulation scales linearly in cost and time.

Parallel mining remains possible.

Parallel advantage does not.

Structural Outcome

Influence ∝ Admitted Subnet Participation Share × Time

Since:

• Issuance is fixed
• IDs are non-transferable
• Influence cannot be purchased
• Dominance decays without scaling

Majority capture becomes:

• Operationally intensive
• Multi-year sustained
• Linearly expensive
• Self-diluting under growth

This transforms consensus security from:

Hardware race (PoW)
or
Capital concentration (PoS)

into:

Time-compounded infrastructure endurance under perpetual dilution.

Parameterization Notice

All numeric values referenced in this summary (e.g., issuance rate, witness count, prefix granularity, pacing intervals) are provisional protocol parameters intended to demonstrate proportional behavior. Final values will be empirically determined through adversarial simulation and testnet validation. Security derives from proportional scaling properties, not fixed constants.

Full paper with formal model, economic assumptions, and detailed network-layer security analysis:

Releasing soon.

Has any tangible analysis test been carried out on GRAHAMBELL? I found this project very interesting and innovative, congratulations on the initiative.

[Hurairah Shamsi]

Executive Summary — Neutralising the Advantage of Parallel Mining

Most Proof-of-Work systems reward parallelism. More hardware = more influence.
Proof-of-Stake systems reward capital concentration. More tokens = more influence.

This paper introduces a third model:

Influence scales only linearly with admitted subnet participation share and time under a fixed global issuance cap. Proof of Endurance (PoEnd), Proof of Presence (PoP) and Proof of Internet (PoI).

Uniqueness is enforced at the externally visible subnet allocation layer, not at the individual IP address or routing-sovereignty level.

Core Design Principles

1. Global Issuance Serialization

Identity issuance is globally serialized at a fixed rate (~1,050,000 IDs/year).

No participant can increase total issuance.
They can only compete for fractional probability share.

There is no burst capture.
There is no parallel minting.
There is no shard-level amplification.

Total issuance R is fixed at the protocol level through Proof of Work ID (PoW-ID) blocks (1 valid PoW-ID block = 1 Registered ID).

2. Per-Prefix Throughput Cap

Each externally visible IPv6 /64 public subnet allocation is capped at:

1 hash per second for Proof of Work computations.

Hardware acceleration, ASICs, multi-threading, and parallel compute provide no advantage per prefix.

Mining power scales only with the number of admitted externally visible /64 subnet allocations.

While IPv6 address space itself is abundant, the protocol does not rely on address scarcity as a security assumption. Security derives from the operational requirement to sustain large numbers of concurrent, stateful, deterministic mining sessions. Each admitted /64 subnet must maintain persistent multi-node connectivity and continuous pacing compliance. Influence scales with sustained operational participation, not with address ownership alone.

This eliminates vertical scaling advantage and makes horizontal scaling economically burdensome, as required persistent connections and uptime scale proportionally with participation and time.

2.1 Global Admission & Uniqueness Enforcement

Before any miner becomes eligible to compute PoW-ID or transaction blocks, participation must pass a global uniqueness check coordinated across Witness Chains.

When a miner attempts to join:

• A join request is submitted to a Witness Chain
• The externally visible /64 subnet or registered ID is announced network-wide via a lightweight claim broadcast after 1st validation
• All Witness Chains globally validate the request and verify that no active or pending claim already exists (2nd validation)

If duplication is detected:

• The join is rejected, or
• A deterministic canonical ordering rule selects a single valid claim and invalidates competing attempts

Only after global verification and convergence under deterministic canonical ordering does the prefix or ID become active and bound to its assigned Witness Chain.

This prevents:

• Simultaneous multi-chain participation
• Duplicate joins across shards
• Race-condition amplification
• Self-witnessing conflicts

A registered identity that controls a Witness Node within a chain may not join that same Witness Chain as a miner.

Uniqueness is enforced before pacing begins.

Deterministic hash pacing operates only after global admission succeeds.

Admission pressure is isolated from productive consensus: join validation is capacity-bounded at the shard level and processed independently of mining execution, ensuring that onboarding latency does not affect block production, issuance rate, or pacing enforcement. Only canonically admitted and activated participants influence the chain.

3. Infrastructure-Bound Identity Creation

During registration:

• 1 externally visible /64 subnet identity allocation = 1 mining connection
• Each accepted connection competes to mint exactly one non-transferable identity (ID).
• Each ID corresponds to exactly one allowed mining connection within the internal network.
• The externally visible /64 subnet allocation serves solely as the external registration (PoW-ID) constraint; identity issuance (validation) and mining (transactions) occur entirely within the protocol’s internal network.
• Each connection must maintain ~30 persistent witness connections
• Continuous uptime required
• Loss of connectivity forfeits registration eligibility

Large-scale participation therefore requires sustained multi-million persistent connections.

Subnet allocation alone is insufficient; sustained external reachability, uptime continuity, and persistent Witness connectivity determine eligibility.

Identity Finalization Rule

An unregistered miner may propose a PoW-ID block only after satisfying deterministic pacing compliance and obtaining majority Witness Chain signatures.

Identity issuance is finalized exclusively through full-network consensus validation of the proposed block.

Witnesses attest.
Global consensus finalizes.

The attack surface becomes:

Long-duration infrastructure endurance, not compute bursts.

Confirmation and Maturity

A PoW-ID block becomes a valid Registered ID only after reaching protocol-defined confirmation depth.

If competing PoW-ID blocks are proposed at the same height, the canonical chain is determined by longest-chain consensus. Only identities on the canonical chain after maturity are considered valid.

4. Deterministic Hash Pacing

Mining attempts are deterministically recomputed in parallel by Witness Chains at 1 hash per second.

If a miner attempts to accelerate or parallelize computation:

• Witness recomputation diverges
• Signed hash mismatch occurs
• The block is rejected

Acceptance requires deterministic equivalence across quorum Witness validation.

The pacing rule is enforced through a dual-consensus mechanism combined with sequential cryptographic chaining.

First, Witness Chains independently recompute each nonce attempt at exactly 1 hash per second beginning from a shared starting PoW state and consensus-injected unpredictable event. A PoW-ID or PoW-Transaction block is not eligible unless a quorum of Witness Nodes derives the identical valid hash under deterministic rules and signs the corresponding Proof-of-Witness (PoWit) block.

Second, all nonce attempts are sequentially chained within the PoWit block body. Each hash state depends on the previous state, beginning from nonce 0, timestamp n + 1, etc and progressing step-by-step until the valid PoW difficulty target is reached. The final PoWit root hash commits to the complete ordered history of attempts.

Because each step depends on the prior state, no valid future state can be computed without computing all intermediate states in exact sequence. Skipped attempts, accelerated computation, or fabricated histories produce a mismatched PoWit root and PoWit block hash and are rejected during global validation.

Witness Chains execute and attest to deterministic nonce progression.

Global consensus verifies the attested commitment and quorum signatures and validates by replaying the full nonce sequence.

Pacing enforcement is therefore:
• Operational (through independent Witness recomputation)
• Structural (through sequential PoWit root dependency)
• Canonical (through full-network deterministic validation)

Parallel hardware may compute locally at higher speed, but issuance (Transactions and IDs) remains cryptographically bound to serialized sequential verification and quorum Witness equivalence. Precomputation and time compression therefore provide no issuance acceleration.

4.1 Witness Load Partitioning

Witness re-computation responsibility is partitioned across bounded Witness Chains.

Each Witness Chain consists of ~30 registered nodes and is assigned a fixed identity validation capacity (e.g., 100 unregistered identities and 200 registered identities per chain at any given time).

A Witness Chain recomputes deterministic pacing only for the identities assigned to it, not for the entire network.

Scaling therefore follows:

• 1 chain → 100 unregistered identities and 200 registered identities = 300 total
• 2 chains → 200 unregistered identities and 400 registered identities = 600 total
• 1,000,000 chains → 100,000,000 unregistered and 200,000,000 registered identities = 300,000,000 total

No single Witness Node or Chain recomputes for all identities.

Total re-computation load grows linearly with network participation and is horizontally distributed across chains.

The protocol therefore preserves proportional scaling:

Registered identity growth increases total Witness capacity symmetrically, preventing quadratic re-computation growth.

Witness enforcement remains O(N), not O(N²).

5. Linear Economic Model

Let:

A = attacker-controlled admitted /64 subnet identities
N = total active admitted subnet identities
R = global issuance rate
P = probability share
T = time (duration of active mining)
Iₐ(T) = Expected identity accumulation over time T

Probability share:

P = A / N

Expected accumulation:

Iₐ(T) = (A / N) × R × T

No superlinear gain exists.

Influence scales strictly linearly with subnet participation share and time.

5.1 Dynamic Participation Effect

In practice, N (total admitted subnet identities) is a dynamic variable.

As network participation increases, N grows.

If an attacker’s infrastructure share A remains static while N expands, their proportional influence declines over time:

P(T) = A / N(T)

As N(T) → ∞, P(T) → 0 for any fixed A.

Network growth therefore dilutes static attackers.

Security scales with adoption.

Only proportional infrastructure expansion preserves influence share.

Improvements in hardware efficiency, networking stacks, or automation reduce absolute infrastructure cost per identity over time. However, required operational capacity scales with total network participation. Maintaining a fixed percentage share requires sustaining a proportional percentage of total active identities.

If future technology allows a participant to maintain millions of connections more efficiently, overall network participation capacity increases as well. The number of identities required to preserve the same influence share grows as N grows. Technological progress increases global capacity symmetrically and does not alter the protocol’s proportional security model.

6. Influence Dilution

Iₜ(T) = total global identity supply over time T

Total identities grow linearly:

Iₜ(T) = R × T

If acquisition stops:

P(T) → 0 over time.

Even majority positions decay unless proportional scaling continues.

Dominance is not one-time capture.
It is continuous maintenance.

7. Operational Activation Requirement

Holding a large number of registered identities does not automatically grant network control.

Influence over:

• Transaction ordering
• Block production
• Chain reorganization attempts

requires active mining participation under protocol rules.

Each active identity identity must:

• Maintain one mining connection
• Maintain ~30 persistent Witness connections
• Adhere to deterministic 1 hash/sec pacing

Operational scaling therefore follows:

N identities → N mining connections → ~30N witness connections

At scale, this produces linear connection growth:

• 10,000 identities → ~300,000 witness connections
• 100,000 identities → ~3,000,000 witness connections
• 1,000,000 identities → ~30,000,000 witness connections

Each connection exchanges protocol messages continuously (≈295 bytes per 30 seconds for unregistered nodes, excluding transport overhead).

This requirement is independent of transport protocol. Whether implemented over TCP, UDP, QUIC, or multiplexed transports, each identity must maintain independent logical session state, deterministic pacing compliance, and periodic Witness exchange. Transport substitution does not reduce identity cardinality or proportional bandwidth requirements.

Operational scaling therefore grows linearly with influence share and must be sustained indefinitely for continued control.

Registered identity accumulation without active mining confers no control.

To influence the ledger, identities must actively propose blocks under the same deterministic constraints that govern all participants.

Importantly, the 1 hash/sec rule applies uniformly to:

• Unregistered miners proposing PoW-ID blocks
• Registered miners proposing transaction blocks

There is no privileged acceleration pathway.

Control requires sustained infrastructure endurance, not passive identity possession.

8. Historical Inertia

H₀ = total number of pre-existing (historical + genesis) registered identities at T = 0

If H₀ identities already exist:

Time to majority ≈ H₀ / R

An attacker must effectively replay (out-accumulate) network history at scale.

Security strengthens with age.

Mature networks become temporally resistant to takeover.

With a non-zero Genesis base, even an attacker sustaining exactly 51% of annual issuance asymptotically approaches 51% total influence but never reaches it in finite time. Majority capture therefore requires sustained issuance dominance strictly greater than 51% for extended multi-year or multi-decade periods.

What This Model Does NOT Claim

• It does not make Sybil attacks impossible
• It does not rely on IPv6 scarcity
• It does not assume honest routing
• Temporary routing manipulation or short-term exposure of additional subnet allocations does not bypass serialized issuance or deterministic pacing enforcement. All join requests are globally propagated prior to mining eligibility, and duplicate /64 or registered ID claims are rejected at the network level. Even if a subnet becomes temporarily externally visible, it must independently sustain persistent Witness connectivity and continuous protocol-compliant participation over time. Influence accrues only through uninterrupted operational endurance. Loss of connectivity immediately halts accumulation and results in proportional dilution as total identities expand. Network exposure alone cannot accelerate issuance or compress time-bound accumulation.
• It does not prevent state-level actors

It ensures instead:

Sybil accumulation scales linearly in cost and time.

Parallel mining remains possible.

Parallel advantage does not.

Structural Outcome

Influence ∝ Admitted Subnet Participation Share × Time

Since:

• Issuance is fixed
• IDs are non-transferable
• Influence cannot be purchased
• Dominance decays without scaling

Majority capture becomes:

• Operationally intensive
• Multi-year sustained
• Linearly expensive
• Self-diluting under growth

This transforms consensus security from:

Hardware race (PoW)
or
Capital concentration (PoS)

into:

Time-compounded infrastructure endurance under perpetual dilution.

Parameterization Notice

All numeric values referenced in this summary (e.g., issuance rate, witness count, prefix granularity, pacing intervals) are provisional protocol parameters intended to demonstrate proportional behavior. Final values will be empirically determined through adversarial simulation and testnet validation. Security derives from proportional scaling properties, not fixed constants.

Full paper with formal model, economic assumptions, and detailed network-layer security analysis:

Releasing soon.

Has any tangible analysis test been carried out on GRAHAMBELL? I found this project very interesting and innovative, congratulations on the initiative.

Appreciate the interest.

So far the focus has been on validating the core consensus and pacing mechanics. A working MVP (browser-based local client) and demo video already demonstrates deterministic 1 hash/sec progression per identity.

Full network-level analysis, adversarial simulations, and broader testing are planned for later phases as the implementation matures. Right now the priority is validating the model itself.

Happy to hear any technical thoughts in the meantime.

[zee47]

Just finished reading the executive summary and your design is really interesting.

The Genesis ID distribution is very clever considering it will make it structurally impossible for 51% attacks to occur in finite time.

[Laheeboo]

Now after doing a lot of reading and understanding little better, and watching the videos because, my god, visual learning is so much better for me, I understand this project a lot more.

But I have questions or things to discuss with you about it.

So from what I understand no matter what your device is we're all equal, and trust me I'm not trying to go into extremes, I'm asking based on real life.

My household has 2 gaming PCs, 2 laptops, 2 tablets, and 4 phones, sometimes work or school laptops on top of that, but let's say just those, 10 devices.

Would we be all able to join this project and mine it and our speed will be 1 on all devices? I figured out the answer is YES.

BUT would we all be able to mine on 10 different devices from 1 house? Not opening any virtual machines nothing crazy like that, would I have to choose only 1 of them to join or all 10 can?

Do you think there should be a cut off line or max hash allowed from IP I'm not sure how this part works yet? and since they are all individual devices I didn't see or read anything against them joining.

[Hurairah Shamsi]

Now after doing a lot of reading and understanding little better, and watching the videos because, my god, visual learning is so much better for me, I understand this project a lot more.

But I have questions or things to discuss with you about it.

So from what I understand no matter what your device is we're all equal, and trust me I'm not trying to go into extremes, I'm asking based on real life.

My household has 2 gaming PCs, 2 laptops, 2 tablets, and 4 phones, sometimes work or school laptops on top of that, but let's say just those, 10 devices.

Would we be all able to join this project and mine it and our speed will be 1 on all devices? I figured out the answer is YES.

BUT would we all be able to mine on 10 different devices from 1 house? Not opening any virtual machines nothing crazy like that, would I have to choose only 1 of them to join or all 10 can?

Do you think there should be a cut off line or max hash allowed from IP I'm not sure how this part works yet? and since they are all individual devices I didn't see or read anything against them joining.

> BUT would we all be able to mine on 10 different devices from 1 house? Not opening any virtual machines nothing crazy like that, would I have to choose only 1 of them to join or all 10 can?

You can mine using different devices (10 in your case) in parallel as long as they are not connected to the same visible IPv6 /64 subnet connection. The network only allows 1 mining connection per publicly visible and verifiable /64 subnet. But this rule only applies during ID generation (registration).

Once an ID is generated, 1 registered ID is considered 1 connection. So if you can successfully mine 10 or more IDs you can use multiple or the same device to mine in parallel.

However, the system does not only rely on the /64 subnet or registered ID rule alone to neutralize parallel mining.

If you’ve read the executive summary in reply 29, you can see that the system also requires each mining identity (/64 or registered ID) to maintain multiple persistent connections to witness nodes (for example ~30 connections per identity). These connections exchange small amounts of data periodically to stay synchronized.

Because of this, scaling to large numbers of mining identities requires real network infrastructure, bandwidth, and uptime, not just spinning up extra devices or virtual machines.

So, a normal household can participate easily, but large-scale parallel mining becomes operationally and economically expensive to attack or 51% control specifically when network adoption continues to grow honestly and constantly dilutes the attackers share.

[Laheeboo]

Thank you for clearing that out,

Looking forwards for the main net launch to try it out,

you did mention if something went wrong the device can be black listed, sometimes with auto ips once you restart devices you get different ip so that might flag it, I think users should use static ips on devices to avoid encountering that issue (if ever).

Can a machine be ever be whitelisted again? if so have you thought of the mechanics of it? or if something gets flagged it may never ever join again?

trust me I'm not planning or thinking of anything bad, I generally have bad luck at life and things don't usually just connect or just work out lol.

[Hurairah Shamsi]

Thank you for clearing that out,

Looking forwards for the main net launch to try it out,

you did mention if something went wrong the device can be black listed, sometimes with auto ips once you restart devices you get different ip so that might flag it, I think users should use static ips on devices to avoid encountering that issue (if ever).

Can a machine be ever be whitelisted again? if so have you thought of the mechanics of it? or if something gets flagged it may never ever join again?

trust me I'm not planning or thinking of anything bad, I generally have bad luck at life and things don't usually just connect or just work out lol.

The blacklist mechanism exists to protect the network from large-scale attacks, invalid parallel mining join attempts, or provable protocol violations (for example: invalid behaviour or breaking consensus rules). Normal honest users running standard nodes should never encounter this situation.

Also, a device itself is not blacklisted. Instead, the system can blacklist either:

• the IPv6 /64 subnet, or
• the registered mining ID

If a /64 subnet gets blacklisted, it is temporary. The subnet enters a cooling-off epoch, after which it can again be used to mine PoW-ID blocks. So yes, a /64 subnet can effectively become usable again. However, if the same behavior that caused the blacklist keeps repeating, the subnet of the owner will continue to be flagged, even if it’s dynamic.

This is intentional because persistent connectivity is important in the system. If an attacker keeps getting removed (gets offline) and has to rejoin repeatedly, their share of the network keeps getting diluted making them weaker as time progresses throughout the duration of them being offline.

If a registered ID is blacklisted, that ID is permanently removed. The participant would need to go through the registration process again to obtain a new ID before they can mine PoW-Transaction blocks.

In practice, normal households running honest nodes should never run into these situations, so I wouldn't be worried about it.

> trust me I'm not planning or thinking of anything bad, I generally have bad luck at life and things don't usually just connect or just work out lol.

Well... I can't really help with that unfortunately!

[Laheeboo]

Thank you for clearing that out,

Looking forwards for the main net launch to try it out,

you did mention if something went wrong the device can be black listed, sometimes with auto ips once you restart devices you get different ip so that might flag it, I think users should use static ips on devices to avoid encountering that issue (if ever).

Can a machine be ever be whitelisted again? if so have you thought of the mechanics of it? or if something gets flagged it may never ever join again?

trust me I'm not planning or thinking of anything bad, I generally have bad luck at life and things don't usually just connect or just work out lol.

The blacklist mechanism exists to protect the network from large-scale attacks, invalid parallel mining join attempts, or provable protocol violations (for example: invalid behaviour or breaking consensus rules). Normal honest users running standard nodes should never encounter this situation.

Also, a device itself is not blacklisted. Instead, the system can blacklist either:

• the IPv6 /64 subnet, or
• the registered mining ID

If a /64 subnet gets blacklisted, it is temporary. The subnet enters a cooling-off epoch, after which it can again be used to mine PoW-ID blocks. So yes, a /64 subnet can effectively become usable again. However, if the same behavior that caused the blacklist keeps repeating, the subnet of the owner will continue to be flagged, even if it’s dynamic.

This is intentional because persistent connectivity is important in the system. If an attacker keeps getting removed (gets offline) and has to rejoin repeatedly, their share of the network keeps getting diluted making them weaker as time progresses throughout the duration of them being offline.

If a registered ID is blacklisted, that ID is permanently removed. The participant would need to go through the registration process again to obtain a new ID before they can mine PoW-Transaction blocks.

In practice, normal households running honest nodes should never run into these situations, so I wouldn't be worried about it.

> trust me I'm not planning or thinking of anything bad, I generally have bad luck at life and things don't usually just connect or just work out lol.

Well... I can't really help with that unfortunately!

We need a coin to help with real life luck haha

but thank you so much for clearing that out, now All I have to do is hurry up and wait for the main net launch.

Wish you the best in this project and I hope it will work out for you and everyone involved.

I turned on notifications here so I'll keep up with the updates and once it's up and running I will join , specially that it would barely consume any power / computer power it's like a dream coin.

[oxynaz]

and what if you isp shares your ip with others ?

[Hurairah Shamsi]

and what if you isp shares your ip with others ?

To mine PoW-Transaction blocks, the IP address itself is not important. Mining at that stage is tied to the registered mining ID, not the IP.

However, in order to mine PoW-Transaction blocks, a node must first register by mining a PoW-ID block. During this identity registration phase the protocol limits one registration attempt per publicly visible and verifiable IPv6 /64 subnet.

If someone is using IPv4, it is possible that the address is shared, which could limit how many registration attempts (connection identities) can originate from that address.

But the protocol is primarily designed with IPv6 in mind which is the long-term direction of internet networking anyways, where each network (household) will typically have its own unshared /64 subnet, meaning different households should normally have independent prefixes and would not interfere with each other.

In short, once an identity is successfully registered, the IP address no longer affects mining, since mining would be tied to the registered ID.

[Hurairah Shamsi]

Thank you for clearing that out,

Looking forwards for the main net launch to try it out,

you did mention if something went wrong the device can be black listed, sometimes with auto ips once you restart devices you get different ip so that might flag it, I think users should use static ips on devices to avoid encountering that issue (if ever).

Can a machine be ever be whitelisted again? if so have you thought of the mechanics of it? or if something gets flagged it may never ever join again?

trust me I'm not planning or thinking of anything bad, I generally have bad luck at life and things don't usually just connect or just work out lol.

The blacklist mechanism exists to protect the network from large-scale attacks, invalid parallel mining join attempts, or provable protocol violations (for example: invalid behaviour or breaking consensus rules). Normal honest users running standard nodes should never encounter this situation.

Also, a device itself is not blacklisted. Instead, the system can blacklist either:

• the IPv6 /64 subnet, or
• the registered mining ID

If a /64 subnet gets blacklisted, it is temporary. The subnet enters a cooling-off epoch, after which it can again be used to mine PoW-ID blocks. So yes, a /64 subnet can effectively become usable again. However, if the same behavior that caused the blacklist keeps repeating, the subnet of the owner will continue to be flagged, even if it’s dynamic.

This is intentional because persistent connectivity is important in the system. If an attacker keeps getting removed (gets offline) and has to rejoin repeatedly, their share of the network keeps getting diluted making them weaker as time progresses throughout the duration of them being offline.

If a registered ID is blacklisted, that ID is permanently removed. The participant would need to go through the registration process again to obtain a new ID before they can mine PoW-Transaction blocks.

In practice, normal households running honest nodes should never run into these situations, so I wouldn't be worried about it.

> trust me I'm not planning or thinking of anything bad, I generally have bad luck at life and things don't usually just connect or just work out lol.

Well... I can't really help with that unfortunately!

We need a coin to help with real life luck haha

but thank you so much for clearing that out, now All I have to do is hurry up and wait for the main net launch.

Wish you the best in this project and I hope it will work out for you and everyone involved.

I turned on notifications here so I'll keep up with the updates and once it's up and running I will join , specially that it would barely consume any power / computer power it's like a dream coin.

Glad to hear that and thank you for the support!

If you’re interested, you can also join the waitlist on the website. We’ll notify waitlist members first about future updates, including the testnet launch, mainnet progress, and other developments.

Waitlist members will also get early access to try the testnet and etc.

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

[Laheeboo]

Already did, number 199 on the waiting list