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

Disallow empty treasury withdrawals #4582

Open
lehins opened this issue Aug 28, 2024 · 3 comments · May be fixed by #4630
Open

Disallow empty treasury withdrawals #4582

lehins opened this issue Aug 28, 2024 · 3 comments · May be fixed by #4630
Assignees
Labels
conway intra-era-hardfork A task that requires an intra-era hard fork

Comments

@lehins
Copy link
Collaborator

lehins commented Aug 28, 2024

Currently a TreasuryWithdrawal action can contain an empty map, which would result in a proposal that does nothing. This does not have any dangerous implications, but it doesn't make sense to have TreasuryWithdrawals that has no affect, especially since it has confused some developers in the past: IntersectMBO/cardano-cli#876

We should add a predicate failure that prevents TreasuryWithdrawals with Maps that sum to 0 ADA. This would not only prevent empty withdrawals, but also the ones that don't try to withdraw any funds.

@lehins lehins added conway intra-era-hardfork A task that requires an intra-era hard fork labels Aug 28, 2024
@lehins
Copy link
Collaborator Author

lehins commented Aug 28, 2024

CC @WhatisRT and @williamdemeo I don't think we need to have a matching predicate check in the spec, but wanted to let you know that we are planning to implement a predicate failure like this.

@WhatisRT
Copy link
Contributor

With these types of things I wonder if it'd be a good idea to implement some granularity for predicate failures. I.e. ones that affect block validation and ones that trigger when a node verifies individual transactions for the mempool, possibly functioning more like a warning. Then you could just add this to the next version without a HF. In general that would make it much easier to patch issues like that. You wouldn't get guarantees that these transactions don't exist, but that's not an issue for downstream tooling since it needs to handle the possibility of such situations in the era before they are fixed right now anyway.

@lehins
Copy link
Collaborator Author

lehins commented Sep 10, 2024

With these types of things I wonder if it'd be a good idea to implement some granularity for predicate failures. I.e. ones that affect block validation and ones that trigger when a node verifies individual transactions for the mempool, possibly functioning more like a warning

@WhatisRT I've opened a ticket for a potential solution like this: #4622

@teodanciu teodanciu self-assigned this Sep 12, 2024
@teodanciu teodanciu linked a pull request Sep 18, 2024 that will close this issue
9 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
conway intra-era-hardfork A task that requires an intra-era hard fork
Projects
Status: To do
Development

Successfully merging a pull request may close this issue.

3 participants