pull down to refresh

Kaspa uses UTXO commitments:
[...] new nodes by default do not request historical data, rather, they sync in SPV mode, i.e., by downloading and verifying only block headers. [...] The node then requests the UTXO set from untrusted peers in the network, and verifies it against the UTXO commitment embedded inside the latest received header (technically, this is done against the latest pruning point). If those do not match, the node bans the sending peers, requests the UTXO set from new untrusted peers, and repeats the process. If those match, the node verifies that no unexpected inflation occurred by comparing the sum of UTXOs to the specified minting schedule, a comparison for which block headers suffice.
10 sats \ 1 reply \ @Catcher 18 Jan
The node then requests the UTXO set from untrusted peers in the network
Still don’t understand who has the utxo data if all nodes are pruned:)
reply
Still don’t understand who has the utxo data if all nodes are pruned:)
Me neither ;) I guess it has something to do with their pruning points. Kaspa nodes store only the last 3 days of historical data and the UTXO set and the nodes do not rely on even one single archival to fully sync.
reply