Transaction propagation issue on private test net since geth 1
Transaction propagation issue on private test net since geth 1.Four.6 #2769
nimmaj commented Jul 1, two thousand sixteen • edited
Geth version: 1.Four.6
OS & Version: Linux(Ubuntu:xenial)
I’ve got two geth knots 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.Four.6 i cannot send them back.
Steps to reproduce:
- bring up two geths, create coinbase on each, unlock accounts
- join them together using admin_addPeer
- begin mining on one knot – wait for it to have some ether
- send a transaction of, say, four ether from the miner coinbase to the non-miner coinbase
- observe that this succeeds
- once the non-miner coinbase has a balance, send some ether back
- observe that on 1.Four.Five this works fine. on 1.Four.6 this transaction is never included
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 affixed some files that display the problem (dag generation takes a while). They work on a mac with docker-machine commenced and presume a docker machine ip address of 192.168.99.100 – you might need to switch this to localhost on linux (there are directive line args for this).
The runTest.sh file assumes that you are in a directory called ethBug to help it find the ip address.
- docker-compose -f geth-docker-1.Four.Five build
- docker-compose -f geth-docker-1.Four.Five up
- npm install (i’m using node5, but presumably node6 will work)
At this point observe that the test (eventually) finishes with a payment back.
- ctrl-c the running docker compose (once)
- docker-compose -f geth-docker-1.Four.Five down
- docker-compose -f geth-docker-1.Four.6 build
- docker-compose -f geth-docker-1.Four.6 up
Observe that this does not finish.
You can see this in the logs for 1.Four.6:
So the txn never seems to be included in the block. The client has the txn as a pending txn. The miner has zero 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.Four.Five logs: