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.
Login to reply
Replies (1)
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?