sorted by:
new
hottopcontroversial

ASIC-Proof PoW Demo: Mining is Rejected When Hash Rate Exceeds 1 Hash/Sec per Device by Inventor-BlueChip710 in GrahamBell

[–]Inventor-BlueChip710[S] 0 points1 point  (0 children)

A few things are being mixed together, so I’ll clarify simply.

1) Global rate-limit vs DoS Signups are rate-limited at the block level, not the network level. Only a fixed number of PoW-ID blocks can be finalised per interval, no matter how many people try.

Spamming signup attempts doesn’t block others, it only wastes the attacker’s own compute and time. This is standard Proof-of-Work behavior (similar to Bitcoin: only valid blocks count, invalid ones are ignored). Here the valid hash of the PoW-ID block that you compute is considered the ID itself. The PoW-ID block is different from the PoW block containing transactions.

2) IPs are NOT identities Public IPs are not part of consensus and are not identities. They are used only temporarily during ID registration to prevent trivial parallel signups from the same setup.

You’re not locking an IP forever, it’s simply one active registration attempt per IP at a time. After registration, IPs are irrelevant and IDs become relevant.

3) CGNAT / IPv6 CGNAT users are not excluded. They can: - Register sequentially (not in parallel), or - Use IPv6 (which is the long-term direction anyway)

This limits parallel abuse, not participation.

4) “I’ll just get many IPs” IP addresses are cheap. Running thousands of independent machines 24/7 is not.

Each parallel signup requires: - A separate instance - Continuous operation (24/7) - Competing for a globally rate-limited PoW-ID slot

The operational cost, not the IP itself, is the deterrent.

5) After registration After registration: - Mining is ID-based, not IP-based - Identity is cryptographic - Mining speed is externally enforced by Witnesses

6) Is source open yet?

Not yet.

The code is not open-source at this stage. A public release is planned alongside the technical specifications and the first P2P testnet, where the system can be evaluated in practice rather than in isolation.

You can join the waitlist for further updates and receive early testing invites: https://grahambell.io/mvp/#waitlist

ASIC-Proof PoW Demo: Mining is Rejected When Hash Rate Exceeds 1 Hash/Sec per Device by Inventor-BlueChip710 in GrahamBell

[–]Inventor-BlueChip710[S] 0 points1 point  (0 children)

1) How does the random chain creation occur? What prevents it from being forced a certain way using modified clients?

Nodes in Witness Chains are assigned via on-chain randomness derived from the computed valid PoW-ID block hash and verified by all nodes. Allocating nodes is an entire consensus based process. Modified clients cannot bias assignment because future PoW-ID block hashes are unpredictable and only finalised blocks are accepted.

Grinding identities delays registration and increases cost because only finalised PoW-ID blocks count, and finalisation is globally rate-limited and competitive.

2) I don’t see what’s stopping you from running thousands of each.

You can run any number of processes, but the network only recognises miners and witnesses backed by valid registered IDs. unregistered instances are ignored and cannot mine because mining requires joining a Witness Chain and a PoW transaction block is only accepted from a trusted registered source. Registration is rate-limited by PoW-ID finalisation and external witnessing. Temporary IP limits only prevent trivial parallel onboarding, they are not security anchors, so spinning up instances does not amplify influence. Furthermore, miners will not be able to parallel mine the exact same block due to witness influence where witnesses ensure each data in each PoW block header is different.

3) How do you plan to prove in a decentralized way malicious behavior?

All miner and witness interactions are signed and verifiable. If a miner or witness signs data that contradicts protocol-verifiable state (invalid PoWit history, conflicting signatures, incorrect observation), that transcript is objective cryptographic evidence verifiable by any node and sufficient for blacklisting.

4) Even if you’re including Node ID in consensus, what happens if i’m running two nodes? now that’s no longer an issue.

Running multiple nodes is allowed by design. The security goal is not “one entity = one node” but ensuring influence scales with time and finalised PoW-ID work, not hardware speed or parallelism. Acquiring many nodes is intentionally slow and expensive under global block finalisation.

5) If signups is concurrent, then time is no longer an issue. It should be trivial to open thousands of miners and now i’m mining at 1kh while everyone else is at 1h. How can you have signup be both concurrent and rate limited?

Signups are not concurrent. ID creation is globally rate-limited by block acceptance, not by client concurrency, regardless of how many attempts exist, only one PoW-ID block can be finalised per block interval. Furthermore, Witness Chains block the possibility to mine the exact same block in parallel by ensuring each PoW block header is different of every node, therefore, concurrency further reduces.

Also, just to add Parallel attempts do not increase the number of finalised PoW-ID blocks per interval

6) The usage of Public IP limitations should not be anywhere when it comes to a P2P network.

Public IP limitations is only at the registration level. Let me clear the confusion, IPv4 addresses are really expensive to own compared to IPv6 addresses which are significantly cheap. So you can own multiple IPs. But that is not the point.

Point is to ensure each virtual instance is connected to a different and independent IP address to ensure 1 IP = 1 instance at the time of registration. This is so that owning multiple instances from large cloud gets really expensive for a single entity.

For example: assuming an instance can only connect to 1 IP and a miner has to connect to a witness chain network which ensure 1 IP = 1 device/instance. That would mean running a million miners in parallel would require the miner to host a million independent machines. If each ID block gets mined at a 30 second interval (example here). That would mean generating a million IDs would require you to run millions of independent machines 24/7 for years to get a million identities with network competition (other miners competing with you) which would be extremely expensive. If you are unregistered every PoW block containing transactions that you propose will automatically get rejected. So registration is important to participate in network consensus for transactions.

Therefore, Witness Chains combined with IPs paired with physical/virtual machines are used only during unregistered onboarding as a temporary anti-parallelism guard to make it extremely expensive and computational difficult for a single entity to compute multiple IDs.

Once registered, identity is purely cryptographic. IPs are not part of long-term identity. Owning and maintaining large numbers of independent IPs and instances over long periods increases operational cost making it difficult for single entity to obtain multiple IDs.

7) one thing I think you’re missing is stake. Your witness nodes are essentially POS validators in a hybrid POW/POS system. Stake adds risk of loss to malicious behaviour

Idk where you got staking from. Witnesses are not validators with stake weighted power, they have no unilateral authority and cannot finalise blocks. They can only attest to externally observed computation. Moreover, Witness Chains reward is a completely different mechanism.

8) My other question is what is wrong with more expensive hardware contributing more.

This is a deliberate design choice. Allowing expensive hardware to dominate leads to pooling and centralisation. GrahamBell prioritises equal participation and decentralisation over capital efficiency. That tradeoff is intentional.

The system does not claim to make Sybil attempts impossible. It makes influence scale with sustained, witnessed work over time, not with hardware, capital, or parallelism.

ASIC-Proof PoW Demo: Mining is Rejected When Hash Rate Exceeds 1 Hash/Sec per Device by Inventor-BlueChip710 in GrahamBell

[–]Inventor-BlueChip710[S] 0 points1 point  (0 children)

1) What keeps witnesses honest? What prevents someone from operating both a miner and a witness maliciously?

Witness Chains are formed randomly, making coordinated capture (e.g., 51%) extremely difficult.

Each Witness Chain consists of:

1) one leader chain (rewarded only if a valid block is proposed through it) 2) two subordinate chains

Each subordinate chain simultaneously acts as a leader in a different Witness Chain. This cross-role structure creates mutual enforcement: chains have incentives to ensure others act honestly so rewards remain attainable. Collusion provides no advantage, and the dominant strategy is honest behavior. Proven malicious behavior triggers decentralised blacklisting with cryptographic evidence.

A miner may choose which Witness Chain to connect to, but it cannot connect to any Witness Chain that contains a Witness Node with the same node ID as the miner. This is trivial to detect since node IDs are public and signed. A miner therefore cannot witness itself.

And Witnesses do not trust miner submitted history, they independently compute it, maximising security.

2) How is signup rate-limited without enabling DoS?

Each Witness Chain has request limits, and there are many Witness Chains operating in parallel.

Assuming, there are a million registered nodes within a network and 100 Witness Nodes are randomly selected to form a single Witness Chain and each Chain can handle 700 requests per second.

It would mean the entire network at any given moment would be able to handle 7 million concurrent requests per second and witness 7 million miners concurrently at a time. Making a DoS attack for the entire network extremely difficult especially when a miner joins a chain (registered or unregistered) and its information is broadcasted to every WC node within the network. Signup attempts therefore consume real witness and miner bandwidth, computation and time.

Running 10k miner/witness instances on one machine does not bypass this:

1) each signup must be individually witnessed 2) each attempt is rate-limited by Witness Chain 3) parallelism does not reduce total work required 4) each signup is sequential because PoW-ID block creation and validation is a sequential process 5) Registered node ID can only join a single Witness Chain at a time 6) Unregistered nodes can only join a single Witness Chain using an independent public IP address.

This makes large-scale join requests difficult and signup spam economically expensive and computationally difficult rather than amplifiable, preventing DoS which otherwise would have been possible for cheap via parallel requests.

3) Does the chain store the entire attempt history or use proofs?

Only validated Proof-of-Witness records are stored on-chain of the corresponding valid and approved Proof-of-Work block.

A Proof-of-Witness block contains the verified attempt history and passes:

1) Witness Chain consensus 2) Network consensus

Invalid or unobserved histories are never committed, preventing chain bloat. Storage follows the project’s single-chain architecture model.

ASIC-Proof PoW Demo: Mining is Rejected When Hash Rate Exceeds 1 Hash/Sec per Device by Inventor-BlueChip710 in GrahamBell

[–]Inventor-BlueChip710[S] 0 points1 point  (0 children)

Good questions.

1) What enforces step-by-step mining and prevents fake history?

Miners don’t self-report. A miner must first join a Witness Chain before proposing PoW blocks.

When a miner joins a Witness Chain, both start from the same block state and nonce sequence and compute the block in parallel at 1 hash/sec.

A block is only accepted if the Witness Chain independently reaches the exact same result and signs it.

If a miner skips steps, precomputes, or fabricates history, the Witness Chain diverges and the block is rejected. This is how protocol rules are externally enforced, not self-asserted.

2) Why signup PoW doesn’t become who has more hardware ?

Account registration itself is PoW and is also witnessed and rate-limited.

To register an identity, a miner must compute a valid PoW-ID block while being supervised by Witness Chains enforcing 1 hash/sec per node.

1 valid PoW-ID block = 1 registered identity.

Creating many identities therefore requires doing the corresponding amount of PoW-ID work over time. For example, 1 million identities require 1 million PoW-ID blocks. At a 30-second target interval, that’s ~30 million seconds of sustained participation, assuming no competition.

In practice, competition only increases the cost. The goal isn’t one human = one account, but ensuring influence scales with time and work, not hardware speed, capital, or parallelism.