applies to an 80-byte header and checks whether the result meets the network's target. The construction combines -based key derivation with a mixing stage that uses memory. That combination explains both Litecoin's distinctive mining hardware and a common misconception: requiring memory does not make an algorithm permanently resistant to .
This guide follows one attempt, explains the 128 KiB working array, and connects the calculation to difficulty, mining efficiency and Dogecoin .
The Scrypt family and Litecoin's fixed parameters
Scrypt was designed as a password-based key derivation function. Its configurable parameters let an application choose computational and memory costs. RFC 7914 documents that general construction; Litecoin fixes a particular configuration for .
The Litecoin Core implementation calls it scrypt_1024_1_1_256. The serialized block header occupies both the password and salt input positions. Those names describe the function's interface: a public mining header is not a secret password.
| Parameter | Value | Role |
|---|---|---|
| N | 1,024 | CPU/memory cost parameter; determines the ROMix loop lengths |
| r | 1 | Block-size parameter; the mixing state is 128 × r bytes |
| p | 1 | Number of mixing blocks in one Scrypt invocation |
| Input | 80 bytes | Serialized block header, used as both password and initial salt |
| Output | 32 bytes | 256-bit result used for the proof-of-work target comparison |
The parameter p = 1 does not limit a mining device to one core or one hash at a time. A device can evaluate many different headers in parallel. These consensus settings also should not be copied as a modern password-storage recommendation.
What the computation does
One Scrypt attempt has three main stages:
- Expand the header. PBKDF2-HMAC-SHA256 takes the header as password and salt and produces a 128-byte block. The PBKDF2 iteration count is one.
- Mix with memory. ROMix transforms that block using the fixed N and r values. Its BlockMix operation uses the Salsa20/8 core.
- Derive the result. PBKDF2-HMAC-SHA256 runs again, using the original header as password and the mixed block as salt, with one iteration and a 32-byte output.
Inside ROMix: store states, then revisit them
ROMix begins with the expanded block as its current state, X. In its first loop it stores X in V[i], applies BlockMix, and repeats for 1,024 entries. In its second loop it derives an index from the current X, combines X with V[index] using XOR, and applies BlockMix again. That second loop also runs 1,024 times.
The later accesses depend on the evolving state. An implementation that saves fewer intermediate states may have to reconstruct missing ones. This is the time–memory trade-off: reducing stored data can increase computation. The algorithm is specified in RFC 7914, sections 4–6.
What 128 KiB means
Each entry in the conventional V array holds 128 × r bytes. With Litecoin's parameters:
128 × N × r = 128 × 1,024 × 1 = 131,072 bytes = 128 KiB.
This describes the main working array for one conventional computation. Additional input, temporary state and alignment space are separate. An ASIC designer may also choose a different balance between storage and recomputation, so the expression does not prescribe an exact physical SRAM allocation for every engine.
The memory is reusable. Finishing a hash does not permanently consume another 128 KiB. Multiple simultaneous computations do require their own active state or an implementation that schedules and shares resources.
Working-array capacity is not memory bandwidth. A bandwidth estimate must account for the implementation's actual reads, writes, reuse and recomputation. Multiplying 128 KiB by a device's does not by itself establish that device's memory traffic.
What a miner changes between attempts
A miner constructs a candidate block and repeatedly changes valid inputs to search for a qualifying result. Scrypt processes the header rather than hashing the entire block's transaction data directly on every attempt. The header's Merkle root commits to the transaction set.
| Field | Bytes | Purpose |
|---|---|---|
| Version | 4 | Block version and applicable signalling bits |
| Previous block hash | 32 | Links the candidate to its parent |
| Merkle root | 32 | Commits to the block's transaction set |
| Timestamp | 4 | Candidate time, subject to validation rules |
| nBits | 4 | Compact encoding of the required target |
| Nonce | 4 | A 32-bit field varied during mining |
The nonce provides 232 possible values for an otherwise unchanged header. Miners can create further work by changing an extra nonce in the coinbase transaction, which changes its and the Merkle root. The extra nonce is not an additional header field. Litecoin Core's IncrementExtraNonce implementation shows this connection.
The header definition fixes the field layout. Miners cannot freely choose an easier nBits value: verify that the declared target is the one required by consensus.
The proof-of-work result is not the block identifier
Litecoin uses two different header hashes for different purposes. Scrypt produces the proof-of-work result; double SHA-256 produces the block identifier. A block hash displayed by an explorer should therefore not be treated as the Scrypt result tested against the mining target.
This distinction is explicit in Litecoin Core: GetPoWHash() calls Scrypt, while GetHash() calls SerializeHash(). The latter uses the double-SHA-256 writer defined in hash.h. Saying that Litecoin uses Scrypt does not mean every hash operation in the protocol uses Scrypt.
How difficulty changes the search
A proof-of-work result qualifies when its numerical value is less than or equal to the required target. A smaller target leaves fewer qualifying results. Describing this as finding enough leading zeroes is a useful intuition, but the exact rule is a numerical comparison, as shown in CheckProofOfWork().
Increasing difficulty does not increase N, r or p. It makes a qualifying result less likely per attempt while leaving the Scrypt construction unchanged. If a valid target is approximately halved, the expected number of attempts approximately doubles. It does not make an individual attempt use twice the working memory.
Litecoin mainnet targets an average block interval of 150 seconds and adjusts difficulty every 2,016 blocks. That corresponds to a nominal adjustment period of 3.5 days, calculated as 2,016 × 150 seconds. These values come from the mainnet parameters and the retarget logic in pow.cpp.
The interval is an average, not a timetable. Individual blocks may arrive much sooner or later, and an adjustment period need not last exactly 3.5 calendar days. A pool's share target is another threshold: shares let the pool account for contributed work, and most shares do not qualify as network blocks.
Why ASICs still exist
Memory-related work changes the cost of specialization; it does not prevent specialized circuits. ASIC designers can optimize computation, storage and data movement together. Litecoin's fixed, relatively small working array is a defined engineering workload, not a guarantee that general-purpose hardware will stay competitive.
A Bitcoin SHA-256 ASIC cannot mine Litecoin's Scrypt proof of work merely by changing its pool . The required computation differs. Likewise, comparing Scrypt GH/s with SHA-256 TH/s does not compare equivalent mining performance.
A worked example: hashrate, power and energy
The BITMAIN L9 specification lists a 16 GH/s configuration with typical wall power of 3,360 W and efficiency of 210 J/GH at 25°C. This is a documented example, not a ranking of the newest or most profitable hardware. The manufacturer lists hashrate variation of ±3% and wall-power and efficiency variation of ±5%.
| Quantity | Calculation | Result |
|---|---|---|
| Hashrate | 16 billion Scrypt attempts per second | 16 GH/s |
| Energy per work | 3,360 W ÷ 16 GH/s | 210 J/GH |
| Daily energy | 3.36 kW × 24 hours | 80.64 kWh |
| Daily electricity cost | 80.64 kWh × hypothetical $0.10/kWh | $8.064, or about $8.06 |
Watts measure power; kilowatt-hours measure energy over time. Dividing power by hashrate gives energy per unit of work because W = J/s. Lower J/GH means less energy for the same number of Scrypt attempts when measurement conditions are comparable.
The daily example assumes continuous operation at the stated power and excludes additional site loads such as external cooling. Electricity cost alone does not establish profit: hardware cost, uptime, pool fees, actual payouts and coin prices also matter. The mining calculator and mining operations guide cover those separate assumptions.
Merged mining and separate targets
Compatible miners can reuse Scrypt work for Litecoin and Dogecoin through auxiliary proof of work, or AuxPoW. The two networks retain separate blocks, ledgers, targets and reward rules. Running a Scrypt miner does not automatically guarantee that a pool credits rewards from both coins.
- The mining setup prepares an auxiliary block and places a commitment to it in the parent candidate's coinbase transaction.
- The parent header's Merkle root commits to that coinbase. Mining then searches Scrypt results for the prepared header.
- Dogecoin validates the auxiliary commitment and tests the parent header's Scrypt result against Dogecoin's own target. Litecoin independently applies its own target and block rules.
An accepted Dogecoin block does not require a simultaneously accepted Litecoin block. A result can meet Dogecoin's target without meeting Litecoin's target. Dogecoin Core's CheckAuxPowProofOfWork() performs the parent-proof target check, while the AuxPoW implementation checks the commitment structure.
The shared search does not require a second independent Scrypt search for DOGE, although building, validating and submitting auxiliary blocks still requires supporting software and infrastructure. Check the pool's payout policy: rewards earned by a pool and assets actually paid to an individual miner are different quantities. The merged-mining guide develops that distinction.
Security claims need the correct primitive
Scrypt proof of work helps determine which candidate headers satisfy the mining requirement. Nodes must also validate transactions and the rest of the block's consensus rules. A valid PoW result does not make invalid transactions acceptable.
Proof of work and transaction signatures solve different problems. Specialized mining hardware does not, by itself, let its owner derive other users' or sign their transactions. Compromised keys, signature attacks, consensus bugs and majority-hashrate attacks require separate analysis.
Memory hardness also does not establish immunity to quantum computing. This guide makes no forecast for a practical quantum attack. Any assessment must identify the primitive being attacked, its resource requirements and the protocol changes needed to respond.
Calculation inputs and sources
Download this guide's calculation inputs and results (CSV). The file contains the working-array size, header length, nominal retarget period and L9 energy example. The $0.10/kWh tariff is hypothetical; the device inputs are manufacturer specifications, not measurements made by Litecoin.watch.
Protocol claims above link to Litecoin Core v0.21.5.8 and Dogecoin Core v1.14.9 so readers can inspect the cited versions. RFC 7914 supplies the general algorithm definition. The sources establish the stated construction and calculations; they do not establish a universal ASIC memory-bandwidth figure, current mining profitability or future cryptographic immunity.
Frequently asked questions
Is Scrypt ASIC-resistant today?
No. Specialized Scrypt ASICs exist. Requiring memory changes implementation costs but does not prevent custom mining hardware.
Does every hash permanently consume another 128 KiB?
No. The conventional V array can be reused between sequential attempts. Parallel designs need active state for their concurrent work or another scheduling and memory trade-off.
Does higher Litecoin difficulty require more RAM per hash?
No. Difficulty changes the required target. Litecoin's Scrypt parameters N=1024, r=1 and p=1 stay fixed, so difficulty does not enlarge the conventional V array.
Is an explorer's Litecoin block hash the Scrypt result?
No. The block identifier uses double SHA-256. Litecoin Core separately calculates the Scrypt proof-of-work result for the target comparison.
Can a Bitcoin ASIC mine Litecoin?
A SHA-256 Bitcoin ASIC does not perform Litecoin's Scrypt construction. Changing the pool configuration does not change the hardware's hashing algorithm.
Does merged mining find LTC and DOGE blocks together every time?
No. Each chain has its own target and validation rules. A qualifying Dogecoin auxiliary proof does not require an accepted Litecoin block at the same time.
