Feature request: Implicit transaction nonces for idempotent transactions

[MitchK]

We currently write a lots of transactions per account (storing hashes in a smart contract) and sometimes have the problem that a transaction cannot be executed for arbitrary reasons, for example if the gas price is too low.

Following transactions depend on this "non-executable transaction" because of the transaction nonce. If the transaction times out and gets discarded, any following transactions then have to be signed again by the issuer with a lower nonce in order to go through.

For our use case, there is no big harm if the issuer is able to write the same hash to the contract twice - the transaction issuer will just lose a little bit of Ether to pay for the gas.

It would help if one could set the transaction nonce to a value "derived" or "implicit", which basically means "determine the nonce of this transaction based on the nonce of the previous account state". This transaction nonce could be determined by the miner.

I understand that you probably don't want this in a case where you transfer value from one account to a other, meaning, when you replay a transaction, the outcome would be different (i.e. resulting in a higher balance on the other person's account).

[infamousrev]

The nonce is also to offer replay protection, if you signed transaction number x, then you only gave permission to include transaction number x.

I understand you don't mind if the transaction gets included twice, but would you still be fine with the transaction being included 10000x (wasting all your ether on gas)?

The account abstraction that will be implemented in the next hardfork might allow for more complicated use cases like the one you mentioned, but the trade-off between functionality and security is a delicate one.

[karalabe]

The nonce is part of the data being signed by the sender, so in the current form the miner can in no shape or form change it (or any other field on the transaction). Account abstraction might help with your usecase as @infamousrev mentioned, but you need to put your thoughts down on the relevant EIP (ethereum/EIPs#86) to have it discussed and considered.