The fastest way to achieve this, is to download the current blockchain and import it into the daemon:
Step 1: Move into the folder where you downloaded the Monero Gui Wallet, e.g:
Step 2: Download the raw block chain from a trusted source, e.g:
wget -c --progress=bar https://downloads.getmonero.org/blockchain.raw
Note that, if you are stuck on block 1288639 (or block 1400001) or a few blocks later, you are using a wrong, outdated, version and you should upgrade to the latest version, which can be found here. In addition, this won't require a resync from scratch, as the "new" monerod will automatically use the blockchain that was used with the previous version and ...
With the most recent version, this particular issue is, fortunately, trivially fixed as follows:
Exit the GUI by clicking on the x (right top) and subsequently making sure to stop the daemon as well.
Upgrade to GUI v0.14.0.0 -> https://www.reddit.com/r/Monero/comments/ayshug/gui_v01400_boron_butterfly_released/
Start the "new" GUI (v0.14.0.0) and let ...
The message means that your block height is 62 days ahead of a block which you just were told was mined (on top of a block way back in history).
As you verified your block height was correct (as of the time of that image)
The blocks that you are "62 days ahead" of were created by miners that remained on Monero chain(s) that we hard-forked away from.
Basically what jwinterm said.
I think your best bet, assuming you want to do something else with your computer while catching up rather than catch up ASAP, would be to add --prep-blocks-threads 1 (or 2; it defaults to 4) to your command line. This will make it use only one (or two) core(s) to compute POW while in "catch up" mode.
Changing the sync size parameter can have a positive impact in some cases.
Start the daemon with:
./monerod --block-sync-size 10
Quoting /u/closenix's test results:
I've run some tests: Syncing with block-sync-size 10 was faster than with the default of 200. I've run the daemon 9 times in sequence, every time starting at block 1275000 and ending at ...
Mainly it's a question of available RAM and I/O bandwidth. When you're importing a raw file, reading the raw file takes up disk bandwidth as well as RAM in the filesystem cache. This competes with the disk bandwidth (and RAM) needed to write out the database file. When you're syncing over the network, this extra disk and RAM overhead isn't present.
This is, fortunately, fairly trivial and you won't lose any of the progress. It is done as follows.
If you're using the GUI, perform the following steps:
Create a new directory on the other/external drive. In addition, create a subdirectory called lmdb. Thus, if you, for example, created a directory called MoneroBlockchain on the other/external drive, you ...
I will try to combine the above answers and my own information into one answer.
After recovering my wallet with my mnemonic seed, do I need to synchronize the entire blockchain before I can send a transaction?
Once you have your wallet, all you need is access to a monero blockchain with the proper data to send a transaction. Access to a monero blockchain ...
People were abusing --verify 0, using it for files they downloaded from the internet, which is a dangerous thing to do. So it got renamed to --dangerous-unverified-import (prior to this it was named --guard-against-pwnage), to make it clear it's a dangerous thing to do. Similar to disabling a malware scanner when downloading some binary off the internet.
For performance reasons, LMDB asks the OS to preallocate its storage space in large chunks, instead of growing incrementally as new records are added. Periodically this space must be increased as the actual usage increases.
I think it tries to sync as fast as possible and the verification is CPU intensive. I believe there are options to limit the bandwidth usage in the daemon, or you could just limit the resource usage of the daemon from Windows or Linux.
Logan is correct, but I'll go into more details about the first question:
You technically do not need to sync the whole blockchain, though you'll want to do it to save headaches. What you need to is sync enough to (1) get your owned outputs (or at least the ones which you will be sending), (2) get the transactions spending your outputs (or at least the ones ...
A large block sync size is supposed to make things faster, as some lookups can be made once and reused. However, this uses more memory, and will be slower if it makes the OS start swapping monerod.
I don't know how 200 was chosen, but it was likely a good value for Tacotime, who added the code.
The upcoming release has the block sync size set to 100 prior ...
Security wise, it's the same, assuming you do not disable verification on the conversion process (which speeds up a lot, but then if there are problems, they won't be detected).
Speedwise, it varies. Typically, syncing is faster, as this can do some things in parallel. However, if your internet download speed is pretty slow, or if you can't download much (e....
It is significantly slower with an HDD compared to an SSD. Bandwith is also a significant factor.
Yes, if you clicked on the defaults, then you are downloading the entire blockchain. See this exchange for details on the necessity, and this one for light clients (like Electrum).
A very vague approximation would be 24h ( ~80% margin of error :) ). Currently,...
It is a common misconception to those new to cryptocurrencies that the coins are "stored" in a wallet. In fact, the coins are stored on the blockchain. They are always there, waiting to be accessed and spent. Your wallet, at its core, is simply a key holder. Your wallet holds the key(s) that allow you to spend your coins.
The answer is no, your coins ...
Use the --log-level X argument to bitmonerod. Default log level is 0 (less verbose).
The impact on syncing time is minimal on 0, but it can be significant when using a very verbose method like 4, and if you are writing to a log file on the same disk where the blockchain is downloaded.
Logs mostly have network information, so I'd say the security impact is ...
The speed of transaction validation was reduced with the activation of RingCT at block height 1220517 in early January.
Although RingCT transactions still take longer to validate than pre RingCT transactions, the difference in performance was significantly reduced with the 10.2.1 release that went live this week. Further improvements are expected, the ...
The 100% part of the message means that you are connected only to nodes with at most that height, which is far in the past.
Try print_cn and see if you have any peers, and how many. This is odd that you'd be connected to only bad peers.
To try to fix the problem:
start monerod again
This will cause monerod to ...
That sounds remarkably normal since Monero's block target is 2 minutes. So you'd be expected to receive a block every two minutes on average.
Try running status in monerod. You'll be given the local blockchain height, and the highest known blockchain height from peers. If those match, then you've synced to the tip, and are receiving new blocks shortly after ...
First of all, to clarify for the readers, this flag will change the batch of blocks that is fetched to 10, from a default of 200 blocks per batch.
How can I do the same thing from the Monero GUI
If you are using the GUI, simply add --block-sync-size 10 as daemon startup flag. You can do this on the Settings page of the GUI. Note that you need to restart ...
Not that I know of, but failed transactions and reorgs can get the wallet's idea of what outputs are spent to get out of sync with the blockchain. This does not require a rescan of the blockchain (just rescan_spent is enough, and it is a lot faster), but it is not widely known, and some people tend to go for the nuclear option first (rescan_spent also did ...
I think generally just update the binaries and sync from where you left off. I believe the resync from scratch with the most recent binaries (v0.10) were due to significant changes to the database format, and resyncing was generally faster than converting the old one.
Basically yes, a wallet has to scan every block in the blockchain to see if any transactions belong to it.
When importing an older wallet, it only needs to scan from the last block known to that old wallet, forward. Depending on the age of the wallet this may be much less than the entire blockchain.
The new wallet code is much faster now because it can ...
I didn't test that in windows command prompt but in my sync tool i'd gain best results with
--block-sync-size 4 --db-sync-mode fastest:sync:8750
connection :10mbps .
Although developers on github mention that the last argument lowerin the fault-proof i bet it still can be used if you wanna speed.
Tool : https://github.com/alexeyneu/tool3
To add to the answer provided by fluffyponyza. Hard drive IO is a major bottleneck with synchronizing the blockchain. As an example synchronizing on my desktop took approximately 50 hours on a traditional 7200 rpm disk drive. My laptop was able to fully synchronize the blockchain from scratch in 2-3 hours on its SSD.
It sounds like your 32 bit Monero build is invalid, it is computing incorrect hashes and failing to accept valid blocks. If you got this from the official download site, please submit an issue on Github about this.
You are wasting power running a 32 bit OS. I'm currently using this 64 bit Debian install: http://forum.geekbox.tv/viewtopic.php?f=12&t=3284
The second line of the log indicates Address already in use, which means that the address the daemon is trying to use (0.0.0.0:18080) is already used by some other sofware on your machine. As if there was already a monerod daemon running.
These are the usual suspects for slow sync:
CPU speed (for block verification). Nothing you can do here other than upgrade CPU or wait for some software optimization but I don't believe there can be any major improvements anymore.
HDD/SSD speed (big slowdown for HDDs, as you have to read / write the blockchain somewhere). Same "solution" as above.