Default avatar
npub1ntle...m38t 1 month ago
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.
↑ Parent

Replies (1)

nomadshiba⚡⚡'s avatar
nomadshiba⚡⚡ me@nomadshiba.me 1 month ago
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.
1 replies ↓
↑