You could try using geth --fast
that will normally take much quicker to sync your blockchain - see What is Geth's "fast" sync, and why is it faster? .
If you want to try out the fast sync, you will firstly have to clear out your old blockchain - see How to delete or reset the blockchain in geth? (OSX) . I would rename my old chaindata folder before trying out the fast sync, and if all is OK, remove my old chaindata.
While you are waiting for your syncing, you could use MyEtherWallet (https://www.myetherwallet.com/) to move your ethers.
UPDATE 1
I have just tested on Testnet and successfully executed a transaction from the Ethereum Wallet while my geth --testnet
instance was 80,000+ blocks from being fully synced. The transaction showed up in https://morden.ether.camp as expected.
The only restriction with sending transactions without the Ethereum Wallet (Mist) being fully synced is that the source account in Mist must have a balance that covers the ethers you want to send, or it will prevent you from sending the transaction. This is the same behaviour as in geth
as Mist sends transactions via geth
.
UPDATE 2
I have also successfully executed a transaction on Mainnet when my local node was a few thousand blocks out of sync.
Summary
I downloaded the geth
source, modified the source code to specify the fast sync pivot block, compiled the code, removed the old chaindata and started the fast syncing. Once this is complete, I'll be back to running the regular geth
binaries.
UPDATE This experiment failed. There were a few different errors with my hack that prevented the blockchain to fast sync to the specified block and then normal sync after the specified block. Back to full archive node sync.
Anyone has any suggestions?
Details
I downloaded the source code for geth
and modified the source code for section that calculates the fast sync pivot point eth/downloader/downloader.go, lines 419-441:
case FastSync:
// Calculate the new fast/slow sync pivot point
if d.fsPivotLock == nil {
pivotOffset, err := rand.Int(rand.Reader, big.NewInt(int64(fsPivotInterval)))
if err != nil {
panic(fmt.Sprintf("Failed to access crypto random source: %v", err))
}
if height > uint64(fsMinFullBlocks)+pivotOffset.Uint64() {
pivot = height - uint64(fsMinFullBlocks) - pivotOffset.Uint64()
}
} else {
// Pivot point locked in, use this and do not pick a new one!
pivot = d.fsPivotLock.Number.Uint64()
}
// If the point is below the origin, move origin back to ensure state download
if pivot < origin {
if pivot > 0 {
origin = pivot - 1
} else {
origin = 0
}
}
glog.V(logger.Debug).Infof("Fast syncing until pivot block #%d", pivot)
I modified the last line above to change the Debug
into Info
and added the following two lines below the code above:
glog.V(logger.Info).Infof("Fast syncing until pivot block #%d", pivot)
if (pivot >= 2394190) {
pivot = 2394190;
}
glog.V(logger.Info).Infof("Fast syncing until modified pivot block #%d", pivot)
I recompiled and started off the fast sync process using the modified binaries:
Iota:go-ethereum user$ make geth
...
Done building.
Run "build/bin/geth" to launch geth.
I checked the version of the modified geth
:
Iota:go-ethereum user$ build/bin/geth version
Geth
Version: 1.5.3-unstable
I removed the old damaged chaindata:
Iota:go-ethereum user$ build/bin/geth removedb
/Users/bok/Library/Ethereum/chaindata
Remove this database? [y/N] y
Removing...
Removed in 35.242291ms
I started the fast sync:
Iota:go-ethereum user$ build/bin/geth --fast --cache=1024 console
I1120 23:44:44.870142 ethdb/database.go:83] Allotted 1024MB cache and 1024 file handles to /Users/user/Library/Ethereum/geth/chaindata
I1120 23:44:44.878926 ethdb/database.go:176] closed db:/Users/user/Library/Ethereum/geth/chaindata
...
I1121 08:33:51.340811 eth/downloader/downloader.go:441] Fast syncing until pivot block #2664150
I1121 08:33:51.340847 eth/downloader/downloader.go:445] Fast syncing until modified pivot block #2394190
After the fast syncing is complete, I'll go back to using the regular geth binaries.
Best Answer
geth --fast
has an interesting effect:geth
cannot provide any information about accounts or contracts until the sync is fully complete.Try querying the balance again after
eth.syncing
returnsfalse
.Why?
The "fast" sync looks nearly complete because the reported current block is based on the best header you have. But that doesn't give you any information about how much of the account state data you have downloaded.
geth
can sync the blocks much faster than it can download the state. An excerpt from @karalabe's explanation why: