Incorrect NC for Nano

[rachel-bousfield]

Nano's consensus algorithm is defeated with 33% corruption, not 67% as the API Nakaflow is blindly trusting implements on the backend.

What's more, addresses from the same legal entities (like exchanges) are being treated as separate to inflate the count. On top of this, the Nano Foundation itself works with exchanges to distribute weight, making it appear like the network has a better NC than it does.

I think it's only reasonable to remove the coin given this info. The chart isn't accurate, and the true NC is much smaller (two years ago when I checked, it was literally just 2-3 exchanges depending on deposit outflows).

[xenowits]

Thanks for flagging this, @rachel-bousfield !

@nano2dev @BrazyDevelopment Could you confirm the accuracy of the data from https://nanocharts.info/data/nanocharts.json? Also, what does data.Stats.C1s.N represent?

[kilkelly]

Hi @xenowits , NanoCharts developer here. The data.Stats.C1s.N figure correlates to the Basic/Safety view of the following pie chart here: https://nanocharts.info/p/01/vote-weight-distribution

Rachel is incorrect in the assessment that entities are treated as separate. To the best of our ability representatives with the same owner are grouped into Entities (which you can view by mousing over the chart and seeing which slices have an [ENTITY] label. This cannot be determined by analyzing raw network data so we have to manually perform the groupings which is not guaranteed to be 100% accurate. Known groupings can be viewed here.

IMHO it is subjective whether Nano's consensus algorithm is defeated with 33% vote weight dominance. 33% would allow for stalling/censorship (choosing not to process certain transactions) if exploited but does not allow for double spends.

Hope this helps. Let me know if there are further questions 👍

[BrazyDevelopment]

Hey @xenowits, thanks for looping in - happy to break this down for you and @rachel-bousfield with the full context of my code.

@rachel-bousfield, you’re pointing out that my Nano code - specifically my Nano() function - leans on NanoCharts’ API at https://nanocharts.info/data/nanocharts.json for the Nakamoto Coefficient, grabbing data.Stats.C1s.N directly instead of calculating it ourselves.

You’re calling that “blind trust”.
My code is built to fetch that NC value because NanoCharts already nails it, pulling live voting weight from Nano’s blockchain and distilling it into c1s.n - the smallest number of reps needed to hit 67% of online weight. That’s not blind; it’s deliberate efficiency.

Check the snippet:

package chains

import (
    "encoding/json"
    "log"
    "net/http"
)

type NanoStats struct {
    Stats struct {
        C1s struct {
            N int `json:"n"`
        } `json:"c1s"`
    } `json:"stats"`
}

func Nano() (int, error) {
    chartsURL := "https://nanocharts.info/data/nanocharts.json"
    resp, err := http.Get(chartsURL)
    var data NanoStats
    json.NewDecoder(resp.Body).Decode(&data)
    nakamotoCoefficient := data.Stats.C1s.N
    return nakamotoCoefficient, nil
}

It’s lean - hits the endpoint, parses the JSON, and pulls Stats.C1s.N.

Why?

NanoCharts tracks Nano’s ORV in real time, and their NC matches what I’d get if I fetched every rep’s weight, sorted, and summed to 67% myself.
Reinventing that in Go would mean syncing a node, polling reps, and crunching it - doable, but overkill when this data’s already on-chain and vetted.
I’ve cross-checked it with NanExplorer; you are welcome to do the same - it holds up.

Your 33% corruption claim:

Nano’s ORV needs 67% online weight to confirm - 33% dropping out might stall transactions if enough reps go offline, but it’s not “defeating” the network like you imply.
Double-spends still can’t happen; you’d need 67% for that. NanoCharts doesn’t bake a stall figure into the JSON data as it is calculated client-side on the webpage. - its C1s.N sticks to the consensus threshold, which is what my code cares about.
Whether 33% amounts to a big deal is subjective, but it’s not a flaw in the API or my logic - it’s just Nano’s design under stress.
Please read the Nano Documentation on ORV Consensus

Exchanges inflating counts?

Irrelevant - NanoCharts gives me weight per rep, not address fluff, and C1s.N counts entities by weight share.

Foundation distributing weight?

That’s just delegation dynamics in the data - not a conspiracy - mine/NanoCharts code doesn’t care who’s behind it, it takes the NC as-is. You said NC was 2-3 two years ago? NanoCharts showed ~7 in 2023, and it’s climbed since - Stats.C1s.N tracks that live.

@rachel-bousfield, C1s.N isn’t a black box; it’s Nano’s pulse, and my code’s just tapping it. If you have case, with evidence where it’s off, then let’s dive in. Otherwise, I believe this setup’s doing its job.

Reponse to @xenowits:

nanocharts.json is accurate - blockchain-sourced, community-trusted.
data.Stats.C1s.N is the NC my code relies on - number of reps controlling 67% weight. It’s what Nano() returns, and it’s consistent with Nano’s design.
If we wanted to compute it ourselves, I’d need to run my own node, pull raw rep weights and loop through - happy to prototype if you think it’s worth it, but NanoCharts’ feed keeps us fast, aligned and cost free. Thoughts?

@xenowits, one note - you might not recall, but @rachel-bousfield has a history of pushing questionable claims about Nano, even contributing to its delisting from Nakaflow once before.
They’ve been very vocal with Nano skepticism and they are well known in the Nano community for this because it's effortless to recognise an anomaly in a community that is typically aligned, so it’s worth considering the pattern here.
Their take’s not new - it’s just dressed up in different clothes.

Looking forward to your feedback - have a great day, both of you!

@BrazyDevelopment

[rachel-bousfield]

33% Is the Only Reasonable NC

With 33% of the stake, you can arbitrarily censor the network, denying the movement of funds. You even permanently freeze accounts to where even if you lost the 33%, the address couldn't make transactions. In such a case validators would need to meet up on the official Discord to decide whose ledger to manually adopt, node-by-node.

In fact, this has happened before! For most of nano's development, nano was vulnerable to a rather trivial double spend attack vector. Because the node would look for 51% when confirming blocks — and importantly validators change their votes during consensus — it was possible to cement both sides of a fork. We even saw this happen on mainnet. People had to manually intervene to fix several accounts for this reason during the spam of 2020.

Because of this failure of the consensus algo, ORV was adjusted to instead require 2/3rds to confirm blocks in a new "final votes" stage that acts after the main one. This means now that you only need 1/3rd to disable accounts on the ledger like you used to be able to do with 0% of the stake. What's remarkable though is that after this event, the community tried to spin this as a good thing, that the NC was now 67% of the stake, and not 51% as it used to be.

What should be clear in the above, is that it's not really a "subjective" thing as those here are saying. We all know an actor getting 33% of the stake would be a disaster. I also don't appreciate people telling me to "look into ORV" while pointing at docs that don't actually explain how the algorithm works in any detail. I'm one of the two who found that double spend vector in the first place 😉

Not Accounting for Splits

With 33% out of the way, let's talk about another way Brazy's tool is misleading. Nano is unusual in that an attacker actually has two vehicles for getting to 33%: their coins, and their weight. This means that a more complicated algorithm is necessary than the traditional "identify the entities and add up to 33%". In fact, this is why my original PR to add nano to Nakaflow performed two passes.

This means there's two actors that can potentially use any given coin: the one who owns the coins, and the one to which the coins have been delegated.

For example, Binance used to delegate about 1/8th of the entire nano stake to my validator. During those months, both me and Binance could have use that 5% to corrupt the network. Brazy's tool ignores this scenario entirely, which is one of the downsides of just blindly trusting an API: they can just make decisions to inflate the NC they never ran by you.

Question of Relevance

Another thing to consider is if it's worth listing coins outside the top 100. According to CoinGecko, nano is now rank 324. When a coin is small, the central developers tends to run the show. For example, the foundation told Binance to re-delegate to their partner project, 465 Digital Investments (now defunct). When new docker images are published, everyone just updates.

One problem with even calculating an NC for such small coins is that it obscures these community dynamics. If the foundation told all the exchanges to delegate to them, or to run some malicious node software, it's pretty straightforward that they would. This is untrue for large networks like Ethereum, however, which split their stake over several competing node implementations and providers.

[BrazyDevelopment]

Your 33% NC Claim is Off-Base

You insist 33% is the “only reasonable NC” because it could censor or freeze accounts, forcing manual Discord fixes.

That’s a misrepresentation.

Nano’s ORV demands 67% of online weight for consensus - that’s the final votes threshold, period.
Sure, 33% abstaining could stall transactions by choking quorum, but it’s not “defeating” the network.
It can’t double-spend or permanently lock accounts - 67% is required to control the ledger.

Your “validators meet on Discord” bit is a dramatic what-if; nodes resync to the honest majority in practice, not some ad-hoc powwow. @kilkelly confirms this: their data.Stats.C1s.N - what my code pulls - tracks the “Basic/Safety” NC at 67%, not your 33% stall scare.

Stalling’s a nuisance, not a knockout.

You lean on the 2020 spam and a double-spend bug - nodes confirming at 51% with vote-switching forking the ledger.
Yeah, that was a flaw, and it got fixed - ORV bumped to 67% final votes to kill that vector.
Your twist that 33% now “disables accounts like 0% used to” is nonsense - the old issue was consensus mechanics, not weight alone, and 67% today stops double-spends dead.

The NC isn’t 33%; it’s 67%, as NanoCharts’ pie chart backs up.

You’re peddling outdated fears as current truth.

Splits and Delegation Don’t Break My Tool

You argue Nano’s coin-weight split - owners vs. delegates wielding stake - makes my tool “misleading” by missing dual actors (e.g., 5% colluding with a delegate). Your two-pass PR had a point back then, but my Nano() function:

func Nano() (int, error) {
    chartsURL := "https://nanocharts.info/data/nanocharts.json"
    resp, err := http.Get(chartsURL)
    if err != nil { return 0, err }
    defer resp.Body.Close()
    var data NanoStats
    if err := json.NewDecoder(resp.Body).Decode(&data); err != nil { return 0, err }
    return data.Stats.C1s.N, nil
}

pulls Stats.C1s.N - a single-pass NC from NanoCharts based on delegated weight hitting 67%. It’s not “blind trust”; it’s scoped to active voting power, not theoretical owner-delegate schemes.

As @kilkelly says they group same-owner reps into entities (check the chart’s [ENTITY] labels), countering your “separate entities” jab - they’re not perfect, but it’s not raw data chaos either. My tool doesn’t tackle splits because it’s not meant to - that’s a node-level analysis, not Nakaflow's job. If C1s.N inflates anything, show me the gap with hard numbers - I’m not buying your speculation.

The Bigger Picture

Your historical disgruntlement with Nano clearly fuels this - you’ve got a grudge, and it’s clouding your take. My code’s not misleading; it’s built to grab Nano’s NC as NanoCharts delivers it - a solid 67% metric, not your 33% doomsday. You’re wrong to pin any quirks on my implementation when your real issue is the network you soured on.

@xenowits - this is why nanocharts.json works for me:

It’s blockchain-sourced, manually grouped for accuracy, and keeps Nakaflow lean. Rachel’s 33% stall and split theories don’t undo Stats.C1s.N - they’re just edge cases my tool isn’t chasing. If you need a custom implementation, I can look into it, but this holds firm.

Cheers!

[rachel-bousfield]

33% Is the Only Reasonable NC, Part 2

First, let me just point out that everyone showing up on discord to get the "official" ledger this isn't just theoretical. This literally happened in 2020 and it took months for some accounts to be fixed, requiring manual intervention as validators asked for the correct ledger. A few nodes even corrupted their databases, requiring us to clone JayyCox's ledger.

Second, it's clear Brazy doesn't understand how nano's consensus algo works, which is a bit concerning for someone asking you to trust his API. Since the nano docs don't explain it (despite people asking for years -- another issue for coins outside the top 100), I'll go ahead and describe how voting works.

Nano consensus takes two stages:

1. Validators each vote on the side of the fork they believe has the majority (could be ephemeral, votes change)
2. Validators then vote a second time, broadcasting the side they'd like to cement

Stage 1 is pre-threshold. Stage 2 requires 67%. Once a validator enters Stage 2, it never changes its vote.

This is a problem: it means if you can't get 67% of the stake on one side of the fork in Stage 2, your account is stuck. A node will refuse to broadcast votes for the opposite side, and its database will not update without manual intervention. This is true even if one side has a slight majority like 60% and the other 40%. This means you only need 33% to make this happen, since that's the threshold after which you can induce majorities like 60-40 or 66-34.

Remember, 100% - 67% = 33%. That 33% is all you need to ensure 67% never happens, and that nodes sit on opposing sides of a fork, forever stuck in Stage 2. Even if you lose this weight, the validator remains stuck, unable to make progress.

The Need for Robust APIs

I'm glad Brazy has at least admitted he doesn't check for the rep splitting case I mentioned. You can call these "edge cases", but in a world where the foundation tells exchanges who to vote for, I think it's only reasonable to demand robust methodologies.

We need to stop trusting and instead start verifying this stuff. That might be intractable for small coins like nano, but I think Nakaflow should still set a really high bar when telling people how healthy a set of validators is. People trust these kinds of numbers when figuring out if a coin is legit, and misleading choices act more as a marketing opportunity for the given chain than a dispassionate public resource.

[BrazyDevelopment]

33% Is the Only Reasonable NC, Part 2

First, let me just point out that everyone showing up on discord to get the "official" ledger this isn't just theoretical. This literally happened in 2020 and it took months for some accounts to be fixed, requiring manual intervention as validators asked for the correct ledger. A few nodes even corrupted their databases, requiring us to clone JayyCox's ledger.

Second, it's clear Brazy doesn't understand how nano's consensus algo works, which is a bit concerning for someone asking you to trust his API. Since the nano docs don't explain it (despite people asking for years -- another issue for coins outside the top 100), I'll go ahead and describe how voting works.

Nano consensus takes two stages:

1. Validators each vote on the side of the fork they believe has the majority (could be ephemeral, votes change)
2. Validators then vote a second time, broadcasting the side they'd like to cement

Stage 1 is pre-threshold. Stage 2 requires 67%. Once a validator enters Stage 2, it never changes its vote.

This is a problem: it means if you can't get 67% of the stake on one side of the fork in Stage 2, your account is stuck. A node will refuse to broadcast votes for the opposite side, and its database will not update without manual intervention. This is true even if one side has a slight majority like 60% and the other 40%. This means you only need 33% to make this happen, since that's the threshold after which you can induce majorities like 60-40 or 66-34.

Remember, 100% - 67% = 33%. That 33% is all you need to ensure 67% never happens, and that nodes sit on opposing sides of a fork, forever stuck in Stage 2. Even if you lose this weight, the validator remains stuck, unable to make progress.

The Need for Robust APIs

I'm glad Brazy has at least admitted he doesn't check for the rep splitting case I mentioned. You can call these "edge cases", but in a world where the foundation tells exchanges who to vote for, I think it's only reasonable to demand robust methodologies.

We need to stop trusting and instead start verifying this stuff. That might be intractable for small coins like nano, but I think Nakaflow should still set a really high bar when telling people how healthy a set of validators is. People trust these kinds of numbers when figuring out if a coin is legit, and misleading choices act more as a marketing opportunity for the given chain than a dispassionate public resource.

Hey @rachel-bousfield, your “Part 2” is a parade of shaky claims and finger-pointing - let’s dismantle it piece by piece and show why you’re dead wrong about my code, Nano’s consensus, and Nakaflow’s purpose.

Your 2020 Discord Sob Story Doesn’t Prove 33%

You kick off with the 2020 spam mess - Discord scrambling, months to fix accounts, nodes cloning JayyCox’s ledger after corruption. Fine, that happened - Nano got slammed, and it was ugly. But waving that around as proof 33% is the NC today is a bait-and-switch. That was pre-ORV fix, when 51% consensus and spam broke everything. The shift to 67% final votes patched that - your “manual intervention” nightmare isn’t the norm now. Nodes don’t need Discord to pick an “official” ledger unless the network’s totally shattered, which 33% can’t pull off. You’re cherry-picking history to prop up a flimsy point - it doesn’t fly.

Your ORV Breakdown is a Bust

You swagger in claiming I don’t get Nano’s consensus, then serve up a two-stage voting lecture to “school” me. Nice try, but you’re the one fumbling it.

You say:

• Stage 1: Validators vote on the fork side they think has majority (votes shift).
• Stage 2: They lock in with 67%, never changing.

Then you spin this tale:

If Stage 2 can’t hit 67%, accounts are “stuck forever” - nodes refuse to vote opposite, databases freeze, even at 60-40 splits, so 33% kills it.

That’s a gross distortion.

ORV’s Stage 1 narrows the fork; Stage 2 needs 67% online weight to cement it. If no side gets 67%, nodes don’t just sit there twiddling thumbs - they keep voting, or honest weight tips it over time.

Your “forever stuck” fantasy ignores how nodes resync to the majority ledger when quorum’s reached.

A 60-40 split? The 60% grinds forward; 33% can’t lock it down unless the other 67% vanishes, which isn’t realistic.

Your “100% - 67% = 33%” math is cute but meaningless - 33% doesn’t “ensure 67% never happens”; it delays it until weight aligns.

@kilkelly nails this: data.Stats.C1s.N (https://nanocharts.info/p/01/vote-weight-distribution) is the 67% NC - stalling’s a hiccup, not defeat.

My Nano() function:

func Nano() (int, error) {
    chartsURL := "https://nanocharts.info/data/nanocharts.json"
    resp, err := http.Get(chartsURL)
    if err != nil { return 0, err }
    defer resp.Body.Close()
    var data NanoStats
    if err := json.NewDecoder(resp.Body).Decode(&data); err != nil { return 0, err }
    return data.Stats.C1s.N, nil
}

pulls that 67% NC - not your 33% fiction. You’re mad the docs don’t spoon-feed ORV? Cry to the Foundation - my code’s not here to rewrite them.

Splits and Your “Robustness” Whine

You gloat that I “admitted” skipping rep splits - owners and delegates dual-wielding stake. I didn’t admit a flaw; I said it’s not necessary. I reiterate; NanoCharts groups same-owner reps into entities (check their **[ENTITY]** labels) - your “separate entities” jab was trash.

The code takes C1s.N’s single-pass NC - delegated weight at 67%.

A two-pass owner-delegate check? That’s node-level sleuthing - tracing wallets, ballooning costs - Nakaflow's not your personal blockchain cop.

Show me a split jacking up C1s.N - you’ve got nothing but hot air.

Trust, Verify, and Your Real Agenda

You preach “stop trusting, start verifying” - lofty, but hollow. Nakaflow’s bar is high enough: nanocharts.json is blockchain-sourced, grouped for accuracy, and lean. You say it is a “marketing opportunity” for Nano, but that’s your Nendly grudge talking - you tanked there when the community ditched your node, and now you want Nano delisted.

The API’s not misleading; it’s purpose-built, pulling a legit 67% NC. You calling it a sham, paired with your delisting fetish and bitter history, just proves my point - you’re not critiquing, you’re crusading.

People trust these kinds of numbers?

They should - they’re real, not your 33% fever dream.

@xenowits, Rachel’s 2020 flashbacks and fork fables don’t crack my setup - Stats.C1s.N holds at 67%, backed by NanoCharts data. Her “robustness” nag is noise - my code’s solid for what it does.

Cheers!

[rachel-bousfield]

33% is the Only Reasonable NC, part 3

There's a reason they're called "Final" votes, and it's because they're final. Validators can never switch sides after casting one. The world should hope Nano doesn't work the way Brazy thinks it does, since that would enable the 33% to create ephemeral majorities in Stage 2 just like in Stage 1, cementing double spends.

Now Brazy is just going to tell us again that I'm wrong and ORV is solid and that we should just trust the dev team. After all, Brazy just acknowledged that there's no protocol specification for this chain. You can kinda just believe whatever you want about it, cause nobody in nano really knows how the coin works aside from a select few.

And on top of that, the foundation hopes to replace ORV consensus with a completely different mechanism like "Vote Pulses" in hopes of one day making the chain "commercial grade" (their words, not mine).

Given all that, it's just not the right thing for end users to be told "nano requires 12 independent actors to corrupt" because it's just not true. It takes no more than 33% of the stake, or even just the foundation telling exchanges to upgrade to a malicious software client.

Maybe one day when Nano has a public protocol spec, the stake split over multiple clients, and public audits (recall that the foundation doesn't do security audits) -- then Nakaflow could actually show a number. But for now, this coin being rank 324, it's just too dangerous to assign a number and thus endorse the chain.

I think we're looping at this point and the conversation is no longer productive. I'm not really interested in reading insults all day. @xenowits it's up to you, I think I've made a really compelling case based on facts and not ad hominem. I invite you to reflect on the arguments and make a decision.

[BrazyDevelopment]

33% is the Only Reasonable NC, part 3

There's a reason they're called "Final" votes, and it's because they're final. Validators can never switch sides after casting one. The world should hope Nano doesn't work the way Brazy thinks it does, since that would enable the 33% to create ephemeral majorities in Stage 2 just like in Stage 1, cementing double spends.

Now Brazy is just going to tell us again that I'm wrong and ORV is solid and that we should just trust the dev team. After all, Brazy just acknowledged that there's no protocol specification for this chain. You can kinda just believe whatever you want about it, cause nobody in nano really knows how the coin works aside from a select few.

And on top of that, the foundation hopes to replace ORV consensus with a completely different mechanism like "Vote Pulses" in hopes of one day making the chain "commercial grade" (their words, not mine).

Given all that, it's just not the right thing for end users to be told "nano requires 12 independent actors to corrupt" because it's just not true. It takes no more than 33% of the stake, or even just the foundation telling exchanges to upgrade to a malicious software client.

Maybe one day when Nano has a public protocol spec, the stake split over multiple clients, and public audits (recall that the foundation doesn't do security audits) -- then Nakaflow could actually show a number. But for now, this coin being rank 324, it's just too dangerous to assign a number and thus endorse the chain.

I think we're looping at this point and the conversation is no longer productive. I'm not really interested in reading insults all day. @xenowits it's up to you, I think I've made a really compelling case based on facts and not ad hominem. I invite you to reflect on the arguments and make a decision.

Hey @rachel-bousfield, let’s settle this with facts.

“Final Votes” Don’t Make 33% King

You say ‘Final votes’ are final - validators can’t switch after Stage 2 - and claim my view would let 33% cement double-spends like Stage 1. That’s a wild misread. Nano’s ORV has two stages: Stage 1 picks a fork with fluid votes; Stage 2 locks it at 67% online weight. Once a validator casts a final vote, it’s set - but if 67% isn’t reached, nodes don’t freeze into chaos. They keep polling until quorum hits, or honest weight resolves it. Your 33% can’t “create ephemeral majorities” in Stage 2 - 67% is the bar, and double-spends need that, not 33%. As @kilkelly confirmed above: data.Stats.C1s.N is the 67% NC (https://nanocharts.info/p/01/vote-weight-distribution) - stalling’s possible, not ledger control. You’re twisting mechanics to fit your narrative.

I Get ORV - You Don’t

You accuse me of not understanding Nano’s consensus, then wave a lack of “protocol specs” like it’s my fault.

I don’t need to decode ORV’s soul; I’m reporting its health as-is. You say “nobody knows how Nano works” except a few - yet you’ve got no evidence my 67% NC is off.

33% Isn’t 12 Actors or a Delisting Trigger

You scoff at “12 independent actors” (Nano’s current NC per NanoCharts ) and cry 33% - or the Foundation rigging exchanges - breaks it.

Wrong again.

NanoCharts groups same-owner reps into entities (**[ENTITY]** labels on the chart) - not “separate” as you’ve claimed. My API reflects delegated weight at 67%, not your 33% stall fantasy or a Foundation coup. No audits, “Vote Pulses” looming? That’s Nano’s roadmap, not my metric’s flaw.

Rank #324 doesn’t make the NC “dangerous” - it’s data, not an endorsement.

Robustness Isn’t Your Call

You harp on rep splits and “trust vs. verify” saying Nakaflow’s number misleads because I don’t chase owner-delegate games. That’s not a flaw - it’s scope. A two-pass NC needs node-level tracing - costly and pointless when C1s.N nails delegated reality. You’ve got no proof it’s skewed - just gripes about Nano’s ecosystem. My bar’s high: accurate, lean, verifiable data. You want delisting because the Nendly node flopped and you can’t let go - not because my number’s bunk.

Finally, you say I’ve insulted you “all day" - I’ve been sharp, sure, but it’s been technical critique in defence of my work that I spent time to create, not personal jabs. If you perceived anything as ad hominem, then I apologise, it only had relevance to the points I was making. If calling your arguments shaky or your Nendly bias relevant stings, that’s on you - I’m here to debate your "issue", my code and consensus, not coddle. In your own words, you are the "Architect of Nano's ruin".

@rachel-bousfield named her node this before she shut it down.

[RockmSockmJesus]

Hi, I'd just like to jump in here and state my support for Rachel's points. Despite what many in the Nano community would like, this was and still is a vulnerability to the consensus algorithm, AFAIK.

This was an issue while I was deeply involved with the NF in 2018-19, and I don't believe much has changed in this regard since.

[BrazyDevelopment]

Hi, I'd just like to jump in here and state my support for Rachel's points. Despite what many in the Nano community would like, this was and still is a vulnerability to the consensus algorithm, AFAIK.

This was an issue while I was deeply involved with the NF in 2018-19, and I don't believe much has changed in this regard since.

Hey @RockmSockmJesus!

Instead of opinion, would you please mind adding some value here and explaining why you support Rachel's points and why/what it is still a vulnerability/issue? And what leads to you believe that much hasn't changed since?

[BrazyDevelopment]

I just want to point out that no one has yet to address Rachel's point which is about the official nano documentation not containing any low level details about ORV. Regardless of who's correct, this fact alone makes the nano community not look good. Let's do better.

Hey @bernwo, Rachel’s gripe about Nano’s docs lacking ORV details isn’t the point here - this thread’s about my Nakaflow code, not the community’s paperwork. If she - or you - want to push that fight, take it to Nano’s docs repo and back it with evidence there.

I’m stepping back from this thread now - it’s veering into Nano FUD territory instead of sticking to the actual issue with my code. I’ve defended ORV’s 67% NC beyond what’s needed - if you’ve got gripes with Nano itself, that’s not my lane.

Tag me if there’s a legit code issue, and I’ll jump back in.

@xenowits, check @kilkelly’s and my relevant comments above - they cut through the noise on this. Hope that helps you sort it out!

[rachel-bousfield]

@bernwo Yes, unlike Ethereum and larger coins within the top 100, nano does not have a protocol spec. This means anyone can claim anything about it, and there's no real research literature on the protocol. On Ethereum, Solana, etc there's a myriad of scientific papers analyzing the consensus algo, asking questions like "what if an actor had X% of the stake and insert advantage". It's well understood what the right NC cutoffs are. For nano, the scientific community is totally unaware as to how it works. When I was a PhD student studying consensus algos, none of my colleagues had even heard of ORV.

If next year Brazy came back and told @xenowits "actually it's 99%, not 67%" (although he'd more likely just silently update his API to have more favorable number), then who's to say he's wrong? I'd ofc insist he's wrong about how consensus works, but then his whole discord community would show up here, bigrade/downvote the entire discussion, and act like they proved points they hadn't.

It is only people shilling nano on twitter who advocate for 67% NC. Everyone else knows it's 33%, the threshold by which manual intervention on the official Discord is necessary, and databases are ruined. And that's only if we don't count the foundation as an actor, who has a history of picking the validators for exchanges to use, in which case the NC is really just 1.

[dalindev]

"the Nakamoto Coefficient is defined by the number of node operators that, together, control more than one third (33.33%) of all stake on the network."

For Nano, this is 33% to stall and 67% to double spend.

[rachel-bousfield]

@dalindev I know this thread is being sent around the nano community in hopes of getting your way by brigading the post, but you're not adding anything to this discussion.

33% permanently freezes funds and requires everyone show up on discord to manually pick the correct ledger. If that's not a total failure of consensus, I don't know what is. The whole promise of blockchain is for things to just work autonomously and not need manual recovery.

[NanoForEver]

Just saw this on Discord, and I have to say, the more I scrolled, the more pissed off I got. Rachel seriously needs to drop this and move on. We all know that three entities control more than 33% of all Nano, and yes, we all know that if they collude, transactions could be censored or frozen. But come on, Nano already has a terrible reputation, and we desperately need this win to make us look better than the others and in turn attract new investors.

All the nano fudders keep talking about how the NF has completely run out of funds and shut down, how they lost the lawsuit against Coinbase, and we keep getting spammed. We've been dragged through the mud enough already. Just let us have this one, @xenowits.

We can really set ourselves apart from other coins in this discussion if we ignore censorship and solely focus on double spends.

[BrazyDevelopment]

@dalindev I know this thread is being sent around the nano community in hopes of getting your way by brigading the post, but you're not adding anything to this discussion.

@rachel-bousfield
The person that sent it in Discord is @bernwo - the same person that reiterated your point.
Nobody is "brigading" the post for support.

Shall we just leave it here? As you said, it's becoming unproductive.

[ThrowAwayLouisa]

Note: NanoForever is an account which joined Github 45 minutes ago and does not speak for the Nano community.

[NanoForEver]

????
I’m on your side, @ThrowAwayLouisa. I don’t have a GitHub account because I’m not a coder, but that doesn’t mean my opinion is any less valid. I’m part of the Nano community, and it’s my only holding—so excuse you if you think I don’t speak for the community.

Anyway, this entire discussion was derailed from the start by Rachel, who jumped straight into technical rambling to sideline everyone with an opinion but without coding experience. That’s not what this is about. The real discussion is whether the 33% threshold applies to us or not—because we know stalling and censorship can happen at 33%, but we’re saying it doesn’t matter in the same way it does for Bitcoin operators. I constantly use this argument on Twitter and Reddit. Stop pretending this is some kind of technical debate when the reality is simple: Nano is simply better.

[xenowits]

Hey all,

Appreciate the thoughtful debate from all sides. I see valid reasoning for both 33% and 67%, but without full context, it's hard to determine the right threshold.

That said, one thing is clear: @BrazyDevelopment, let's update the Nano code to compute NC properly rather than just pulling data.Stats.C1s.N from a remote API. This will make validator weights and thresholds explicit for anyone reviewing the code.

Apologies for not catching this earlier - Nano is the only chain that doesn't calculate cumulative voting power nor references a threshold, which lacks transparency. Let's fix that first. You can refer to how other chains handle this here: (https://github.com/xenowits/nakomoto-coefficient-calculator/tree/main/core/chains).

As for the threshold (33% vs 67%), let's keep it at 67% for now. This is v1 of Nakaflow, and as pointed out, it doesn’t yet account for factors like stalling, censorship resistance, frozen accounts, double spends, or fork selection. These will be key considerations in v2, where we can incorporate multiple metrics for a more comprehensive view.

Lastly, to clarify: Nakaflow is a free and open-source project focused solely on measuring blockchain decentralization - it has nothing to do with coin performance.

cc: @dalindev @RockmSockmJesus @rachel-bousfield @kilkelly