3

I'm running a private network with one miner and I have the problem that if I send too many transactions from a node, those transactions are not getting mined.

For example: If I send one transaction every 6 seconds, then not a single transaction gets mined. If I send one transaction every 30 seconds then everything works fine.

I send a transaction with nodejs like this:

instance.myFunction(data, {from: account.address, gas: 4000000}, function(error, result) {
// do something
});

The transactions just pile up and not getting mined by the miner.

Here are for example two transactions:

> eth.getTransaction( '0x1e06fec8994ee38a32b2438d51b57c9d4bc95239c45322d58a4a9f0c8a03be4a')
{
  blockHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  blockNumber: null,
  from: "0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12",
  gas: 4000000,
  gasPrice: 18000000000,
  hash: "0x1e06fec8994ee38a32b2438d51b57c9d4bc95239c45322d58a4a9f0c8a03be4a",
  input: "0x4ee27fa900000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006313530313331393039383234343b343000000000000000000000000000000000313530313331393039393234383b323400000000000000000000000000000000313530313331393130303235323b353500000000000000000000000000000000313530313331393130313235363b373700000000000000000000000000000000313530313331393130323236313b393100000000000000000000000000000000313530313331393130333236353b313800000000000000000000000000000000",
  nonce: 107,
  r: "0xe761ccc9db6d387eadba7bcb93dac6c582f8baf052da76eaff828e5b91c1722d",
  s: "0x571f99554f299d551bb05bb6145210a6480c015b42604f9bd885de6eea94dbcb",
  to: "0x8e195493424d416300f8b61b01145956345cd914",
  transactionIndex: 0,
  v: "0x42",
  value: 0
}
> eth.getTransaction('0x02e09d88360c27f6da92075a8ab1f8e2bb23bca149004a3d134048492348677d')
{
  blockHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  blockNumber: null,
  from: "0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12",
  gas: 4000000,
  gasPrice: 18000000000,
  hash: "0x02e09d88360c27f6da92075a8ab1f8e2bb23bca149004a3d134048492348677d",
  input: "0x4ee27fa900000000000000000000000000000000000000000000000000000000000000200000000000000000000000000000000000000000000000000000000000000006313530313331393130343331353b343000000000000000000000000000000000313530313331393130353331373b353700000000000000000000000000000000313530313331393130363332313b383500000000000000000000000000000000313530313331393130373332363b313500000000000000000000000000000000313530313331393130383332393b363000000000000000000000000000000000313530313331393130393333323b323000000000000000000000000000000000",
  nonce: 108,
  r: "0x183a1fc9c149ece66ed8e782758f7980d3b01c88595662e769171e155749dc4a",
  s: "0xfd9abed2168cae1e33c2bd4441015178e54aa3fb1c742f4f613d9d3c140ef4",
  to: "0x8e195493424d416300f8b61b01145956345cd914",
  transactionIndex: 0,
  v: "0x41",
  value: 0
}

I don't understand, why it's not working. I don't think one transaction every 5 second is a lot, they should get included into one block.

I'm using web3 version 0.20.0.

update: to make things even more weird, it is sometimes actually working but sometimes it's not - seems like completely random to me. I can see in the console that the transactions are sent, I can also see, that new blocks are generated and synced with my node - once it stopped working, I have to restart the node.

update: I tried to override the nonce manually but that didn't helped. All transactions are just queued in the transaction pool:

> txpool
{
  content: {
    pending: {},
    queued: {
      0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12: {
        110: {...},
        111: {...},
        112: {...},
        113: {...},
        114: {...},
        115: {...},
        116: {...},
        117: {...},
        118: {...},
        119: {...},
        120: {...},
        121: {...},
        122: {...},
        123: {...},
        124: {...},
        125: {...},
        126: {...},
        127: {...},
        128: {...},
        129: {...},
        130: {...},
        131: {...},
        132: {...},
        133: {...},
        134: {...},
        135: {...}
      }
    }
  },
  inspect: {
    pending: {},
    queued: {
      0x7ee9e416fdb371a9190dfa8fdf7361e66ada7e12: {
        110: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        111: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        112: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        113: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        114: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        115: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        116: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        117: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        118: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        119: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        120: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        121: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        122: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        123: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        124: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        125: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        126: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        127: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        128: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        129: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        130: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        131: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        132: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        133: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        134: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas",
        135: "0x8e195493424d416300f8b61b01145956345cd914: 0 wei + 4000000 × 18000000000 gas"
      }
    }
  },
  status: {
    pending: 0,
    queued: 26
  },
  getContent: function(callback),
  getInspect: function(callback),
  getStatus: function(callback)
}

that's the function in my contract which gets called:

/**
 * save sensor data
 * @param   data    sensor data timestamp;value
 * @return  bool
 */ 
function saveSensorData(bytes32[] data) returns (bool success)
{
    if(sensors[msg.sender].exists)
    {
        for(uint i = 0; i < data.length; i++) {
            sensors[msg.sender].sensorData.push(data[i]);
        }

        return true;
    }

    return false;
}
9
  • One problem is the nonce value, each transaction should have a consecutive increasing number. If you send transactions too fast the geth client may not keep its internal state up to date. In that case you should get the next nonce with getTransactionCount at the begining and then override the default for subsequent transactions increasing it by one each time.
    – Ismael
    Jul 29, 2017 at 11:54
  • I will test it and look if it's a problem with the nonce value
    – Sepultura
    Jul 29, 2017 at 13:21
  • I have seen similar symptoms even where nonce is definitely different. See also this (currently unanswered) question that seems to be about similar topic: ethereum.stackexchange.com/questions/23073/… Jul 29, 2017 at 13:46
  • I tried to set the nonce manually, but that didn't helped, I'm pretty sure the nonce is correct, the transactions are all queued in the transaction-pool (see my update)
    – Sepultura
    Jul 30, 2017 at 9:32
  • 1
    When time permits I'll make a test with a contract instead, and update the answer accordingly.
    – Ismael
    Aug 1, 2017 at 18:11

2 Answers 2

2

Looks like a bug that has just been fixed: https://github.com/ethereum/go-ethereum/issues/14893

2

I've done this with a private testnet without problems

arr=[];
start=eth.getTransactionCount(eth.accounts[0]);
for (i = 0; i<= 200; i++) {
    arr.push(eth.sendTransaction({
        from: eth.accounts[0],
        to: eth.accounts[1],
        nonce: start+i,
        value: web3.toWei(1 , 'szabo')}));
}
miner.start(1);
admin.sleepBlocks(10);
miner.stop();

Mined 201 transactions in three blocks

> eth.getBlock(15).transactions.length
0
> eth.getBlock(16).transactions.length
98
> eth.getBlock(17).transactions.length
98
> eth.getBlock(18).transactions.length
5
> eth.getBlock(19).transactions.length
0

Sample block

> eth.getBlock(16)
{
  difficulty: 131072,
  extraData: "0xd783010605846765746887676f312e382e33856c696e7578",
  gasLimit: 2133025,
  gasUsed: 2058000,
  hash: "0x02efd3e3ff324f38a1b6b2900e58a39ae3cca30b41fc18d45cf4b6d1a2dd73ec",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x7ab9a957982ba2fd5665fccfc3c603b87931b1c9",
  mixHash: "0xf4a979afdc276b6bfc7d7dd1a6ba33d509d04bbfb5d7d65514bd5d4223e829ab",
  nonce: "0x292177014c2c726b",
  number: 16,
  parentHash: "0x1dcb415a3cedbbccaf21cefecadf02df46fbbceffad19bf62c9bcd5f2bf7466b",
  receiptsRoot: "0xe783695d43236e24a353adc1d48868ba90ae4e3f3eef98071c2c81016a9d8ac2",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 11215,
  stateRoot: "0x0c911d8345371e7be2236e548c8ad331449fc1dff93a943a35467428a608ed7a",
  timestamp: 1501385226,
  totalDifficulty: 2101184,
  transactions: ["0x6751df4f6bf8ffc580a87cd9ed3a88795133c0a5408f889999b5a2bda25b2469", 

Sample transaction

> eth.getTransaction(eth.getBlock(16).transactions[0])
{
  blockHash: "0x02efd3e3ff324f38a1b6b2900e58a39ae3cca30b41fc18d45cf4b6d1a2dd73ec",
  blockNumber: 16,
  from: "0x7ab9a957982ba2fd5665fccfc3c603b87931b1c9",
  gas: 90000,
  gasPrice: 18000000000,
  hash: "0x6751df4f6bf8ffc580a87cd9ed3a88795133c0a5408f889999b5a2bda25b2469",
  input: "0x",
  nonce: 122,
  r: "0xece247cd6ad1d19c1fbd997a860c111aa17dcfdfc11535ad9bad8d6f41e2e18c",
  s: "0x4a5dee5a9e4a2a099d070092024ed502a4c8d324badd8fa370d028c2a2c0f61c",
  to: "0x055a11dd8f2c2a2994d380da499c2f4920d969c6",
  transactionIndex: 0,
  v: "0x41",
  value: 1000000000000
}

Sample receipt

> eth.getTransactionReceipt(eth.getBlock(16).transactions[0])
{
  blockHash: "0x02efd3e3ff324f38a1b6b2900e58a39ae3cca30b41fc18d45cf4b6d1a2dd73ec",
  blockNumber: 16,
  contractAddress: null,
  cumulativeGasUsed: 21000,
  from: "0x7ab9a957982ba2fd5665fccfc3c603b87931b1c9",
  gasUsed: 21000,
  logs: [],
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  root: "0x7733965c0b1b35e98fbb60721c56f69225b8328f77e2e043c03ce038c0f1e4c0",
  to: "0x055a11dd8f2c2a2994d380da499c2f4920d969c6",
  transactionHash: "0x6751df4f6bf8ffc580a87cd9ed3a88795133c0a5408f889999b5a2bda25b2469",
  transactionIndex: 0
}

Private testnet genesis.json used

$ cat genesis.json 
{
    "config": {
        "chainId": 15,
        "homesteadBlock": 0,
        "eip155Block": 0,
        "eip158Block": 0
    },
    "difficulty": "0x400",
    "gasLimit": "2100000",
    "alloc": {
        "7ab9a957982ba2fd5665fccfc3c603b87931b1c9": { "balance": "200000" },
        "055a11dd8f2c2a2994d380da499c2f4920d969c6": { "balance": "400000" }
    }
}
8
  • thx I tried that but it didn't helped - I'm pretty sure the nonce is correct
    – Sepultura
    Jul 30, 2017 at 9:32
  • I'm seeing the same symptoms even with this script (and can confirm that the nonces were all unique in my previous tests). The infuriating thing is that on one or two occasions, the script did mine all the txns across 2 or 3 blocks, but most of the time it simply loses the txns that don't make it into the first block. What environment are you using? Aug 1, 2017 at 12:21
  • The details are in the answer, but it is a private testnet running in a single node. Do you have more than one geth instance as a peer? I've had a similar problems when sending transaction from two nodes at the same time using the same account.
    – Ismael
    Aug 1, 2017 at 18:07
  • 1
    I've been playing around a bit more and been able to see a situation where sometimes it works and sometimes it doesn't. My geth fu isn't enough to figure it out for myself, so I raised an issue: github.com/ethereum/go-ethereum/issues/14893 Aug 3, 2017 at 13:36
  • 2
    Hi @Ismael - Thanks for the link and suggestion, but geth seems to work fine through this. I've done a bit more digging and have updated the github issue with more info of what I've found. Seems to be to do with the order in which events are firing. Aug 4, 2017 at 20:49

Your Answer

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

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