Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Revisit "uniqueness" constraints on kernels in transactions and blocks #3370

Open
antiochp opened this issue Jun 27, 2020 · 0 comments
Open

Comments

@antiochp
Copy link
Member

antiochp commented Jun 27, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant