search

ethereum / go-ethereum

Go implementation of the Ethereum protocol
https://geth.ethereum.org
GNU Lesser General Public License v3.0
47.19k stars 19.97k forks source link

Miner starts mining before synch is finished (results in BAD BLOCK) #15159

Closed cgarnier closed 5 years ago

cgarnier commented 7 years ago

System information

Geth version: geth version

Geth
Version: 1.7.0-stable
Git Commit: 6c6c7b2af3efdad4d2f64f70f3a724af434bbcd2
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.9
Operating System: windows
GOPATH=
GOROOT=c:\go

OS & Version: Windows 10 Commit hash : (if develop)

Expected behaviour

No errors

Actual behaviour

ERROR[09-18|18:26:20]
########## BAD BLOCK #########
Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 9223372036854775807 Engine: ethash}

Number: 2
Hash: 0xb495a1d7e6663152ae92708da4843337b958146015a2802f4193a410044698c9

Error: unknown ancestor
##############################

Steps to reproduce the behaviour

Dont know, i just ran a console and ran a ethminer. After some time i got this error. When i check the balance it say 25 ether and it continue to grow. If i stop, remove the db and restart, ther balance go back to 0 and the error disapears.

Backtrace

[backtrace]
olegdater commented 6 years ago

Same here, unable to sync node using --fast

geth version

Geth
Version: 1.7.0-stable
Git Commit: 6c6c7b2af3efdad4d2f64f70f3a724af434bbcd2
Architecture: amd64
Protocol Versions: [63 62]
Network Id: 1
Go Version: go1.9
Operating System: darwin
GOPATH=
GOROOT=/usr/local/Cellar/go/1.9/libexec
==
WARN [09-21|08:46:41] Synchronisation failed, dropping peer    peer=f9c63051bfd9be8d err="retrieved hash chain is invalid"

ERROR[09-21|08:48:31] 

########## BAD BLOCK #########

Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 9223372036854775807 Engine: ethash}

Number: 4296829
Hash: 0x7112ac565466cba42244865cc01c7339fc97976ea255f4f6ef09af272e6f0b47

And it stops syncing. After rebooting it will sync a few blocks and will stuck again with the same error(s)

Bekbolatov commented 6 years ago

I am seeing this error with same block (2) repeatedly:

ERROR[09-23|09:17:39]
########## BAD BLOCK #########
Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 9223372036854775807 Engine: ethash}

Number: 2
Hash: 0xb495a1d7e6663152ae92708da4843337b958146015a2802f4193a410044698c9

Error: unknown ancestor
##############################

WARN [09-23|09:17:39] Synchronisation failed, dropping peer    peer=caf37865237acb78 err="retrieved hash chain is invalid"

Using commit 673007d.

holiman commented 6 years ago

Very interesting. I'd be curious to see the chaindb of those cases where block 2 is rejected, if you can zip it up and upload somewhere.  And make sure not to include the keystore!

They should be fairly small, might be possible to analyse the error in depth.

holiman commented 6 years ago

Also, if you could write in this ticket exactly what command you were using when executing geth, that would help too.

t5unamie commented 6 years ago

Also suddenly got this issue as well.

holiman commented 6 years ago

Anyone with failures at second block, I'd like to look at the database. That is, the chaindata folder in the datadir.

holiman commented 6 years ago

Also, I'd be curious what you get if you start geth up (in non-communicative mode: geth --maxpeers 0 --nodiscovery console ) and then do eth.getBlock(0) and eth.getBlock(1)

escos1 commented 6 years ago

I am also having this issue. If, I go to resync, I can sync about 16gigs, then it starts again. I am not using a fast sync.

holiman commented 6 years ago

Please provide detailed info. When someone says 'this issue', its hard to know if it's the same error message, or the exact same error (same block number and hash). Also, please provide the exact command used to invoke geth, and version information.

escos1 commented 6 years ago

I believe it's the same issue. Exact same block. I cannot tell you the hash as I already dumped the block and cleared my logs. I am using the latest stable version of geth. v 1.7.0-stable-6c6c7b2a Fresh and Clean windows build. However, I resolved the issue by dumping the individual block. Just have to wait and see if the issue comes back. I launch geth with --rpc --ws --cache=8192 console I appologize earlier I am using fast sync as it is on by default in this build.

t5unamie commented 6 years ago

@holiman Error below from the following command.

geth --etherbase "" --mine --minerthreads=2

########## BAD BLOCK #########
Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 9223372036854775807 Engine: ethash}

Number: 2
Hash: 0xb495a1d7e6663152ae92708da4843337b958146015a2802f4193a410044698c9

Error: unknown ancestor
##############################

WARN [09-24|22:17:50] Synchronisation failed, dropping peer    peer=1e83ccb659e9a49d err="retrieved hash chain is invalid"
WARN [09-24|22:19:25] Synchronisation failed, dropping peer    peer=d48db6dc3a9839a5 err=timeout

Output when running the following geth you specified.


geth --maxpeers 0 --nodiscover console
WARN [09-24|22:26:28] No etherbase set and no accounts found as default
INFO [09-24|22:26:28] Starting peer-to-peer node               instance=Geth/v1.7.0-stable-6c6c7b2a/windows-amd64/go1.9
INFO [09-24|22:26:28] Allocated cache and file handles         database=C:\\Users\\xmen1\\AppData\\Roaming\\Ethereum\\geth\\chaindata cache=128 handles=1024
INFO [09-24|22:26:28] Initialised chain configuration          config="{ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzantium: 9223372036854775807 Engine: ethash}"
INFO [09-24|22:26:28] Disk storage enabled for ethash caches   dir=C:\\Users\\xmen1\\AppData\\Roaming\\Ethereum\\geth\\ethash count=3
INFO [09-24|22:26:28] Disk storage enabled for ethash DAGs     dir=C:\\Users\\xmen1\\AppData\\Ethash                          count=2
INFO [09-24|22:26:28] Initialising Ethereum protocol           versions="[63 62]" network=1
INFO [09-24|22:26:28] Loaded most recent local header          number=11787 hash=f9878e…ae2369 td=1046933729586640
INFO [09-24|22:26:28] Loaded most recent local full block      number=11787 hash=f9878e…ae2369 td=1046933729586640
INFO [09-24|22:26:28] Loaded most recent local fast block      number=11787 hash=f9878e…ae2369 td=1046933729586640
INFO [09-24|22:26:28] Loaded local transaction journal         transactions=0 dropped=0
INFO [09-24|22:26:28] Regenerated local transaction journal    transactions=0 accounts=0
WARN [09-24|22:26:28] Blockchain not empty, fast sync disabled
INFO [09-24|22:26:28] Starting P2P networking
INFO [09-24|22:26:28] RLPx listener up                         self="enode://96f767f49e91a50977b5303b592dbe43da0689607322e08e0761258b49eb09d2ebd2e7023de5c6f382f771c86f9ac26c74fc59c8e3b0f8bf872ea778b12aaa2e@[::]:30303?discport=0"
INFO [09-24|22:26:28] IPC endpoint opened: \\.\pipe\geth.ipc
Welcome to the Geth JavaScript console!

instance: Geth/v1.7.0-stable-6c6c7b2a/windows-amd64/go1.9
 modules: admin:1.0 debug:1.0 eth:1.0 miner:1.0 net:1.0 personal:1.0 rpc:1.0 txpool:1.0 web3:1.0

> eth.getBlock(0)eth.getBlock(0)eth.getBlock(0)eth.getBlock(0)
(anonymous): Line 1:16 Unexpected identifier (and 1 more errors)
> eth.getBlock(0)
{
  difficulty: 17179869184,
  extraData: "0x11bbe8db4e347b4e8c937c1c8370e4b5ed33adb3db69cbdb7a38e1e50b1b82fa",
  gasLimit: 5000,
  gasUsed: 0,
  hash: "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x0000000000000000000000000000000000000000",
  mixHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  nonce: "0x0000000000000042",
  number: 0,
  parentHash: "0x0000000000000000000000000000000000000000000000000000000000000000",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 540,
  stateRoot: "0xd7f8974fb5ac78d9ac099b9ad5018bedc2ce0a72dad1827a1709da30580f0544",
  timestamp: 0,
  totalDifficulty: 17179869184,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []
}
> eth.getBlock(2)
{
  difficulty: 17163096064,
  extraData: "0xd783010607846765746887676f312e382e31856c696e7578",
  gasLimit: 5006,
  gasUsed: 0,
  hash: "0xc606a3d3f41ad065553e7444067909b25c2afde629078d0b34b6605a6e634709",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x29ac683653f7629d12a3cdaac824516899cb7220",
  mixHash: "0x725eef3d0cf549ea189e839101ad67aab1c96c53e54edfb225e3bcd5f9dd5ee0",
  nonce: "0xe4a74eb4011f6af1",
  number: 2,
  parentHash: "0x93a796d4f849be00c97b04754a0e60ba1f6ef9b2b64350df2019e36f4472551e",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 536,
  stateRoot: "0x1c192b0346402f19f2f860d667d1cbc333bcfa5588672328401e805b19fd9ea3",
  timestamp: 1505080128,
  totalDifficulty: 51514445824,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []
}
> eth.getBlock(3)
{
  difficulty: 17171476482,
  extraData: "0xd783010607846765746887676f312e382e31856c696e7578",
  gasLimit: 5009,
  gasUsed: 0,
  hash: "0xf12863b36422d7fc8ddc0703be25630c92c7f640c8369fd39dfd3cd3065ea9e2",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x29ac683653f7629d12a3cdaac824516899cb7220",
  mixHash: "0xbcb9fb76d333d33c277431f666c57a27ebd589a93be2a0b6191776a4732ca00e",
  nonce: "0xc1b8b2ac000a861c",
  number: 3,
  parentHash: "0xc606a3d3f41ad065553e7444067909b25c2afde629078d0b34b6605a6e634709",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0xc7288ff147dbad43709e9bf586114af7f3dc41e6cd628ed8090fba36e14a4daf",
  size: 1069,
  stateRoot: "0x9df438afc410c913c2f2b3e2996138f4c01dc426082c8044f44612b5e0cc9210",
  timestamp: 1505080130,
  totalDifficulty: 68685922306,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: ["0x84420f200734cb30b2a6f2ede30ca2f9f682e86b71a4fcca0f50ba7330a14b99"]
}
> eth.getBlock(1)
{
  difficulty: 17171480576,
  extraData: "0xd783010607846765746887676f312e382e31856c696e7578",
  gasLimit: 5003,
  gasUsed: 0,
  hash: "0x93a796d4f849be00c97b04754a0e60ba1f6ef9b2b64350df2019e36f4472551e",
  logsBloom: "0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000",
  miner: "0x29ac683653f7629d12a3cdaac824516899cb7220",
  mixHash: "0xa53ce55863922c2fe61e69e027104608efb58f27a8d1390ac43f146495451df6",
  nonce: "0x0d3943c8071b99d8",
  number: 1,
  parentHash: "0xd4e56740f876aef8c010b86a40d5f56745a118d0906a34e69aec8c0db1cb8fa3",
  receiptsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  sha3Uncles: "0x1dcc4de8dec75d7aab85b567b6ccd41ad312451b948a7413f0a142fd40d49347",
  size: 536,
  stateRoot: "0x0ce4e11c35146a49ea3b5f2cbe8df4c68de81a005b1defe9d2e5950bd9d0bb85",
  timestamp: 1505080104,
  totalDifficulty: 34351349760,
  transactions: [],
  transactionsRoot: "0x56e81f171bcc55a6ff8345e692c0f86e5b48e01b996cadc001622fb5e363b421",
  uncles: []
}

I am assuming you want all the files in "C:\Users\xmen1\AppData\Roaming\Ethereum\geth\chaindata"?

Does'nt that also hold my keystore?

Bekbolatov commented 6 years ago

Block 1 looks wrong right there...

Bekbolatov commented 6 years ago

See the timestamp - it is impossible, since system went live in 2015.

t5unamie commented 6 years ago

@Bekbolatov not sure how to fix it.

holiman commented 6 years ago

Seems like you guys have started mining your own blocks from genesis. Is there anyone in this thread who has had the same problem (bad block on a low number) who has not used the option --mine ?

t5unamie commented 6 years ago

@holiman Genesis? can you elaborate? Is that a branch of the code? Or a spacial setup for mining difficulty?

holiman commented 6 years ago

I am assuming you want all the files in "C:\Users\xmen1\AppData\Roaming\Ethereum\geth\chaindata"? Does'nt that also hold my keystore?

Your keystore is called keystore and would reside (I think) under C:\Users\xmen1\AppData\Roaming\Ethereum\keystore. But you can hold on about sending anything, the output provided abobe helps a lot.

So genesis is the first 'block' (not really a block), that all other blocks build from. It seems to me that you have all been mining from genesis (block 0 ) - that is, starting a paralell chain from scratch. Which probably isn't what you wanted :/

holiman commented 6 years ago

@t5unamie is this your etherbase 0x29ac683653f7629d12a3cdaac824516899cb7220?

t5unamie commented 6 years ago

@holiman - sorry no it isn't On another note, how can you mine ether on a parallel chain? I thought there is only one chain and all changes occur on that chain.

Bekbolatov commented 6 years ago

It worked for me after I completely wiped out the chaindb and restarted. Seems to be happening sporadically.

Bekbolatov commented 6 years ago

@holiman - that is quite a possibility. It is probably an undesirable default behavior though.

Bekbolatov commented 6 years ago

Thanks @holiman! I am pretty sure this is what was happening, but I won't dig into the code to debug it - since there could be many reasons and I am not familiar with this Go codebase.

Ideally a client should be able to switch to the accepted chain. How many peers do you guys typically run? I saw some messages often where it would drop peers due to inconsistency. I wonder if the client didn't get enough information to decide to abandon the new alternative chain.

Anyway - seems like we found out what is happening there, but still need to dig deeper to make sure this doesn't happen often. Thanks all!

holiman commented 6 years ago

On another note, how can you mine ether on a parallel chain? I thought there is only one chain and all changes occur on that chain.

Well, say you start geth in mining mode when you're totally offline. The node would simply start mining from genesis, since it knows about no other blocks.

In this case, it seems that the mining (erroneously) starts even though there obviously is a longer chain already out there, which we're currently synching.

t5unamie commented 6 years ago

Hi There,

So I started mining for ether.

I have done as @Bekbolatov . Deleting the chaindata and started the miner up again. It processes correctly.

However I want to confirm if this has any effect or is in fact the right thing to do.

1> I setup a coinbase account. Got an address and ran the following command. 2> I then run the following command geth --etherbase "${address}" --mine

Been mining for two days and no ether.

Starting to believe something is wrong. Does anyone know how I can check?

Bekbolatov commented 6 years ago

@t5unamie if you are using just your CPU for mining it is unlikely you will mine a block in months, maybe even years. Current version (Homestead) is based on Proof-of-Work that uses computationally expensive hashing, so you would need significant hashing power - probably at least 1-10Gh/s now (compare to your CPU alone at ~50-500Kh/s - orders of magnitude difference) - to really see anything like mining a winning block in reasonable time, like days.

You can use geth to run a node and be connected to the network, interact with it, but for mining you probably want to hook up GPU-based miners and lots of them.

cgarnier commented 6 years ago

Is there a way to know when chain is synced ?

Bekbolatov commented 6 years ago

On console: eth.synching

It will either return the current state of synching (currently synched, highest etc) or "false".

You can also check eth.blockNumber to see your system's latest block number.

Renat

On Thu, Sep 28, 2017 at 08:22 Clément Garnier notifications@github.com wrote:

Is there a way to know when chain is synced ?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ethereum/go-ethereum/issues/15159#issuecomment-332871093, or mute the thread https://github.com/notifications/unsubscribe-auth/ADmM-6lSgVH4EVuo_6Wqi4F5xIEVzc-Pks5sm7nFgaJpZM4PbL2B .

--

Kind regards, Renat

Sign up for my mailing list: http://eepurl.com/cXm00r LinkedIn: http://www.linkedin.com/in/bekbolatov Easy Eight Consulting: www.easyeightconsulting.com

Cu4rach4 commented 6 years ago

@holiman i have the same issue:

Sep 30 09:35:33 ubuntu geth[1067]: WARN [09-30|09:35:33] Synchronisation failed, dropping peer    peer=81ef7fef827e660a err="retrieved hash chain is invalid"
Sep 30 09:35:38 ubuntu geth[1067]: ERROR[09-30|09:35:38]
Sep 30 09:35:38 ubuntu geth[1067]: ########## BAD BLOCK #########
Sep 30 09:35:38 ubuntu geth[1067]: Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000 Byzant
Sep 30 09:35:38 ubuntu geth[1067]: Number: 2
Sep 30 09:35:38 ubuntu geth[1067]: Hash: 0xb495a1d7e6663152ae92708da4843337b958146015a2802f4193a410044698c9
Sep 30 09:35:38 ubuntu geth[1067]: Error: unknown ancestor
Sep 30 09:35:38 ubuntu geth[1067]: ##############################
Sep 30 09:35:38 ubuntu geth[1067]:  
Sep 30 09:35:38 ubuntu geth[1067]: WARN [09-30|09:35:38] Synchronisation failed, dropping peer    peer=0d2135f8c5050687 err="retrieved hash chain is invalid"

But this error is only when i run geth with service:

[Unit]
Description=Ethereum go client

[Service]
Type=simple
ExecStart=/usr/bin/geth --rpc --cache=2048 --etherbase "0x0" --ethash.dagsinmem 2

[Install]
WantedBy=default.target

I change etherbase to other.

if i run the same command or simply geth on console:

INFO [09-30|09:38:27] Imported new block receipts              count=4    elapsed=15.117ms  bytes=483881 number=4323787 hash=aefad8…27dbe9 ignored=0
INFO [09-30|09:38:27] Imported new block receipts              count=12   elapsed=30.255ms  bytes=961406 number=4323799 hash=72eda0…457f56 ignored=0
INFO [09-30|09:38:29] Imported new state entries               count=1007 elapsed=4.831ms   processed=64706 pending=18806 retry=317 duplicate=0 unexpected=0
INFO [09-30|09:38:30] Imported new state entries               count=1198 elapsed=7.269ms   processed=65904 pending=17983 retry=0   duplicate=0 unexpected=0
INFO [09-30|09:38:30] Imported new block receipts              count=6    elapsed=20.261ms  bytes=529695 number=4323805 hash=85d006…2a1c27 ignored=0
INFO [09-30|09:38:31] Imported new state entries               count=699  elapsed=3.510ms   processed=66603 pending=18628 retry=2   duplicate=0 unexpected=0

My eth.syn

> eth.syncing
{
  currentBlock: 4324382,
  highestBlock: 4324688,
  knownStates: 1247828,
  pulledStates: 1220723,
  startingBlock: 4323773
}

I kill process an start again...i also remove all db with geth removedb but sync takes to much time to do again!

UPDATE:

Finally sync is finish...but still can user geth for service...i don't know why still gets the same error...

Evil2000 commented 6 years ago

Has someone finally found a solution for this? I still get this error over and over again:

>$ geth --fast --cache=2048
...
I0102 10:05:59.758648 node/node.go:176] instance: Geth/v1.5.5-stable/linux/go1.9.2
I0102 10:05:59.758725 ethdb/database.go:83] Allotted 2048MB cache and 1024 file handles to /var/lib/bitcoin/.ethereum/geth/chaindata
I0102 10:06:00.718162 eth/backend.go:191] Protocol Versions: [63 62], Network Id: 1
I0102 10:06:00.736243 eth/backend.go:219] Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000}
...
E0102 12:20:53.331259 core/blockchain.go:1222] 
########## BAD BLOCK #########
Chain config: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000}

Number: 4370000
Hash: 0xb1fcff633029ee18ab6482b58ff8b6e95dd7c82a954c852157152a7a6d32785e

Error: Difficulty check failed for header (remote: 2994347070619309 local: 2998009606615050)
##############################
adamschmideg commented 5 years ago

@cgarnier does the original problem persist?

holiman commented 5 years ago

@Evil2000 the problem you're having is that 4370000 is the byzantium fork, and you're running a client which isn't byzantium compatible Geth/v1.5.5-stable/linux/go1.9.2: {ChainID: 1 Homestead: 1150000 DAO: 1920000 DAOSupport: true EIP150: 2463000 EIP155: 2675000 EIP158: 2675000}

holiman commented 5 years ago

Since it's been so long since the original issue was reported, and no new info about the original issue, and we have made quite a lot of changes to the mining engine since then, I'm going to close this. Please open a new ticket if the issue persists.