grin icon indicating copy to clipboard operation
grin copied to clipboard

Revisit "uniqueness" constraints on kernels in transactions and blocks

Open antiochp opened this issue 5 years ago • 0 comments

We currently enforce uniqueness across inputs, outputs and kernels in both transactions and blocks. This is checked via verify_sorted_and_unique(). This is done by kernel hash so two kernels with the same hash are prohibited in the same transaction or block.

We also enforce NRD rules (if NRD is active) and this prevents two NRD kernels with the same excess commitment from existing in the same transaction or block.

There is some inconsistency here as we define uniqueness on both hash and excess commitment in different contexts.

We may want to consider adjusting the uniqueness rules in verify_sorted_and_unique() to take both hash and commitment into consideration when looking at kernels in a transaction or block.

For kernels in transactions and blocks -

  • verify sorted by hash
  • verify unique by hash
  • verify unique by excess commitment

Note this is related to "duplicate outputs" https://github.com/mimblewimble/grin/issues/3271 discussion. If we permit "duplicate outputs" in the UTXO then we may (and likely will) want to allow duplicate outputs (and presumably duplicate inputs) within a transaction or block. So we will want to verify that the full set of outputs are sorted, but loosen the restrictions on uniqueness etc.

So we may well end up loosening uniqueness constraints on inputs and outputs, but tightening uniqueness constraints on kernels in transactions and blocks.

antiochp avatar Jun 27 '20 13:06 antiochp