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;
}
  • 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 '17 at 11:54
  • I will test it and look if it's a problem with the nonce value – Sepultura Jul 29 '17 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/… – Alan Buxton Jul 29 '17 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 '17 at 9:32
  • 1
    When time permits I'll make a test with a contract instead, and update the answer accordingly. – Ismael Aug 1 '17 at 18:11
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" }
    }
}
  • thx I tried that but it didn't helped - I'm pretty sure the nonce is correct – Sepultura Jul 30 '17 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? – Alan Buxton Aug 1 '17 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 '17 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 – Alan Buxton Aug 3 '17 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. – Alan Buxton Aug 4 '17 at 20:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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