Allow non-sequential transaction nonces

[davidyuk]

The reason to have nonce as I know

• to have different transaction hashes if we are doing the same action multiple times;
• be able to define a sequence of transaction execution.

From my experience, most transactions are atomic, e.g. I don't care in which order they would execute in the nearest 10 minutes. In these cases, I can use just a random nonce, to don't sync with the node, to don't resign transactions in mempool made after the failed one. This would speed up batch transaction sending, and won't require syncing between multiple processes that send transactions on behalf of the same account.

If I need to specify transaction order, instead of sequential nonce I can refer by hash to the transaction that should be mined before this one. This way would be possible to do multiple NamePreclaim -> NameClaim in parallel.

[marc0olo]

I think this is in general an interesting request.

This way would be possible to do multiple NamePreclaim -> NameClaim in parallel.

this example is bad because the NamePreclaim only exists for front-running protection. if we want to get rid of front-running protection, then we need to remove NamePreclaim completely and anyway have only NameClaim left.

if you broadcast both in parallel, the front-running protection is lost.

[hanssv]

It is an interesting idea - but one I am not sure how to implement efficiently?! You'd still want nonces to be unique, right? (Or else it would be trivial to re-run profitable transactions) That means we need to store all used nonces for an account?

[marc0olo]

I think it is a little bit of overkill and can be solved on client side, too. (it maybe is already for the "normal usecase"

NamePreclaimTx is a special case anyway where the following NameClaimTx will only be considered valid if a new keyblock is mined.

[dincho]

Sequential transaction order is very important for double spending If I'm not mistaken

[dincho]

In general, using single account for parallel transactions in multiple processes sounds like a bad idea that does not fit the nonce idea.

Clients should track nonces as well as batch processors/multiple processes IMO.
Users should be encouraged to use separate addresses for different wallets as well.

Using the node/API a nonce lock/sync mechanism also sounds wrong to me. An app should sync once (i.e. during startup) and keep track of the nonce.

[davidyuk]

You'd still want nonces to be unique, right? (Or else it would be trivial to re-run profitable transactions)

Sequential transaction order is very important for double spending If I'm not mistaken

It is enough to ensure that the node won't apply transactions with the same hash multiple times. I don't see a problem if transactions with different fields would have the same nonce. So we don't need unique nonces, but transaction hashes.

I think it is a little bit of overkill and can be solved on client side

It can be, but random nonces would be easier to use.

Clients should track nonces as well as batch processors/multiple processes

Currently, it doesn't work well using sequential nonces #3803

[hanssv]

A random nonce would make the TX considerably larger, not sure that is preferrable - and at the end of the day the node would have to check for TX-uniqueness either by storing all Tx-hashes and checking or by storing something per account. Just mentioning the downsides.
Also with random nonces, how would you make sure that two transactions are applied in the correct order if that actually is necessary. 🤔

[davidyuk]

A random nonce would make the TX considerably larger

It can be an arbitrary-size value so the user may decide its size. Also it can be used as a sequential nonce but without validation on the node side. Aepp can set nonce to 1 for each transaction and increase it only in retry in case tx hash is already taken (also it can increase fee the same way 🙃).

If we create 100k transactions with the same fields and 5-bytes nonce then the probability to get the same tx hashes (nonces) about 0.5% according to https://bdayprob.com (it appears to be tricky to calculate by myself).

Regarding reducing transaction size I would propose to do denomination in a way to make gas price equal 1 e.g. to have 9 decimal digits instead 18. This way we would save ~7 bytes for each SpendTx 😃

the end of the day the node would have to check for TX-uniqueness either by storing all Tx-hashes and checking

Isn't node already doing it? There is an endpoint to get a transaction by hash, so it is not expensive. Node can check if the hash of posted transaction is already registered and reject it if so. Probably it already works this way.

by storing something per account

I don't see it necessary

Also with random nonces, how would you make sure that two transactions are applied in the correct order if that actually is necessary.

I have two approaches:

1. we can add a flag to tx specifying whether is it a sequential nonce or random
2. if necessary, tx can include a hash of the transaction that should be mined before, so multiple independent sequences can be defined (mentioned in the first post)

I see that overall we discussing significant changes in the protocol, but I'm not sure that the value would be the same significant. At last, the next we would have issues with nonces I would refer to this thread :D

[hanssv]

There is no uniqueness check for transactions as far as I know? @velzevur or @uwiger can correct me here, maybe? It could be done, I guess, but I'm not convinced it is a great idea.

Side note: Wouldn't you save ~3 bytes on the denominator change? (1 byte to store 1e9 instead of 4) - then, the protocol allows for 1e6 as the minimal gas, so I guess that should be the denominator. But, that is a good, though separate improvement suggestion I think.

[davidyuk]

Yep, I've counted 3.5 bytes for the amount and the same for fee of spend tx. 7 bytes overall.