Scrypt parameters (GCC demo chain).

01 Scrypt, the Litecoin family

GCC’s Proof-of-Work hash is Scrypt, the same memory-hard function Litecoin has used since 2011. This page is the chain’s specification, and it exists partly to correct an earlier mistake in our own materials: an early draft described GCC as using “KawHash”. That was wrong. GCC is a fork of Litecoin Core v0.21.5.5, and it inherits Litecoin’s Scrypt PoW unchanged. If you read “KawHash” anywhere, treat this page as the authority — the algorithm is Scrypt.

Why it matters which one it is: the PoW function determines what hardware can mine the chain and how a miner, a pool and the node must compute and check work. Scrypt is well understood, has a mature tooling and pool ecosystem, and — being the Litecoin family — has commercially available ASICs. That last point is a property to design around, not a flaw; section 07 covers it honestly.

Everything in this spec is for a testnet chain. GCC units have no monetary value. The numbers here are the reference chain’s parameters; when you re-brand the stack you change these in one place (the chain params) and rebuild — they are the knobs, and this page documents what each one is.

02 The Scrypt parameters

Scrypt is a key-derivation function deliberately built to be memory-hard: computing it requires filling and re-reading a scratchpad of memory, which makes it costly to parallelise in cheap silicon. It is parameterised, and the parameters fix how much memory and work each hash costs. GCC uses the Litecoin parameter set:

Parameter	Symbol	GCC value	What it controls
Cost / iterations	N	1024	Size of the scratchpad; dominant cost. Higher N = more memory + time per hash.
Block-size factor	r	1	Width of each memory block.
Parallelisation	p	1	Independent lanes; 1 means no internal parallelism.
Derived-key length	dklen	32	Output length in bytes — a 256-bit hash.

In words: the node computes Scrypt(input, salt, N=1024, r=1, p=1, dklen=32) and gets a 32-byte (256-bit) digest. For block hashing the input and the salt are the same 80-byte block header — this is the Litecoin construction, where Scrypt is applied to the serialised header to produce the PoW hash. These exact values (1024 / 1 / 1 / 32) are what makes GCC mineable by the existing Litecoin/Scrypt tool and pool ecosystem with no special build: to a Scrypt miner, GCC work looks like any other Scrypt-family chain’s work.

03 Chain parameters

Beyond the PoW function, a fork is defined by its consensus and network constants. These are GCC’s. Change them and rebuild and you have a different chain — which is exactly what re-branding the stack does.

Parameter	GCC value	Notes
PoW algorithm	Scrypt (N=1024, r=1, p=1)	Litecoin family
Target block time	60 seconds	One block per minute
Initial block reward	50 GCC	Coinbase to the miner
Halving interval	~2,103,840 blocks	Reward halves; ≈ every 4 years at 60s blocks
Supply cap	~210,000,000 GCC	Asymptotic ceiling from the halving schedule
Premine	0	No pre-allocated supply; all coins from mining
Network magic	c7cc112a	P2P message prefix; isolates the network
P2P port	9433	Peer-to-peer
RPC port	9332	JSON-RPC control (loopback only)
Address prefix	gcc1… (bech32), G… (legacy)	Human-readable part is gcc
Coinbase maturity	100 blocks	Reward unspendable until 100 confirmations

A couple of these deserve a sentence. The halving works exactly as in Bitcoin/Litecoin: the coinbase reward starts at 50 GCC and halves every ~2,103,840 blocks; at a 60-second target that interval is roughly four years, and the geometric sum of all rewards converges on the ~210M cap. Premine is zero — there is no founder allocation; every GCC in existence came from a mined coinbase. The network magic c7cc112a is the four-byte tag on every P2P message; it is what stops a GCC node and a Litecoin node from ever mistaking each other for peers, even though the wire format is otherwise identical.

04 The block header

GCC’s block header is the standard 80-byte Bitcoin/Litecoin header — six fields, serialised little-endian, in this order:

Field	Bytes	Meaning
version	4	Block version / soft-fork signalling bits
prev_block	32	Hash of the previous block — the chain link
merkle_root	32	Merkle root committing to every transaction in the block
time	4	Block timestamp (Unix seconds)
bits	4	The difficulty target, in compact “nBits” form
nonce	4	The value a miner varies to search for a valid hash

You can read these straight off any block with the RPC — getblock and the explorer’s /block/:hash both decode them:

The nonce is the miner’s free variable: it tries value after value, re-hashing the header each time, until the Scrypt digest comes out below the target. When the 32-bit nonce space is exhausted without a solution, the miner changes something else that is allowed to vary — the coinbase transaction (which alters the merkle_root) or the time — and keeps searching. A pool drives this through getblocktemplate and submitblock (see the JSON-RPC reference).

05 How a block is judged valid

A block’s Proof-of-Work is valid when the Scrypt digest of its header, read as a 256-bit number, is less than or equal to the target encoded in bits. That is the whole test. Conceptually:

The bits field is a compact encoding of the target: a one-byte exponent and a three-byte mantissa, in the same “nBits” format Bitcoin uses. A smaller target is harder to beat (fewer hashes qualify), so a smaller target means higher difficulty. “Difficulty” as reported by the RPC is just a human-friendly ratio of the easiest-allowed target to the current target.

When a miner submits a solved block, the node recomputes this check itself before accepting — it does not trust the submitter. If the Scrypt hash does not clear the target, submitblock returns "high-hash" and the block is rejected. This is why a pool must compute the Scrypt hash exactly the way the node does, with the right byte order on the header fields; a mismatch there shows up as every share being rejected for high-hash even though the miner “found” a block.

06 Difficulty retargeting and the demo floor

To hold the 60-second target block time as hashing power changes, the chain periodically retargets difficulty: if blocks have been coming faster than one a minute, the target tightens (difficulty rises); if slower, it loosens. The mechanism is inherited from the Litecoin codebase — the node measures the time the last retarget window actually took against the time it should have taken and scales the target by that ratio, within bounded step limits so difficulty cannot lurch too far in one adjustment.

For a private or freshly-launched demo network there is almost no hashing power, so the chain ships with a low difficulty floor — the easiest target the chain will set. This is deliberate and it is why generatetoaddress returns a block quickly on a quiet GCC testnet: with the floor low, a single CPU clears the target in moments. The floor is the minimum-difficulty / “powLimit” consensus value, set in the chain params alongside everything in section 03.

07 ASICs, not ASIC-resistance

One honest point to close on, because the earlier “KawHash” framing got this backwards too. Scrypt with Litecoin’s parameters (N=1024) is not ASIC-resistant. The memory footprint at N=1024 is small enough that specialised Scrypt ASICs have existed and been sold commercially for years. So:

• GCC is ASIC-available, not ASIC-resistant. CPUs and GPUs can mine it — and on the low demo floor a CPU is plenty — but on any contested network purpose-built Scrypt ASICs would dominate, exactly as they do on Litecoin.
• That is fine for the demo’s purpose: the point of the reference chain is a complete, working, re-brandable PoW network, not a particular mining-hardware policy.
• If a future operator genuinely wanted ASIC-resistance, that is a different algorithm choice (a different memory-hard function with a much larger footprint, or a different PoW entirely) — a fork-level decision, not a parameter tweak. Do not market the chain as ASIC-resistant; it is not, and saying so would be wrong.

This is the corrected, accurate picture: Scrypt PoW, Litecoin v0.21.5.5 lineage, N=1024/r=1/p=1/dklen=32, ASIC-available — replacing the earlier mistaken “KawHash” description wherever it still appears.