You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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" #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.
The text was updated successfully, but these errors were encountered:
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 -
Note this is related to "duplicate outputs" #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.
The text was updated successfully, but these errors were encountered: