Disposable accounts storage keys
grarco opened this issue · comments
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.
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.