This is proposal made by @mr-tron after analysis of risks for Tonkeeper Battery service coupled with signed internal messages in W5 wallet.
In principle, the wallet should not bounce incoming messages as to avoid returning deposits back to the sender due to opcode misinterpretation. However, specifically for "gasless" transactions (signed messages relayed by a 3rd party), there is a risk for the relaying party to be abused: their coins should be bounced back in case of a race condition or delays.
We resolve this dilemma by silently failing during signature check (therefore ordinary deposits with arbitrary opcodes never bounce), but failing with an exception (therefore bouncing) after the signature check.
Verification step
Behavior
Opcode check
Fail silently
Signature check
Fail silently
Seqno check
Exception & bounce
Subwallet check
Exception & bounce
TTL check
Exception & bounce
The downside of this solution is that wallet may emit bounced messages produced on purpose by trolls who reuse old signatures and send malformed, but well-signed messages to trigger bouncing. These bounced messages may clutter history and "recent" addresses in the wallets that do not check the "bounce" flag. Mitigation is simple: such operations should be filtered out as spam, just like the "0 ton" incoming transactions.
This is proposal made by @mr-tron after analysis of risks for Tonkeeper Battery service coupled with signed internal messages in W5 wallet.
In principle, the wallet should not bounce incoming messages as to avoid returning deposits back to the sender due to opcode misinterpretation. However, specifically for "gasless" transactions (signed messages relayed by a 3rd party), there is a risk for the relaying party to be abused: their coins should be bounced back in case of a race condition or delays.
We resolve this dilemma by silently failing during signature check (therefore ordinary deposits with arbitrary opcodes never bounce), but failing with an exception (therefore bouncing) after the signature check.
The downside of this solution is that wallet may emit bounced messages produced on purpose by trolls who reuse old signatures and send malformed, but well-signed messages to trigger bouncing. These bounced messages may clutter history and "recent" addresses in the wallets that do not check the "bounce" flag. Mitigation is simple: such operations should be filtered out as spam, just like the "0 ton" incoming transactions.