you get the utxo from from the snapshot. you dont verify anything to that point. you trust pow. that's almsot exactly like spv behavior. if a bitcoin node sees an invalid tx they blacklist that block hash because the whole block is invalid. you can't build on invalid tx. is that so hard to understand? you can't just download a utxo set and call it verified just because it was timestamped in the DAG/chain. you dont even know if the chain you are on is valid. you just pick what ever has the most pow. because you can't verify a tx from one week ago. you trust the utxoset your are given. be honest with yourself. you are claiming things that are not real. be real.

You are incorrect about the computer science of how a Kaspa node actually handles state transitions and verifies data. You are arguing against a "strawman" version of how a pruned node operates. You think a UTXO snapshot is just an unverified text file handed to you by an archival node, and you just blindly cross your fingers and accept it because it has a high Proof-of-Work score. The UTXO snapshot is not just "timestamped in the DAG", it is cryptographically bound to the BlockDAG’s virtual state. When a Kaspa node syncs, it downloads a Pruning Point Proof. This is a compact cryptographic proof. This proof mathematically demonstrates that the block header containing the hash of that UTXO set sits at the tip of an unbroken, valid chain of accumulated work leading directly back to Genesis. The node does verify the math: it verifies that creating this exact snapshot would require an attacker to expend more thermodynamic energy than the entire honest Kaspa network has produced since inception. You assume that because you aren't checking a transaction from two years ago, a miner could have sneaked an invalid transaction into the past and ruined the current state without you knowing. This completely ignores how a UTXO ledger works. You cannot "build" a valid modern block on top of an invalid historical transaction because invalid transactions destroy the mathematical continuity of the UTXO set. If a miner in 2024 tried to create fake coins out of thin air, that block would be rejected by every node online at that moment. If an archival node tried to alter the historical database to include that fake transaction and feed it to a syncing node today, the resulting UTXO Merkle root hash would change. The new node would compare the hash of the dirty UTXO set to the mathematically proven headers and say, "The hashes do not match. This snapshot is fraudulent." You don't need to read a 3-year-old receipt to know the state is valid. Yes, you pick what has the most Proof-of-Work. That is literally Bitcoin’s consensus mechanism. Nakamoto Consensus states that the valid chain is the one with the most accumulated energy. You're acting as though Bitcoin full nodes don't rely on PoW to determine the valid chain. If a Bitcoin node is presented with two chains that both follow the software rules, it always chooses the one with the most PoW. PoW is the ultimate arbiter of truth in both systems. If an attacker had the computational power to rewrite Kaspa’s history, falsify a Pruning Point Proof, forge the cumulative PoW of the global network, and trick a syncing node into accepting a fake UTXO set, they would also have the exact same power that's needed to 51% attack. You keep calling it an SPV wallet. An SPV wallet downloads headers and assumes the transactions inside are valid without checking the rules. A Kaspa pruned node downloads a cryptographically secured state and fully validates every live transaction against the rules. Bitcoin maxis have a quasi-religious belief that if a node doesn't store a record of a meme inscribed on a block from three years ago, it isn't secure. Kaspa uses math and the laws of thermodynamics to prove that the current state is valid, throwing away the historical bloat so the base layer can actually scale. You aren't arguing against a security flaw, you're just arguing against a different design philosophy Respectfully, you are claiming things that are not real, to be real.

> that block would be rejected by every node online at that moment. you are saying it yourself here "at that moment". what rejecting a change proposed by the kaspa devs looks like? what happens if miners support the change but you don't. also nothing blindly trusts PoW. but with default kaspa node if software rules changed at some point for a while you would have no idea because you dont replay those txs. you just trust what the network tells you the utxo is. if a chain has 2x of pow of your current chain in bitcoin, but has a single tx that doesn't fit into your ruleset, you wouldn't pick that chain. but with kaspa you have no idea that happened. you either have to always online to catch it, or run and verify every tx from the genesis. you can only prove everyone on the network agreed that valid utxo set looked like "this" at some point. no matter how many tricks, ideas you have not to verify txs one by one for real. none is actual verification of the tx. that's trust, not verification. you cannot meaningfully prove anything about the past. have fun complying to another hard-fork that activates "smoothly"

You claim because an installer tool like Kai streamlines node updates, the developer team completely controls the network and forces changes on everyone. You’re confusing a convenience GUI tool with consensus rules. If a tool like Kai downloads an updated node client, it is just a streamlined delivery mechanism. The operator still runs the machine. If the core developers included a malicious rule change in that update (like changing the coin supply), the node software would run, but it would instantly reject the blocks produced by miners who didn't update, or vice versa. Bitcoin has tools exactly like this. Umbrel, Raspiblitz, and Start9 are incredibly popular one-click installers that make running a Bitcoin node dummy-proof. Does everybody use these? Certainly not. Are one-click installers and argument agains a protocol… no, man. Does running a Bitcoin node via Umbrel mean you are "just a pawn to an auto-updating dev schedule"? No. It means you are using modern software convenience to run an independent consensus engine. If miners choose to run a new hard-fork update but you want to stick to the old rules, you are helpless. This is literally how Proof-of-Work works across the board, including Bitcoin. If 100% of miners switch to a new fork and 0% stay on the old chain, the old chain dies from a lack of blocks. That isn't a "Kaspa flaw", that is the fundamental reality of Nakamoto Consensus. If nobody spends electricity to mine your preferred rule set, your ledger stands still. However, if a portion of the community and miners refuse the change, the chain splits. This happened with Bitcoin and Bitcoin Cash in 2017. If Kaspa devs push a change the community hates, the exact same split occurs. The node operator always has the final say on what rules their local machine considers valid. Trusting that a historic UTXO set was agreed upon by past nodes is just a fancy social agreement, not hard cryptographic proof. This is where your pure ideological stance blindingly rejects math. A Kaspa pruned node doesn't just "take the network's word for it." It verifies a Pruning Point Proof. This is a compact, cryptographic proof of the heaviest chain headers back to Genesis. Because of the absolute unforgeable cost of Proof-of-Work, you cannot fake that proof without spending millions of dollars in real-world electricity. The node uses physics to prove that the ledger history is unbroken. You say, "You cannot meaningfully prove anything about the past." If that’s true, then cryptography as a science doesn't exist. You don't need to manually read a bank statement from three years ago to mathematically verify that a digital vault's current signature matches the ledger balance today. The math of the current state inherently contains the validated proof of everything that came before it. You're confusing user-friendly node management software with the underlying protocol consensus. Tools like ⁠mykai.dev⁠ are just the Kaspa equivalent of Umbrel or Raspiblitz on Bitcoin. If someone doesn't like or trust a manager tool like Kai, they can bypass it entirely. Anyone can go directly to the official, core Kaspa GitHub repository, download the raw source code or pre-compiled binaries written by the core development team, and run ⁠it⁠ directly from a command line terminal. Don’t lose the forrest for the trees. Your argument is nonsensical. A Kaspa node operator running a pruned ledger uses thermodynamic Proof-of-Work proofs to verify the absolute validity of the current state. It doesn't need to waste gigabytes of hard drive space hosting a museum of dead data from years ago to enforce the live rules of the network today. Bitcoin scaled by pushing users off the base layer onto centralized or clunky Layer 2s because it refused to optimize its plumbing. Kaspa optimized the plumbing using a BlockDAG so normal people can actually settle transactions on Layer 1. You don’t understand. And that’s ok. I’m used to it at this point.

I think part of your problem is you don’t understand a pruning point proof. A pruning point proof uses cryptographic sampling (similar to FlyClient/NiPoPoW architectures) to allow a node to verify the cumulative difficulty of the entire history using just headers. Because a valid modern UTXO hash can only be generated if every single transaction in history followed the rules, proving the validity of the header tip mathematically proves the validity of the snapshot state. You aren't bypassing verification; you are using math to verify the ledger state while throwing away the historical data storage. Kaspa separates enforcing the rules from archiving the past.

there is no way you can know if someone rejected something in isolation at some point. the commitment proves the utxo set is consistent with the history that was accepted. it doesn't prove that history was valid by your rules. those are different things. you still cant verify what script ran, how. the commitment proves "this utxo set is the result of this history" it does not prove "this history followed the rules you would have enforced" "this utxo is valid", valid by whose rules?

You’re failing to separate data storage from mathematical constraints. Your argument is: "If you don’t manually read the script of a transaction from 2023, you can't verify if it broke your rules." You think that a miner could have sneakily broken a consensus rule (like printing 10 million fake coins) back in 2023, and that an archival node can just hand you a modern UTXO snapshot with those fake coins in it, and your pruned node will accept it because the snapshot is "consistent" with history. That is mathematically impossible. To understand the pruning point proof, you have to look at what is stamped inside a Kaspa block header. A block header doesn't just hold arbitrary text; it contains a Merkle Root Hash of the UTXO state. Every single time a block is mined, the miner has to calculate the new state of the ledger. If a miner in 2023 tried to execute an invalid script or forge fake coins, every honest node online at that second would calculate the state change, see that it broke the rules, and reject the block. The honest network would refuse to build on it. Kaspa uses an advanced cryptographic structural backbone called a Posterity Chain (built on the principles of NiPoPoWs). Block headers don’t just point to their immediate parents. Every block header cryptographically commits to an exponential mathematical "skip-list" of ancestral block headers stretching all the way back to the Genesis block. It is a mathematically sampled backbone of history. [Genesis] ——> (skips) ——> [posterity] When your node boots up completely blank, it asks the network for the Pruning Point Proof. This file contains zero transaction data—it is purely a light chain of these interconnected, mathematically sampled Posterity Block Headers spanning from Genesis directly to the modern Pruning Point.  Your node takes this proof and puts it through a strict mathematical interrogation: -It verifies the proof starts at the hardcoded, unchangeable Genesis block.  -It hashes the headers sequentially to ensure the mathematical line is completely unbroken. -It reads the difficulty targets inside those headers and calculates the total accumulated Proof-of-Work (PoW). Because PoW requires physical energy, an attacker cannot write fake headers; they would have to burn millions of dollars in real-world electricity to generate a fraudulent proof heavy enough to fool your node.  -Once your node confirms that these headers represent the mathematically heaviest, legitimate chain in existence, it looks at the Merkle Root Hash printed inside that final Pruning Point Header. It then hashes the downloaded UTXO Snapshot. If the hashes match perfectly, the snapshot is verified. You ask: "Valid by whose rules?" Valid by the rules of the honest network that spent years of thermodynamic energy building that chain. If a miner in 2023 had printed fake coins, the honest network would have rejected that block. The heavy, legitimate posterity chain would have bypassed it entirely. If an archival node tried to alter the historical database today to sneak those fake coins into the UTXO snapshot they hand you, the Merkle Root Hash of that dirty UTXO set would change. It would no longer match the Merkle Root printed inside the mathematically proven Pruning Point Header. Your node would see the mismatch and instantly throw the snapshot in the trash. You are fundamentally confusing data availability with cryptographic verification. A Kaspa node doesn't need to read a script from 2023 to know it followed the rules, because a valid modern UTXO hash cannot physically or mathematically exist if the history preceding it contained an invalid rule change. The math of the current state is the proof of the past. The Pruning Point Proof uses a cryptographic posterity chain to prove that the snapshot you are holding is the mathematically unbroken continuation of Genesis, secured by the heaviest accumulation of physical energy on the network.

you are still thinking about someone breaking rules. not rule changes.

also no. you cant assume tx fits to your rules because of a "proof". that would be the best compression ever created. you are losing information. its impossible. as i said in the beginning "delusion of a solution"

if you wanna run a full kaspa node good luck with 2tb. and 100tb in near future

It’s clear you don’t understand cryptography or zero-knowledge logic. I’ve explained to you why you’re wrong and you’re just repeating the same wrong arguments. YOU DO NOT NEED THE DATA TO PROVE THE MATH. It really is the great paradox of Bitcoin maximalist religious zealots. They worship at the altar of mathematics and cryptography, yet they completely reject what cryptographic math is actually capable of achieving. They confuse data archiving with consensus validation. Your position is the only way to verify the state is to read every historical receipt (which you’ve never done). You need to study Merkle Trees, Polynomial Commitments, and Zero-Knowledge proofs. These proofs demonstrate with absolute mathematical certainty that a specific computational process was followed correctly, without needing to reveal or store the raw data that went into it.

"Trust the 'Science'. Even thought I don't get it fully. Because it sounds sciency~" "Just trying to prove myself right any means necessary, mentioning things that doesn't even exist in Kaspa" You just hear some stuff that you dont fully understand and, go "oh so thats why" *clueless*. THE mAth doesnt "prove" what you think it proves... Or you dont know what is suppose to be proving. you think you have some cool new solution while mentioning 40 years old papers. kaspa literally doesn't use zero knowledge proofs. it uses muhash commitments and sampled headers. which is a hash of a set. it commits to what the set is, not to how the set was derived. even if it did, zk proofs require a prover. someone generates the proof. bitcoin doesn't need a prover. i am the prover. i run the computation myself from genesis. you invoked zk proofs to sound technical. but kaspa doesn't even have them. and even if it did, it wouldn't solve the "valid by whose rules" problem. it would just move the trust to whoever generated the proof. you don't even know what the scripts are.... as a newcomer node. https://medium.com/@jcroger/why-archive-nodes-are-no-longer-essential-the-kaspa-proof-f15d3b64d24a > While you can’t prove cryptographically that pre-pruning history is valid once it’s dropped, **social consensus** ensures that if deceit happened, at least one honest node would have detected it and preserved proof. This hybrid model guarantees consistency

hashdag

In which mayday mayday we are syncing about*

About trust, civilization, and pruning block data

> The primary goal of consensus systems is **facilitating agreement, not enforcing consistency**. And if the economic majority happens to follow and maintain a ledger to which an invalid transaction entered at some point in history, so be it, > Kaspa nodes prune block data by default, and new nodes by default do not request historical data, rather, they **sync in SPV mode**, i.e., by downloading and verifying only block headers. kaspa is just the other side of the bcash coin. "fuck verifying txs, we will just have lots of txs" honestly im tried of all "lets make L1 fast" "solutions". L1 suppose to be slow and small. stop trying to walk around it.

oh btw, how much data do you spend monthly? what is the bandwidth.

You clearly have no idea what you’re talking about.

I never said Kaspa uses ZK-proofs; I used ZK and succinct blockchains as examples to smash your primitive idea that you can't verify a ledger's validity without keeping every raw text file from 2015. A Kaspa pruned node doesn't run in 'SPV mode' like a light wallet—it holds and actively enforces the full UTXO ledger state. It just uses a thermodynamic header proof to verify how that state was reached instead of buying a 2TB hard drive to host a museum of dead data. But thank you for finally being honest at the end: 'L1 is supposed to be slow and small.' That's your real argument. It's not about math or security; it's a religious dogma. You believe a blockchain has to be slow to be pure. Kaspa solved the trilemma on Layer 1 using physics and mathematics.

proof of consensus != proof of enforcement also maybe you cant understand it but "L1 should be slow" isn't dogma. it's the cost of letting anyone verify without permission. you can disagree with the tradeoff, but you didn't solve anything. everything works the same its 1+1=2 its the reality of the universe. you love using words like "thermodynamic" so much, its not so hard to understand. its not a bitcoin thing, its any system ever. you started a new kaspa node fresh: - downloads the pruning point proof (just headers, not full blocks) - checks PoW on those headers (only for ordering/consensus, not verifying the txs inside them) - checks ghostdag structure + blue work (only picks the heaviest proof, says nothing about tx validity) - downloads the UTXO set from an untrusted peer (the list of who owns what, streamed to you in chunks) - hashes that set with muhash, compares it to the `utxo_commitment` field in the header (only confirms the set matches a number a miner wrote into the header) - validates txs in the pruning point block only (that single block, against the set it was just handed) - everything before the pruning point: never executed (no scripts run, no signatures checked, data never even downloaded) what verifies what: - PoW: energy was spent on the headers - ghostdag/blue work: this proof is heavier than competing ones - muhash check: the set you received matches a number in the header - nothing: that the number was produced by valid txs following the rules the `utxo_commitment` is just a value in a header. the node confirms "the set i got matches this value." it never confirms "this value came from valid execution." consistency, not correctness. proof of consensus, not proof of enforcement. nodes will rejectrt `utxo_commitment` if: - a utxo set that doesnt hash to the value in the header, meaning someone hands you a snapshot thats been tampered with after the fact. the hashes won't match. rejected - the only thing that breaks the check is a mismatch between the bytes you received and the committed hash. basically checksum. - only way you can reject it meaningfully is you are online at that time, and see the invalid (for you) tx. and out right deny the utxo set. `utxo_commitment` doesnt enforce that the transactions which produced that utxo set were valid. its generated by the miner who mined that block. if devs pushes an update and miners mine based on it during a period. and days pass. you have no idea if it fits your ruleset or not. you just accept it because its the most pow. a fresh node goes: does my downloaded set match this hash? Yes. Accepted. it has no way to know the set contains coins that should never have existed. the `utxo_commitment` proves the set matches what was committed. it does not prove what was committed was legitimate by your rules. it catches tampering with the snapshot, not "fraud" or period of rule change baked into the history, deep enough. its trusting the work, not verification. and assuming the bandwidth a kaspa node spends, you cant have a lot of nodes that you cant easily find one that is telling you to double check that older block. if you can find a copy of the said block of course. assuming only few big cloud runners will be running a full node soon. source:

GitHub

GitHub - kaspanet/rusty-kaspa: Kaspa full-node reference implementation and related libraries in the Rust programming language

Kaspa full-node reference implementation and related libraries in the Rust programming language - kaspanet/rusty-kaspa

You just laid out the sync process perfectly, but you missed the foundational rule of cryptography: A miner cannot dictate the hash; the math dictates the hash. You claim the node just confirms the UTXO set matches the number the miner wrote into the header, without knowing if the transactions were valid. But a miner cannot just write any random number they want. The ⁠utxo_commitment⁠ is a strict mathematical result of the ledger's entire history. If a miner tried to bake fake coins into that history a year ago, every honest node online at that exact second would have rejected the block instantly. That invalid block would have been orphaned and left in the dust. The only way that 'fake coin' hash could become the heaviest, valid Pruning Point Proof handed to a fresh node today is if the rogue miners successfully sustained a 51% attack against the honest network for an entire year. Kaspa didn't abandon verification. Kaspa realized that if an honest majority enforces the rules in real-time, the resulting Proof-of-Work header chain becomes an unforgeable cryptographic proof of the valid ledger state. You don't need to turn your hard drive into a museum of ancient data to enforce the rules of the present. It’s sad to me you don’t understand this.

you dont seem to understand my point. you are still thinking about a decentralized network where one "bad guy" does something out of the ordinary. thats not about that, thats about how much you can resist "official" change. the decentralization aspect. i already mentioned your point here: > only way you can reject it meaningfully is you are online at that time, and see the invalid (for you) tx. and out right deny the utxo set. you make most pow the valid chain (pre-pruned), as long as miners wants a change, that change happens. once it happens no fresh node even with an older version rejects that chain. you just ride along. again `utxo_commitment⁠` doesnt prove the specific script was following your ruleset. it only proves utxo set was valid, and seen as valid and has been built on top of it in the past by others. not you. call it what its, which is trusting the collective, social consensus with pow. you can accept trade offs and say, "yeah i think kaspa does enough" but you dont do that. you insist that utxo_commitment⁠ and pow means verification of past txs some how. you even admit 51% attack could create invalid utxo for your ruleset. thats the definition of utxo_commitment⁠ cant verify tx was following your ruleset back then. it means there is consensus and work done to accept that history no matter it fits into your rules or not. that's compliance not verification. another example if you do a temporary hard fork that get deactivated a while later, even the freshly running old version nodes follows the hard fork chain after it deactivates. its a really simple question: Q: Do you know every TX before you is following YOUR RULES A: No but you keep arguing that "no i can verify", that's just wrong, you can only trust network in large says its good. you didnt even answered bandwidth point, even if you are are pruning you still download. and with the goal of 100bps that looks even worse. do you think someone's laptop sync with every tx ever worldwide without hogging some stuff? you also didnt answer periodic "smooth" hardfork activations kaspa has. thats not decentralization, thats a realase schedule of dev team. everybody complies to updates. node impls auto update. you can't know if history was valid, you just know history has big support. when i first asked "do you run kaspa" and you said "yes", you were wrong. you dont run kaspa. you listen to the kaspa network. illusion of a node running. if you were running it you would run it from the genesis. yes you can reject blocks as long as you are live. but unlike a bitcoin node you just accept what came before you. you TRUST others before you acted the way you hopped they would act.

You completely abandoned your original argument. You realized the cryptography works, so now you're trying to argue about human politics and hard forks. Guess what? If 100% of Bitcoin miners and developers decide to change Bitcoin's rules tomorrow, and a year passes, a fresh Bitcoin node downloading the latest software client will 'just ride along' and accept that history too. That isn't a Kaspa flaw; that is how software and social consensus work on every decentralized network in existence. And your laptop bandwidth comment proves you still don't understand pruning. A fresh Kaspa node does not download or process every historical transaction worldwide. It downloads a light header proof and the current balance sheet. It takes minutes, not days, and it doesn't hog a thing. You can keep playing philosopher and moving the goalposts, but the engineering speaks for itself. Kaspa verifies the present state using the unforgeable energy of the past. You don't need to be a historical archivist to be sovereign.

If Kaspa is a 'delusion' and the security is just an illusion of blind trust, stop complaining about it on the internet. Go attack it. Go rent some hashrate, forge a fake UTXO commitment, wrap it in a dishonest GHOSTDAG proof, and crash the network. The code is open-source. The bounty is worth a lot of money. But you won't, because you can't. You know that breaking the network requires 51%. You lost the argument on the math, so you tried to move the goalposts to human politics. You keep insisting that a Layer 1 network must be slow and clunky to be secure, but Kaspa proved that cutting-edge cryptography can separate data storage from real-time enforcement. You’re not defending decentralization anymore; you’re just an over emotional zealot that the trilemma was solved without Bitcoin.

im so sorry but are you retarded... im saying the same thing since start... and a kaspa node listens new blocks... im talking about bandwidth, not ibd time... "you realized cryptography works" i wrote why it doesn't do what you think it does. and this is what you get from it... wtf is this conversation... wtf is this. are you real. is this ragebait? your mind is completely closed to any rational explanation. and you call others "religious dogma".

learn to read. or see some professional for your medical learning disability.

go make out with you centralized crypto.

oh wait bet you have no idea what decentralized vs centralized means. you probably keep mixing decentralized with distributed

Same low iq energy as: "Oh if ethereum security is just an illusion. Go attack it. You can't"

I've given you 100 reasons you're wrong and you just can't understand. Last resort is to tell you to go prove yourself right.

you didnt give any reasons, made up arguments. its ok to not know things, you dont have to try hard to appear correct. you are constantly lying about how kaspa works and its cryptography, using meaningless jargon to appear more qualified or feel better. read the whole thread. if you are gonna support kaspa at least learn how it actually works.

Haha the AI just told you you were wrong about the math.

And sure, if you’re running no downloads on Bitcoin since 2010… give me a break.

If you don’t agree with a fork, you don’t sync. That’s flatly plain. Idk why that’s contentious.

If you don’t like the syncing node, don’t run it. It’s that simple.

Without a 51% attack, the MuHash written in the header is unchangeable, and the UTXO snapshot matching that MuHash is unforgeable. Does Kaspa have consensus at the moment? Yes. And if your argument is what happens when it doesn’t have consensus? Same as BTC in years past. Don’t run the syncing node if you’re worried about consensus.

learn to read retard

All you’ve said is that what if the Devs fork it??? Nobody can disagree! It’s just not true. I’ll say it again. Without a 51% attack, the MuHash written in the header is unchangeable, and the UTXO snapshot matching that MuHash is unforgeable. Does Kaspa have consensus at the moment? Yes. And if your argument is what happens when it doesn’t have consensus? Same as BTC in years past. Don’t run the syncing node if you’re worried about consensus.