cannot be established by adding a count to a rich-list percentage. coordination, validation, software distribution, and development have different participants and different failure modes. A useful assessment preserves the evidence for each one and states which control the measurement actually represents.
The earlier version presented pool shares, reachable-node estimates, holder balances and contributor counts without the frozen records needed to reproduce them. Those figures are withdrawn as current findings. This revision supplies a measurement method and a clearly synthetic pool example. It does not claim to have performed a new mainnet pool census, node crawl or ownership investigation.
Mining concentration needs a block window and an attribution rule
Define the start and end heights, record the chain boundary and collect all in that inclusive window. A same-height block can change during a reorganization, so preserve block hashes rather than only a row number. Save the relevant raw evidence, the parser and the rule that assigns each block to a pool or leaves it unknown.
Coinbase tags, known payout scripts and a pool's own records can support attribution. They are not a universal ownership registry. A tag can be absent, copied or changed; a payout need not identify the owner of every machine contributing work. Record evidence and uncertainty per block instead of converting every unfamiliar tag into a confident name.
Block share over a window is an observation of block production. It is a noisy proxy for contributed work, especially over short windows; it is not a direct meter of every operator's . Self-reported pool hashrates can use different averaging periods and include separate definitions of effective or nominal work. Do not combine them with an unrelated network total as though the periods match.
Keep pool coordination separate from hardware ownership. Where a coordinator chooses the block template, concentrated coordination can create a meaningful censorship or reorganization exposure. Miners may be able to switch services, but detection, connectivity, contracts and operating choices affect that response. The name on a block does not reveal whether all its contributors are independent or whether several names share control.
A reproducible coefficient example, with unknown attribution retained
For this article's exercise, define a pool-attribution coefficient as the smallest number of attributed groups whose block counts sum to more than 50% of the complete window. This threshold is a declared definition for a production-share statistic. It is not an estimate of the cost or probability of an attack, and it does not combine mining with every other decentralization dimension.
| Attribution bucket | Invented block count | Share of complete window |
|---|---|---|
| Pool A | 420 | 42% |
| Pool B | 200 | 20% |
| Pool C | 100 | 10% |
| Pool D | 80 | 8% |
| Unknown attribution | 200 | 20% |
On the full denominator, A alone accounts for 420 of 1,000 blocks. A and B account for 620, so two named buckets cross the stated threshold. If the 200 unknown blocks are silently removed, A becomes 420 / 800 = 52.5% of the remaining sample. A careless calculation would now report a coefficient of one. The underlying invented window has not changed; the denominator has.
Unknown is also not automatically one independent pool. Its blocks might belong to A, to several smaller operators or to some other grouping. If all 200 belonged to A, that controller would account for 620 blocks. With other assignments, two groups might be required. The labels therefore cannot establish an ownership-level coefficient without more attribution evidence.
Exactly 500 out of 1,000 does not exceed this exercise's strict-majority threshold; 501 does. Published coefficients should state that convention because “50%,” “more than half” and “51%” are not identical integer cutoffs in every window. Preserve ties and grouping assumptions as well as the final integer.
Download the synthetic counts and the calculation script. Both label the example as synthetic. Their purpose is to expose denominator and attribution effects, not supply missing current measurements. David Harding's original critique of the minimum-majority measure explains why observable identities and chosen subsystems require caution.
What concentrated mining can and cannot authorize
Mining concentration concerns control over candidate block production and the ability to influence which valid history accumulates work. It must not be described as permission to sign another person's coins or to make every validating node accept an excessive subsidy. Nodes independently enforce their configured ; our consensus and reorganization guide separates valid-chain competition from invalid transactions.
A reported majority of recent blocks is not proof that the same entity can sustain a majority of future work. A short window has sampling variation, difficulty and timing effects. Conversely, a window without an observed majority does not prove the absence of common ownership or collusion. Report the observation and the threat scenario separately.
adds a separate mapping. A participating operator can reuse compatible work for LTC and DOGE, but the chains have separate targets, blocks and validation. The two production windows need not have identical pool shares. Our AuxPoW guide explains why a parent-work relationship does not imply that each accepted Litecoin block corresponds to an accepted Dogecoin block or the same payout to every miner.
Reachable endpoints are a limited view of validating nodes
A crawler observes endpoints it can discover and contact under its own network configuration. Preserve the crawl time and duration, IPv4, IPv6 and onion coverage, discovery seeds, connection rules, successful-handshake criteria and timeout policy. A count without those details cannot support a precise comparison with another crawler or another network.
The earlier claim that Tor nodes simply “do not show up” was incorrect. The reviewed Litecoin Core Tor documentation supports reachable onion services. A crawler configured for that network can observe some of them. Other nodes accept no inbound connections or are inaccessible from a particular viewpoint. Neither fact reveals the missing population's size.
Deduplicate carefully. One installation can expose more than one endpoint; one operator can run many installations; endpoints can change over time. Public reachability does not establish a unique person or an independent economic decision-maker. A single IP address can also represent hosted or shared infrastructure rather than a complete ownership story.
Geolocation and autonomous-system mapping answer further, narrower questions. An IP's registered geography may differ from a machine's physical location, and a hosting company's name is not the identity of the customer operating the node. Several endpoints in one cloud can indicate infrastructure dependence without giving that cloud ownership of their keys or a direct consensus vote.
Software diversity needs behavior and release context
A version string in a peer handshake is self-reported. It can help an operator understand compatibility, but it is not an authenticated inventory of exact binaries, independent consensus implementations or code review quality. Preserve what was observed and avoid converting an advertised client name into a claim about every line running on that host.
Compare actual supported releases, their upstream origins, security fixes, Litecoin-specific changes and the paths by which operators obtain updates. A lower-looking version number is not enough to conclude that a fix is absent; the change may have been backported. Nor does sharing ancestry mean every upstream change automatically applies to Litecoin's additional consensus and MWEB behavior.
The reviewed Core 0.21.5.8 release record is a concrete artifact for a version-specific assessment. It is not a measurement of how many nodes installed that release. The Core updates directory provides dated notices; current operator deployment requires separate evidence.
More implementations are not automatically safer. Independent validation can expose shared assumptions, while subtle disagreement can introduce consensus risk. A useful diversity report documents which rules each implementation enforces and what interoperability testing exists. Counting product names alone cannot resolve that trade-off.
Address balances do not identify ultimate owners
A rich list groups ledger value using a particular representation and cutoff. One custodian can hold coins for many customers, while one owner can distribute value among many addresses. Address concentration is therefore neither a direct beneficial-ownership census nor a voting-power distribution.
Preserve the exact snapshot, chain boundary, address or script grouping rules, treatment of tagged services and any scope limitations around confidential activity. Entity labels should carry their evidence and date. Avoid silently treating every unlabelled large address as one private or every -labelled address as a fully verified set of customer liabilities.
A corporate disclosure can establish what the filing reports at its stated date and accounting scope. It does not automatically provide a current wallet map, a present balance or ultimate control of unrelated addresses. Likewise, a founder's reported sale in 2017 does not prove the founder has acquired no Litecoin since then. This revision does not make a present-ownership claim from that historical event.
Litecoin uses . Possessing a large LTC balance does not by itself provide a proportional right to create blocks or override validation rules. Custody concentration can matter for withdrawals, service dependence and , but those are different channels from mining coordination. See the supply-definition guide before choosing a denominator for a balance percentage.
Contributor counts require a reproducible counting rule
Start with a repository, fixed revision, date window and definition of contribution. Decide whether you are counting authors, committers, reviewers, maintainers, release signers or independently funded organizations. Those groups overlap but are not interchangeable. People can use several email addresses, share organizational identities or contribute substantial review work without authoring a merged commit.
Inherited upstream history is another trap. Counting every author in a repository descended from Bitcoin does not measure the active Litecoin-specific review bench. Excluding merge commits alone does not remove upstream commits. A credible calculation needs a documented upstream comparison, identity treatment and an explicit handling of backports and imported work.
Release authority also differs from raw activity. Who can merge code, produce binaries, distribute , choose dependencies and maintain tests are separate questions. A high commit count can contain mechanical updates; a small count can contain important review or security work. Neither establishes an individual's availability in an emergency.
Funding and organizational dependence require their own dated records. Do not infer a foundation budget from repository activity or turn an informal impression of developer availability into a numeric bus factor. The earlier single-digit contributor and comparative funding claims lacked those preserved methods and are not retained as measured results.
A useful scorecard records evidence and uncertainty
| Claim | Minimum useful record | Unresolved boundary |
|---|---|---|
| Pool production is concentrated | Dated block window, hashes, attribution rules and unknown share | Hardware ownership and future ability to redirect work |
| Reachable infrastructure shares a host | Crawl coverage, deduplicated endpoints and dated ASN mapping | Unreachable nodes, customer identities and common control |
| A client dominates observed peers | Handshake observations and exact measurement period | Advertised identity versus actual binary behavior |
| Holdings are concentrated | Defined balance snapshot with evidenced entity labels | Beneficial ownership and confidential-accounting coverage |
| Development depends on few people | Fixed repository window, review and release roles, identity rules | Unrecorded work, availability and correlated funding |
There is no justified operation that adds these rows into one universal “decentralization percentage.” The denominators, units and attacker capabilities differ. A report may reasonably prioritize one threat, but it should explain that choice rather than present an unweighted mixture as an objective security grade.
Repeat observations under the same method to study change. Preserve revisions when attribution improves. If a conclusion changes because a large unknown bucket receives a name, distinguish that from a change in actual block production. Method changes can otherwise masquerade as an improvement or deterioration of the network.
What a reader or operator can verify now
A reader can ask for the frozen inputs behind a quoted coefficient and check whether unknown observations remain in the denominator. A miner can investigate who constructs its templates, what pool switching requires and which assets its payout terms cover. A node operator can validate its own transactions and choose documented software and connectivity arrangements without assuming that merely increasing an endpoint count creates an independent participant.
The full-node setup and troubleshooting guide covers verification, and local RPC. Operating a node can reduce reliance on a third party's view for the tasks you validate, but its cost depends on the actual host, network and workload. This article does not repeat the earlier blanket promise that synchronization is always cheap or finishes within hours.
The revision removes unsupported mid-2026 pool totals, node counts, ownership percentages, corporate balances and developer totals. It adds the synthetic denominator example, a reproducible worksheet and a measurement checklist. The historical source critique and versioned Core documentation support the method; they do not supply a new live Litecoin census.
Frequently asked questions
What is Litecoin's current Nakamoto coefficient?
This revision does not establish a current value. A defensible answer needs a dated population, threshold, attribution method and unknown share. The coefficient of two in the worked example belongs only to its declared synthetic counts.
Can I exclude blocks with unknown pool attribution?
Not silently. That changes the denominator and can change the result. Report the unknown share and explain whether your statistic concerns the full window or only the identified subset.
Does a pool's block share prove it owns the mining hardware?
No. It can describe observed coordination or production attribution. Hardware ownership, template selection and the ability to redirect work require additional evidence.
Are all Tor nodes invisible to crawlers?
No. Core supports reachable onion services. Visibility depends on crawler configuration and discovery, while nodes that do not accept inbound connections can remain outside that view.
Do the largest addresses control Litecoin consensus?
A large LTC balance is not a vote. Address balances also do not directly identify ultimate owners. Custody and market concentration should be assessed separately from mining and validation.
Does a high contributor count prove resilient development?
No. The count needs a fixed repository window and identity rules, and it should distinguish upstream history, reviews, maintenance and release authority. Activity alone does not measure independent control or emergency availability.
