Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Transaction propagation issue on private test net since geth 1.4.6 #2769
Geth version: 1.4.6
I've got two geth nodes joined together on a private test net. Both have a coinbase. I can send transactions from the coinbase on the miner to the coinbase on the client geth. Post 1.4.6 i cannot send them back.
Steps to reproduce:
Presumably there is either a bug or I've mis-setup my setup. But that fact that the txns flow in one direction seems interesting.
I've attached some files that show the problem (dag generation takes a while). They work on a mac with docker-machine started and presume a docker machine ip address of 192.168.99.100 - you might need to change this to localhost on linux (there are command line args for this).
The runTest.sh file assumes that you are in a directory called ethBug to help it find the ip address.
At this point observe that the test (eventually) finishes with a payment back.
Observe that this does not complete.
You can see this in the logs for 1.4.6:
So the txn never seems to be included in the block. The client has the txn as a pending txn. The miner has 0 pending txns.
Presumably the transaction is not propagating from the client to the miner. Anyone have any idea why?
For completeness here is the corresponding part of the 1.4.5 logs:
Thanks v. much :-)
This was actually a feature that behaves in a weird way on private networks with a single miner.
We've noticed that on the main network when new nodes join, they already receive and try to process transactions against their whatever stale state. Since initial sync can take quite some time, new nodes manages to pile up 10s of thousands of transactions, which put an enormous burden on them. Our solution was that the nodes do not accept new transactions from remote nodes until they complete their initial sync cycle (= receive either a long chain from a remote node, or a fresh enough block).
In a private scenario with only 1 miner, the miner actually never completes a sync since it never receives a block from anyone else (as it is the only one minting the blocks). It's an unfortunate corner case we didn't think of.
One solution is to assume the chain synced when a miner starts mining, but the drawback is that people starting a new node with
I'm trying to figure out the best solution for this.
@karalabe - that's really interesting, thanks. So actually in my case i could work around the issue by mining a bit on each node and letting them sync before switching to a single miner. I will try that and report back later today.
You might ask why we're only using one miner? We are trying to have broadly one block per second and we've found that we get into a lot of trouble with multiple miners and low difficulties so we've switched to one miner for the moment. There are other rather interesting issues in this use case.
Many thanks for the clear explanation about what is going on - that's really helpful.
referenced this issue
Jul 15, 2016
I just had a strange case presumably related somehow to this issue on a private testnet with three miners. The "main" miner was the only one mining and the other two miners were connected to the main miner but not each other. At first, I observed the behavior above.
Reading the discussion above, I started mining on the two other nodes at which point transactions were indeed passed along to the main node, however, the two other miners happened to be mining faster than the main miner and they were all out of sync in block numbers. The main miner (slowest) was in the 1930's, and the other two were in the 2030's range and 2070's, respectively. None were syncing to the longest chain but were passing on transactions. I verified all were connected correctly by checking admin.peers.
One solution is to replace the conditional at eth/handler.go#L668:
Its not a perfect fix since some tx's might arrive before downloading starts, and some tx's may occasionally slip through when downloading is interrupted (when a peer is dropped,
referenced this issue
Sep 6, 2016
adding to the previous post:
I think if you remove these lines:
And compile it ONLY for your miner-client on your server, then should working temporary.
I'm using Geth 1.5.5 on a private network with one mining node (M) and a non-mining node (A). On the node A, I have a static-nodes.json file describing the node M.