search

kaspanet / kaspad

Kaspad was the reference full node Kaspa implementation written in Go (golang), now rewritten in Rust: https://github.com/kaspanet/rusty-kaspa
ISC License
467 stars 230 forks source link

Solve time-based relative timelocks after pruning headers #1753

Open svarogg opened 3 years ago

svarogg commented 3 years ago

The current situation is that the UTXO-Set only remembers the output's DAAScore.

Then if the output has a time-based relative timelock, kaspad searches over the selectedParentChain to find the relevant block, and retrieve it's timestamp. Once pruning headers is implemented, we no longer will be able to find such blocks the moment they are out of the pruning window, rendering the whole feature useless.

Possible alternatives:

  1. Disable relative time-based timelocks. Some might argue that relative time-based timelocks are a redundant feature anyway. Either DAA-score based timelocks or absolute time-based timelocks can be used in all real-life situations. This might be correct, but requires further research to make sure there are no valid use-cases. There's a general feeling of "we don't know why it might be used, but it definitively should be available"

  2. Add AcceptingBlockTimestamp to UTXOEntry. This will solve the problem, and is not very complicated, but adds ~10% more data to the UTXO-Set - a constrained resource to start with.

hashdag commented 3 years ago

Disable for now, revisit post mainnet