Using macOS 10.12.1 with Ethereum Wallet 0.8.7, nodes are connected but Sync doesn't even start. Stuck at block 2,306,843.
What can I do? Please keep in mind, I am neither a coder nor a tech geek.
[Ethereum] Why is the node synchronization stuck/extremely slow at block 2,306,843
attacksgo-ethereumNetworksynchronization
Related Solutions
Here's what I would do:
Make sure you're using the latest Ethereum-Wallet release: https://github.com/ethereum/mist/releases
Connect to the testnet to verify that all is well (there should be less transactions on the testnet blockchain so you should be able to sync quicker)
- Skip peer search
- Appbar -> Develop -> Network -> Testnet (Morden)
If you can sync'd on the testnet, you'll know it's working.
Additional things you can try:
- verify that all dependencies are up-to-date. You may need to reinstall all Ethereum related stuff. Don't forget to backup your accounts
- Check your computer. Is it having issues building a DAG?
- Try connecting with Geth (it'll also sync you up and build a DAG)
There has been some issues with geth syncing over the past few days as documented in geth does not sync out of the box .
The issue seems to have been resolved with the bootnodes now supplying peer information for geth to connect to. You can try running geth again and check whether your blocks start synchronising. Note that one of the attacks in the past few days was to make geth run slow by executing very high I/O actions in the Ethereum virtual machine. Your geth instance should connect to peers but the block processing will be slow.
A new version of geth titled Geth 1.4.13: Into the Woods (various DoS fixes) has just been released at https://github.com/ethereum/go-ethereum/releases/tag/v1.4.13 . The .zip files have been packaged, but the release binaries are still being built.
Download this new version of geth when you find the correct binaries for your system. This version should now sync and process the blocks containing the I/O spam transactions quicker compared to the 1.4.12 version.
If you are unsure about the procedure to separately run this new geth version outside the Ethereum Wallet, wait until the new version of geth is packaged into a new Ethereum Wallet and released.
Your GETH log error message
Last login: Sun Sep 25 21:49:28 on ttys000 Brents-MBP:~ brent$ /Users/brent/Desktop/Ethereum-Wallet.app/Contents/Frameworks/node/geth/geth ; exit; I0925 21:49:34.219133 ethdb/database.go:82] Alloted 128MB cache and 1024 file handles to /Users/brent/Library/Ethereum/chaindata Fatal: Could not open database: resource temporarily unavailable logout
The reason why you get this message is because you have started the Ethereum Wallet and Ethereum Wallet automatically starts an instance of geth.
If you want to connect to this geth instance, you can issue the command
geth attach
You can also shut down the Ethereum Wallet which will shut down it's geth instance. You can then manually start your own instance of geth using the following command
geth console
You can now start the Ethereum Wallet which will detect that you have manually started your own instance of geth, and automatically attach to your instance.
Best Answer
Update Mar 5 2017
The state cleaning was announced by Vitalik Buterin in the tweet State clearing 100% complete dated 23:07 Nov 29 2016. This time corresponds to block 2,718,436.
The Clearing Contract can be found at 0xe9c9068240d8450da314f60804debfc194b72309. There was over 10,000 transactions involved in clearing the state. The first transaction to Sweeper.sol was at block 2,675,055 in transaction 0x884d0fc7.... The last transaction to Sweeper.sol was at block 2,700,301 in transaction 0x6b651cfd....
The Sweeper.sol Contract can be found at 0xa43ebd8939d8328f5858119a3fb65f65c864c6dd. There was 35370 transactions involved in clearing the state. The first state clearing transaction was at block 2,675,055 in transaction 0x884d0fc7.... The last state clearing transaction was at block 2,717,576 in transaction 0xbf78cc00....
You can see that the daily gasUsed chart below shows the increase in gasUsed during the state clearing period:
One of the state clearing operations in block 2,686,351 triggered a consensus bug in
gethcausing a network fork in the blockchain. This was caused because the behaviour in one of the state clearing operations produced a different state compared to Parity.Some further information in the post A state clearing FAQ.
Your blockchain is currently syncing with the block data containing the recent low gas price network attacks where the following transaction types occurred within blocks:
gethmemory crash transaction.gethclients crashed when processing these transactions. This issue was fixed ingethFrom Shanghai, with love (1.4.12).EXTCODESIZEopcodes taking 20-60 seconds to validate due to the ~ 50,000 disk fetches needed to process each transaction.Note that from #2,675,000 when the 4th hard fork occurred, the syncing slows down as the node clients are clearing out the empty accounts created by the account bloat transactions. From Is there a new DOS attack? I'm running geth 1.5.2 and after starting it his morning I'm seeing very slow block processing times and cannot catch up with the network. Worked perfectly before the hard fork. What is going on?:
Computers with hard disk drives (HDD) are slowed down more compared to computers with solid state drives (SSD). Computers with 4Gb RAM + 4Gb swap disk or less were also harder hit, with the node clients crashing.
Your options are:
--gethparameter that will allow the Ethereum Wallet or Mist to communicate with it. See Using Parity with Mist. Parity syncs much faster thangethand is a drop-in replacement node client for Ethereum Wallet / Mist.References:
Update Nov 23 2016 - Some Results From A Full Sync
The following output from a full sync shows the speed of syncing improving after the end of the account bloat transaction attack blocks and slowing down again during the low impact transaction spam attack blocks. Further logs from the
gethfull node sync can be found here:The following output shows the syncing speed improving after the low impact transaction spam attack blocks: