I have a simple idea following the proposal Idea to fix both play and replay attacks.
As it appears (see the corresponding thread), this proposal enables to link outputs and inputs to kernels, which is something that we don’t want for Grin. Nonetheless, I want to use an idea from it, and directly apply it to the previous kernel uniqueness constructions.
The idea is to “funnel”
signature_block_height: live validating nodes only accept fresh transactions entering the network that have a
signature_block_height contained between
current_block_height - 1 and
current_block_height + 1, and treat the others as invalid.
Similarly to the other kernel uniqueness methods, the miner joins
relative_height = inclusion_block_height - signature_block_height to the kernel when he includes it in the blockchain, which allows users to verify the signature of the historical kernels.
Verifying kernel uniqueness is insured by live validators, and they can do it using a small moving window of
3 blocks. Uniqueness check should not be performed at ibd.
The proposal disables all play and replay attacks wthout using mempool expiry because once in there, kernels can wait in it as long as they wish. Output uniqueness doesn’t need to be verified. Pruning nodes can prune the historical kernels. It is scalable and it provides essentially the same privacy and the same UX guarantees as today, plus an optimal security for the blockchain users since no play attacks can be performed on them due to the short validity of
signature_block_height and no replay attacks can be performed due to the uniqueness check.