-
Notifications
You must be signed in to change notification settings - Fork 220
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
feat!: fix kernel mutability #4377
feat!: fix kernel mutability #4377
Conversation
79a8b1d
to
5607786
Compare
let mut challenge = Challenge::new() | ||
.chain(sum_public_nonces.as_bytes()) | ||
.chain(total_excess.as_bytes()) | ||
.chain(u64::from(fee).to_le_bytes()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would be better to chain(features.to_consensus_bytes())
kind of thing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I thought the features were a substruct like in the output. I suppose this is fine
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that we should use consensus encoding and domain-separated hashing here.
Might need to wait for #4381
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
#4381 is merged
You can now write something like:
DomainSeparatedConsensusHasher::<TransactionHashDomain>::new("kernel")
.chain(sum_public_nonces)
.chain(total_excess)
.chain(fee)
.chain(lock_height)
.chain(features)
// NOTE that you can (and should) pass `Option`s into consensus hashing
.chain(burn_commitment)
.finalize().into()
let mut challenge = Challenge::new() | ||
.chain(sum_public_nonces.as_bytes()) | ||
.chain(total_excess.as_bytes()) | ||
.chain(u64::from(fee).to_le_bytes()) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would say that we should use consensus encoding and domain-separated hashing here.
Might need to wait for #4381
222caef
to
ce34eb4
Compare
const KEY = null; // optional key | ||
const OUTPUT_LENGTH = 32; // bytes | ||
const context = blake2bInit(OUTPUT_LENGTH, KEY); | ||
const buff = Buffer.from(publicNonce, "hex"); | ||
const buff2 = Buffer.from(publicExcess, "hex"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I added a DomainHasher class in JS
let hash = new DomainHasher("com.tari.yada.yada.kernel")
.chain(buff).chain(buff2)
// etc.
.finalize();
317c0c1
to
39b535d
Compare
fix kernel mutability update to rather use consensus bytes directly on features Add in mempool validation of burn
39b535d
to
3a2dead
Compare
Description
Currently, the kernel has a mutability issue where the public excess, features, and new optional burn commitment is not committed to in the challenge.
See issue: #4365
This is a breaking change as it changes every single kernel signature.
This changes the challenge for the kernel to include those fields. Because the kernel fields need to be signed by all parties, these needs fields must be decided at the start of the transaction. This required changes to the tx protocol as well.
How Has This Been Tested?
Running all current unit tests and all critical cucumber tests.