6

When sending new transactions one at a time (meaning separated by 1 or several minutes in time) they are correctly broadcasted and mined. But when sending several of them one after another (spearated by just a few seconds) most of them are lost. Geth node confirms reception of the transaction, but blockchain Ropsten do not show them.

Here it is a set of transactions, most of them not available at Ropsten:

I0421 14:23:57.216680 internal/ethapi/api.go:1107] Tx(d83896adacd210a545d8bc53be2672d2bbb535cd6fd93fc6d74dcafb24c047ea) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:41.739022 internal/ethapi/api.go:1107] Tx(c6002dc6a3b28b6caba7ed7cb143d79147dc705437ccf70e267a4b2379f7920d) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:08.040512 internal/ethapi/api.go:1107] Tx(dcaa2a36ca4e2c5c3377e6b1f72d127242b4556c001efc3aca38c980c4e4c333) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:07.542375 internal/ethapi/api.go:1107] Tx(dcaa2a36ca4e2c5c3377e6b1f72d127242b4556c001efc3aca38c980c4e4c333) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:23:01.623979 internal/ethapi/api.go:1107] Tx(c70976a147e3e268131b0ed2be4555277371f439bbfe641ed1c55acaeec725eb) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:54.749671 internal/ethapi/api.go:1107] Tx(c3089a845110a871713bead6b71984ac5053cf4c2a3baa864e7ba0cf4499280b) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:49.069954 internal/ethapi/api.go:1107] Tx(fb629dc7f75b9ad486fd48afe3838c093567463d850b19c867c58520420eb9e7) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:35.357242 internal/ethapi/api.go:1107] Tx(1cae8925fb57971c126f37d2cef98f71696523cd109b7359f2f5845f1f05ca6a) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:24.175374 internal/ethapi/api.go:1107] Tx(9aceebdb23c4542ea5469d4cf05cc3ee7bddc7ea55fdae05ea63c45c9e581a70) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:16.787944 internal/ethapi/api.go:1107] Tx(7a2d0660aeec7698328e1e1ee96ecc929f4f6323fd22c5a337c92995bf88b4cf) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:08.852178 internal/ethapi/api.go:1107] Tx(73e7586a05ed17f1acb21fae93806349334881393c4493d4c708e3a902cd16c6) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:22:01.956836 internal/ethapi/api.go:1107] Tx(2ded9002531b59dd7c42dcb2a51ab420be555d8c7a26269334c24ce8971e1b6e) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df
I0421 14:21:53.184982 internal/ethapi/api.go:1107] Tx(9a9ac63a5d7b061b1597892f63a906c195c258c66b81e8d2f943ca9b5664f314) to: &ce8efd03766a309af57ddeb9c79f3e7cd23da0df

For example, 

https://ropsten.etherscan.io/tx/0x2ded9002531b59dd7c42dcb2a51ab420be555d8c7a26269334c24ce8971e1b6e

says "Unable to locate Transaction entry".

Meanwhile others such as:

https://ropsten.etherscan.io/tx/0x9aceebdb23c4542ea5469d4cf05cc3ee7bddc7ea55fdae05ea63c45c9e581a70

have been mined successfully.

How can I find out where and why those transaction became lost? Any idea how to debug the process?

Refs.:

Transaction stuck since yesterday

Transaction mined or not?

Improve this question
4
  • 1
    Could you share some more details, are you connected to peers? Are you fully synchronized? What Geth version are you using? Are you using Ropsten or Ropsten-Relaunched?
    – q9f
    Apr 24, 2017 at 9:02
  • Geth version 1.5.9 . Yes, admin.peers returns 64 peers. Fully synchronized because log shows same last block as ropsten.etherscan.io I gues it is plain Ropsten.
    – Juan Ignacio Pérez Sacristán
    Apr 25, 2017 at 8:21
  • 2
    How are you creating the transactions? Specifically, how are you assigning nonces?
    – Péter Szilágyi
    Apr 25, 2017 at 9:27
  • Transactions are created and signed using ethereumJS lib through a remote geth node via JSON-RPC. Nonces are queried with Web3.js calls to the node.
    – Juan Ignacio Pérez Sacristán
    Apr 28, 2017 at 14:17

2 Answers 2

Reset to default
3
+150

Multiple transactions sent from one account during a single block may not necessarily be received or mined in the order sent. The nonce for each transaction increases but a miner must invalidate a transaction of a lower nonce than previously received. If they are mining out of order, then older transactions (by seconds) might be invalidated.

Improve this answer
3
  • Does it mean there is no guarantee for a transaction to be mined once broadcasted?
    – Juan Ignacio Pérez Sacristán
    Apr 25, 2017 at 14:05
  • 2
    Transaction nonces are strictly sequential. There cannot be gaps. So this answer is false, the miner cannot mine them in any other order than their sequence defined by their nonce.
    – Péter Szilágyi
    Apr 25, 2017 at 15:25
  • 2
    @Péter Szilágyi Yes nonces are strictly increasing when sent, so where a miner receives a nonce > nonce+1, then that miner drops the TX right? So when a miner receives TX's out of order which is possible due to propagation delay, then won't it drop TX's until it sees one with nonce+1?
    – o0ragman0o
    Apr 25, 2017 at 22:09
2

You need to check if you are on the correct chain, you might happen to be on some wrong chain. Try eth.getBlock(blockNumber) and compare the return blockhash with etherscan.

If yes, from the geth console, can you try using eth.pendingTransactions() to see if these transactions are listed as pending on your machine.

If yes, try admin.peers to see if you are connected to any peer. If yes, try:

var tx = eth.pendingTransactions()[index], and replace index with the index of the transaction you want to rebroadcast. Then:

eth.resend(tx, <optional gas price>, <optional gas limit>).

Doing this will allow you to rebroadcast the transactions to your peers (should set higher gas price).

Improve this answer
4

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.