You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
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.
The text was updated successfully, but these errors were encountered: