Does Geth guarantee consistent snapshot of state in a RPC batch?

[alexhanh]

System information

Geth version: 1.4.7-stable-667a386d
OS & Version: OSX

Expected behaviour

Using sendRawTransaction reliably requires computing the proper nonce. This requires knowing previous transaction count of the from address, as well as checking pending and queued transactions of the from address.

AFAIK, this means that we need to call getTransactionCount(tx.from) and txpool_content to compute the final nonce (nonce = tx_count + pending_count + queued_count).

Since we need to use two calls, it's possible the state gets mutated in between the calls and thus we compute the wrong nonce:

Batched RPC call of [getTransactionCount, txpool_content] ---> Geth

1. getTransactionCount(tx.from) returns 0
2. (... Geth processes a block and clears the txpool, and now previous step would return 1 ...)
3. txpool_content is now empty and returns 0 pending/queued transactions. Application computes the final nonce of tx_count (0) + tx_pool_count (0) = 0 and the tx gets rejected (the nonce should have been 1).

If the state isn't guaranteed (which is what I suspect, since it would seem silly to halt all processing because of RPC calls), then how on earth are we able to consistently produce the proper nonce?

Actual behaviour

Unknown.

[bas-vk]

This is indeed a hard problem. In theory the node cannot give you all required information to determine the correct nonce since it might not have all pending/queued transactions in its transaction pool. Batched RPC calls are just an optimization to reduce the number of separate RPC calls. Your assumption is correct. The requests are still executed one by one and and affected by state changes.

@Arachnid, if I recall it correct you did some work on adding Ethereum support for trezor. Maybe you can share your thoughts?

[drewshaver]

It seems to me the most straightforward approach would be calling getTransactionCount(addr, 'pending'). Which is supported according to the json-rpc docs. But it does not seem to be actually working for me, or this other person from stack overflow.

[Arachnid]

Trezor support was naive, and just fetches the transaction count, on the theory that you're not going to be signing transactions by hand that fast. :)

[fjl]

The correct way is indeed to use getTransactionCount(addr, 'pending'). I'm closing this now because #2880 tracks the issue with that call.