18

It's difficult to give an answer without just re-hashing the explanation on the Parity wiki... The pertinent part is as follows: These snapshots can be used to quickly get a full copy of the state at a given block. Every 30,000 blocks, nodes will take a consensus-critical snapshot of that block's state. Any node can fetch these snapshots over the ...


4

I'm being totally serious when I say that the best thing to do is simply be patient. As long as you're getting new blocks, there's not much to do. If on the other hand, Parity continues to report the same block, then you can kill it and restart it. Blocks between around ~2286900 and ~271800 are very, very slow because of the DDOS attack in Sept/Oct 2016. ...


3

The quickest way of syncing Parity Ethereum client with the top of the chain is achieved using Warp sync in combination with --warp-barrier. To make sure you get the most recent snapshot available and warp sync very close to the top of the chain, Parity Ethereum >=v1.10.1 supports the flag --warp-barrier [NUM]. Replace [NUM] with the chain's latest block ...


2

I recently went through this process. I think the documentation is a bit outdated in times of how long it should take (or the network is slower than the documentation assumes). There are about 4.2 million blocks. Given your setup, it looks like you are getting about 150 blocks / second. At this rate, it will take about 4,200,000 / 150 seconds ~= 8 hours.


2

Many times it is a time-syncing issue Go to http://time.is/ and ensure it says "Your time is exact": 1-2 seconds out of sync is enough to disrupt peer discovery. Synchronize your OS clock with the NTP server you are using, so that you see the "Your time is exact" message in the above link. Make sure your network does not block outgoing UDP traffic (used ...


2

Partly solved the Problem: Add the flags to the parity.exe not the ptray.exe, this increased my syncing speed by about 50%. Nevertheless still ~1300 Block per hour is pretty slow


2

You can warp from any point in the blockchain, the client notices if you are more than 30_000 blocks behind and kicks in a warp sync unless you disabled it with --no-warp The --warp flag literally does nothing because warp is enabled by default. So it does not affect your connected peers in any way. It must be a coincidence. You can try to increase your ...


2

You are either on a bad connection or you don't have enough peers which can provide you with a warp snapshot. You can add extra warp snapshot peers with: parity --snapshot-peers 16 This will help maintaining the warp sync.


2

The --warp downloads the most recent 30k blocks and quickly validates for PoW and total difficulty. This is what's taking around 1-5 minutes. 0 ✓ user@hoster ~ $ parity --mode active --db-compaction ssd --warp --cache-size 4096 2016-12-01 22:27:08 Starting Parity/v1.4.5-beta-UNKNOWN-UNKNOWN/x86_64-linux-gnu/rustc1.13.0 2016-12-01 22:27:08 State DB ...


1

Use --jsonrpc-port for HTTP interface and/or --ws-port for WebSocket interface.


1

The best optimizations I can offer is: [parity] light = false [network] warp = true [footprint] tracing = "off" fat_db = "off" pruning = "fast" pruning_history = 8 pruning_memory = 32 db_compaction = "ssd" [snapshots] disable_periodic = true This disables light mode and enables warp-sync. Warp-sync does only verify PoW of ancient blocks and does not ...


Only top voted, non community-wiki answers of a minimum length are eligible