That’s not how pruned nodes work. The claim that a pruned node "doesn't replay anything" is fundamentally false. A Kaspa pruned node absolutely does validate and replay blocks within the pruning depth window. It independently calculates consensus for all current traffic; it just throws away old historical data after it has been finalized by the network's cumulative Proof-of-Work.
A pruned node verifies the current heaviest chain/DAG headers. For an archival node to successfully feed a "lie" (a fake UTXO snapshot) to a newly syncing pruned node, an attacker would have to secretly mine a fake history with more accumulated Proof-of-Work than the entire real global Kaspa hashrate.
You’re just wrong because you don’t understand. And that’s ok. I’m used to that.
Kaspa has thousands of nodes. Counting publically available and saying that’s the totality is dishonest. Public nodes alone have spike over 1,000. The high throughput guarantees this. You have to cut latency. You’re making an assumption that’s illogical I counting only public nodes. Solo mining is the point.
Peer connections aren't a hidden vulnerability that breaks the cryptography of the network. It is a bottleneck, to be sure, but it doesn’t upend the project.
StackSatsRaiseFamily / WildBill
npub1nt…0m38t
2026-06-07 00:46:11 UTC
in reply to nevent1q…ejn7
Author Public Key
npub1ntlexmuxr9q3cp5ju9xh4t6fu3w0myyw32w84lfuw2nyhgxu407qf0m38tPublished at
2026-06-07 00:46:11 UTCEvent JSON
{
"id": "77de3245d180289137f349ec81fb0b2368c74a9d2edb44cd60dc81cecf72b1d0",
"pubkey": "9aff936f8619411c0692e14d7aaf49e45cfd908e8a9c7afd3c72a64ba0dcabfc",
"created_at": 1780793171,
"kind": 1,
"tags": [
[
"e",
"82c26fb39fd189f205f24f9a36afbf0f59611d236af61e313fd16826ac701632",
"",
"root",
"9aff936f8619411c0692e14d7aaf49e45cfd908e8a9c7afd3c72a64ba0dcabfc"
],
[
"e",
"e08c5e0f1fbe64de90d91aee1263019d994abafe074ceca5df23306fc4b9ef33",
"",
"reply"
],
[
"p",
"45835c36f41d979bc8129830f2f5d92562f5343d6feddd6f30aa79480730f26e",
"",
"mention"
]
],
"content": "That’s not how pruned nodes work. The claim that a pruned node \"doesn't replay anything\" is fundamentally false. A Kaspa pruned node absolutely does validate and replay blocks within the pruning depth window. It independently calculates consensus for all current traffic; it just throws away old historical data after it has been finalized by the network's cumulative Proof-of-Work.\n\nA pruned node verifies the current heaviest chain/DAG headers. For an archival node to successfully feed a \"lie\" (a fake UTXO snapshot) to a newly syncing pruned node, an attacker would have to secretly mine a fake history with more accumulated Proof-of-Work than the entire real global Kaspa hashrate.\n\nYou’re just wrong because you don’t understand. And that’s ok. I’m used to that. \n\nKaspa has thousands of nodes. Counting publically available and saying that’s the totality is dishonest. Public nodes alone have spike over 1,000. The high throughput guarantees this. You have to cut latency. You’re making an assumption that’s illogical I counting only public nodes. Solo mining is the point. \n\nPeer connections aren't a hidden vulnerability that breaks the cryptography of the network. It is a bottleneck, to be sure, but it doesn’t upend the project. ",
"sig": "cf9132ddfd450c4f80130e652e2a63c4da06a30432d082ae26320e4ad5f4d893f47eb116cf14a9e935681d46ec571a8baa09f024fa9a6b1667e7a7265e724473"
}