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

feat!: fix kernel mutability #4377

Merged

Conversation

SWvheerden
Copy link
Collaborator

@SWvheerden SWvheerden commented Aug 2, 2022

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.

let mut challenge = Challenge::new()
.chain(sum_public_nonces.as_bytes())
.chain(total_excess.as_bytes())
.chain(u64::from(fee).to_le_bytes())
Copy link
Collaborator

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

Copy link
Collaborator

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

Copy link
Member

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

Copy link
Member

@sdbondi sdbondi Aug 4, 2022

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()

stringhandler
stringhandler previously approved these changes Aug 3, 2022
integration_tests/log4rs/base_node.yml Outdated Show resolved Hide resolved
let mut challenge = Challenge::new()
.chain(sum_public_nonces.as_bytes())
.chain(total_excess.as_bytes())
.chain(u64::from(fee).to_le_bytes())
Copy link
Member

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

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");
Copy link
Member

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();

@SWvheerden SWvheerden force-pushed the sw_fix_kernel_mut branch 4 times, most recently from 317c0c1 to 39b535d Compare August 4, 2022 14:17
fix kernel mutability
update to rather use consensus bytes directly on features
Add in mempool validation of burn
@stringhandler stringhandler merged commit d25d726 into tari-project:development Aug 4, 2022
@SWvheerden SWvheerden deleted the sw_fix_kernel_mut branch August 5, 2022 06:26
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

Successfully merging this pull request may close these issues.

None yet

3 participants