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

Disposable accounts storage keys #3053

Closed
grarco opened this issue Apr 10, 2024 · 1 comment
Closed

Disposable accounts storage keys #3053

grarco opened this issue Apr 10, 2024 · 1 comment

Comments

@grarco
Copy link
Collaborator

grarco commented Apr 10, 2024

Currently, when unshielding to a disposable account, the operation ends up writing a balance of 0 in storage (which in turn ends up being diffed and merklized). Since these addresses shouldn't really be reused it would be slightly better to not write anything in storage (the default is 0 anyway).

We could think about doing this with a custom check in the unshielding operation to decide if anything should be written, even though this might not be that simple since a disposable account is indistinguishable from a normal one and would probably require us to examine its subspace.

An alternative could be to not unshield but just consume the spend notes and leave the amount in the masp balance from which we could then move it to the block proposer. This would require a change in the masp vp logic to allow this kind of operation which at the moment is forbidden.

In any case, this should be evaluated together with #2597 and #1677.

@grarco
Copy link
Collaborator Author

grarco commented Jun 4, 2024

Nevermind, after the introduction of tx batches, unshielding directly to the masp balance is exploitable by a malicious user who could extract the unsigned fee payment transaction and apply it before the "original" transaction. If the fee-paying masp transaction is unshielding enough funds (e.g. it's the first tx of a batch), the attacker could use it to pay fees for their own transactions, effectively stealing funds from the original fee payer. This is not possible in the current implementation where we always take the fees from the transparent balance of the wrapper signer (even in case of a masp fee payment), cause the attacker would not be able to produce a valid wrapper signature for their malicious tx.

@grarco grarco closed this as completed Jun 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants