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

[CHIA-2419] Handle RESERVE_FEE differently with identical spend aggregation #951

Draft
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

Rigidity
Copy link
Contributor

No description provided.

Copy link
Contributor

@arvidn arvidn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this core logic is correct. We would need tests and I think it would be nice to avoid having to do this in consensus mode (where the SpendVisitor is EmptyVisitor)

@@ -1540,6 +1542,33 @@ pub fn validate_signature(
Ok(())
}

pub fn check_deduplication(ret: &mut SpendBundleConditions) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

all other dedup logic is implemented in the MempoolVisitor, to only have it active in mempool mode, and not consensus mode. It seems we create a new visitor for every spend, and it doesn't really have a view of the whole bundle. I think it's worth trying to think of ways to tie this check to the visitor still.
worst case check_deduplication() could be a "static" function in the SpendVisitor trait. but maybe be called something like spend bundle post processing.

@@ -1540,6 +1542,33 @@ pub fn validate_signature(
Ok(())
}

pub fn check_deduplication(ret: &mut SpendBundleConditions) {
let mut non_dedup_removal_amount = 0;
let mut non_dedup_addition_amount = 0;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it would make me a bit less nervous to specify these types as u64

@arvidn arvidn changed the title Handle RESERVE_FEE differently with identical spend aggregation [CHIA-2419] Handle RESERVE_FEE differently with identical spend aggregation Feb 26, 2025
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.

2 participants