Since transactions require a nonce that is one more than the previously mined transaction for a given address, what happens if someone sent a transaction with a low gas price that was refused by miners? They would have all subsequent transactions refused unless they were given the same nonce and a more favourable gas price.
[Ethereum] Transaction nonce management
noncetransactions
Related Solutions
- Then does this indicate that the same address can NOT send two transactions at the same time?
No. It indicates that you cannot send two transaction with the same nonce from the same address.
- As the nonce is the number of transactions sent from a given address, may I just increase the number of nonce when sending the second transaction?
Yes.
- However I don't think it is possible to know which transaction will be mined firstly, so it confuses me that I can not determine which transaction should be given a higher nonce.
I think (if someone could confirme or correct) it is the first one that gets mined. But I'm not sure at all because that miners' configuration migth have an influence on that.
From @Зелёный in the comments, you could set an higher gas price in one of yoru transaction so that it is processed before the other one. You then don't have to worry about nonce anymore.
I haven't yet got to the point where I can test any of these things, but my gut feel is that the Singleton Nonce Manager would be the way to go, with a few enhancements:
- Make it a singleton transaction sender
- That has a maximum buffer or 'head' of pending transactions per 'from' address that matches or is less than the maximum number of transactions that the peer can have in its transaction pool queue per from address. Let us call these pending transactions 'slots.'
- Is implemented as a rolling queue, where oldest, confirmed transaction are deleted from the 'tail'.
- Each new slot gets a new nonce
- Each new slot is associated with an asynchronous call to sendRawTransaction. On failure of any kind, the slot becomes free.
- Any new transactions are added to the lowest free slot.
- In the event that the higher slots are pending for more than N milliseconds after a slot is freed on error, cancel the highest transaction by sending 0 eth to self with same nonce as highest slot nonce, and replaying that transaction in the freed slot.
The implementation details would require intimate familiarity of concurrent programming, locks, mutexs, async or whatever. Essentially the above is a guess as I have not worked directly yet with the RPC calls and cannot test it, but I think that's the bare bones of the route I would go. I see that the queue structure would offer an internal API for listing pending transactions, processed, and supporting other UI operations as a bonus.
Best Answer
You're correct that all subsequent transactions would be refused.
So with Geth, you can rebroadcast with a higher fee (gas price) by using
eth.resend
(the nonce will remain the same).eth.resend(tx, optional gas price, optional gas limit)
Example: