Make transaction order flexible

[rmeissner]

Currently the transactions need to be executed in strict order of the nonce (as a normal ethereum transaction). This was done to save gas and to ensure that specific actions (adding owners/ removing owners/ changing threshold) don't get mixed up.

By adjusting that adding/ removing owner increments/ decrements the threshold by 1 instead of allowing to specify the threshold can prevent issue with potential owner changes mess ups (see formal verification for details)

If the order of transaction is important (which normally means that the transactions depend on each other) then batched transactions should be used.

The increase in gas costs can be minimized to a couple thousand gas by using a bucket based strategy (each storage slot can store up to 256 flags for used nonces).

[tschubotz]

By adjusten that adding/ removing owner increase/ decrease the threshold instead of allowing to specify the threshold can prevent issue with potential owner changes mess ups (see formal verification for details)

You mean for those actions, the nonce cannot be an "out of order" nonce, but rather an incremental one, right?

[rmeissner]

For clarification here an example scenario:

Let's assume you have a Safe with owners A, B, C and threshold 2
If you now have 2 transactions:

• Add D and increase threshold to 3
• Remove C and reduce threshold to 1

It has different end states depending on the order you execute them in.
If you change the logic of these transactions to:

• Add D and increase threshold by 1
• Remove C and decrease threshold by 1

Then the endstate is fix no matter what order you execute them in (and the state change of each single transaction is the same as before)

[rmeissner]

Solutions used by any.sender contracts: https://github.com/anydotcrypto/metatransactions/blob/master/src/contracts/account/ReplayProtection.sol

[RenanSouza2]

@mmv08 is this something you would like to be persued for release 1.5?

[mmv08]

No, because this is a breaking change. We're also tens of bytes away from the code size limit, so this would be impossible to include.