Rust implementation of Zcash protocol

Parity Technologies

Last update: Sep 8, 2022

Related tags

Cryptography rust client node blockchain parity zcash

Overview

The Parity Zcash client.

Gitter

Blog: Parity teams up with Zcash Foundation for Parity Zcash client

Installing from source
Installing the snap
Running tests
Going online
Importing bitcoind database
Command line interface
JSON-RPC
Logging
Internal Documentation

Installing from source

Installing pzec from source requires rustc and cargo.

Minimal supported version is rustc 1.23.0 (766bd11c8 2018-01-01)

Install rustc and cargo

Both rustc and cargo are a part of rust tool-chain.

An easy way to install the stable binaries for Linux and Mac is to run this in your shell:

curl https://sh.rustup.rs -sSf | sh

Windows binaries can be downloaded from rust-lang website.

Install C and C++ compilers

You will need the cc and gcc compilers to build some of the dependencies.

On macOS

build-essential is a Debian package. On macOS you will need to make sure you have Xcode installed. If you already have Homebrew installed, you probably also already have the Xcode tools installed as well. If not, you can run the command below:

xcode-select --install

On Linux

sudo apt-get update
sudo apt-get install build-essential

Clone and build pzec

Now let's clone pzec and enter it's directory:

git clone https://github.com/paritytech/parity-zcash
cd parity-zcash

# builds pzec in release mode
cargo build -p pzec --release

pzec is now available at ./target/release/pzec.

Installing the snap

In any of the supported Linux distros:

sudo snap install parity-zcash --edge

Running tests

pzec has internal unit tests and it conforms to external integration tests.

Running unit tests

Assuming that repository is already cloned, we can run unit tests with this command:

cargo test --all

Going online

By default parity connects to Zcash seednodes. Full list is here.

To start syncing the main network, just start the client without any arguments:

./target/release/pzec

To start syncing the testnet:

./target/release/pzec --testnet

To not print any syncing progress add --quiet flag:

./target/release/pzec --quiet

Importing zcashd database

It it is possible to import existing zcashd database:

# where $ZCASH_DB is path to your zcashd database. By default:
# on macOS: "/Users/user/Library/Application Support/Zcash"
# on Linux: "~/.zcash"
./target/release/pzec import "$ZCASH_DB/blocks"

By default, import verifies the imported blocks. You can disable this, by adding the --verification-level=none option.

./target/release/pzec --verification-level=none import "$ZCASH_DB/blocks"

Command line interface

Full list of CLI options, which is available under pzec --help: see here

Logging

This is a section only for developers and power users.

You can enable detailed client logging by setting the environment variable RUST_LOG, e.g.,

RUST_LOG=verification=info ./target/release/pzec

pzec started with this environment variable will print all logs coming from verification module with verbosity info or higher. Available log levels are:

error
warn
info
debug
trace

It's also possible to start logging from multiple modules in the same time:

RUST_LOG=sync=trace,p2p=trace,verification=trace,db=trace ./target/release/pzec

Internal documentation

Once released, pzec documentation will be available here. Meanwhile it's only possible to build it locally:

cd parity-zcash
./tools/doc.sh
open target/doc/pzec/index.html

Comments

Thread panic at block 14b054be76b515b12efcfdfd6e5d6bfe39988f937f48768c61e5c01600000000

git @ b0ebed0

Reproducibility: always

Steps: pzec import /Zcash/blocks

What happened:

...
2019-03-11 01:29:15  INFO sync Imported 230000 blocks
2019-03-11 01:30:40  INFO sync Imported 231000 blocks
2019-03-11 01:32:00  INFO sync Imported 232000 blocks
2019-03-11 01:33:44  INFO sync Imported 233000 blocks
2019-03-11 01:35:39  INFO sync Imported 234000 blocks
2019-03-11 01:37:24  INFO sync Imported 235000 blocks
thread 'main' panicked at 'Corrupted database - no sprout root for block 14b054be76b515b12efcfdfd6e5d6bfe39988f937f48768c61e5c01600000000', src/libcore/option.rs:1008:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:49
   1: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:71
             at src/libstd/sys_common/backtrace.rs:59
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:211
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:227
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:491
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:398
   6: std::panicking::try::do_call
             at src/libstd/panicking.rs:325
   7: core::ptr::real_drop_in_place
             at src/libcore/panicking.rs:95
   8: <T as core::any::Any>::get_type_id
             at src/libcore/option.rs:1008
Abort trap: 6

Expected result: All blocks are imported.

opened by rex4539 10

Cannot append block: Verification("Transaction(1, Signature(0, EvalFalse))")

2019-04-11 22:11:00  TRACE import::blk Opening blk file: "/Users/rex/Library/Application Support/Zcash/blocks/blk00129.dat"
2019-04-11 22:22:58  INFO sync Imported 413000 blocks
2019-04-11 22:40:55  INFO sync Imported 414000 blocks
2019-04-11 23:00:30  INFO sync Imported 415000 blocks
2019-04-11 23:19:04  INFO sync Imported 416000 blocks
2019-04-11 23:36:06  INFO sync Imported 417000 blocks
2019-04-11 23:53:53  INFO sync Imported 418000 blocks
2019-04-12 00:14:09  INFO sync Imported 419000 blocks
Cannot append block: Verification("Transaction(1, Signature(0, EvalFalse))")

https://www.dropbox.com/s/v3uk6lo9y99ll4z/blk00129.dat?dl=0

F0-consensus 💣

opened by rex4539 6

Update + read + verfiy sapling commitment tree where required
closes #27

Could be reviewed commit-by-commit:

this one - updates commitment tree when block is inserted into db;

this one - introduces last (needs double check when we'll close #3) Sapling-related verification step - checks that final_sapling_root field of the block header matches computed;

this one - reads Sapling commitment tree state when getblocktemplate RPC is executed.

There's a single quite important TODO left there - we do not need to save default (empty) commitment tree states until Sapling is really activated. This would either require db level to know about ConsensusParams or some other heuristic (probably - return default state if there's no state in db OR do not save state until non-default state is first met). I'll file a separate issue about that.
A0-pleasereview 🤓
opened by svyatonik 6
Ignore zero-filled gaps in blk files

closes #82

Looks like the blk-files structure slightly differs from what we were assuming earlier. Here you can find file having extra 7 zero bytes between blocks #248859 and #248860. Parsing blocks index file (the file that has pointers to blocks positions in blk files) has never been in our plans. So the only solution I could think of is to skip inter-block bytes until first non-zero byte is met. Block is always prefixed by magic and, iirc, magic is designed not to have zero bytes in it (on all BTC-like chains) => that should work (only if gaps are zero-filled, though).
A0-pleasereview 🤓 M4-core ⛓

opened by svyatonik 4
RPC methods meta issue
[x] BlockChain:

[x] getbestblockhash;

[x] getblockcount;

[x] getblockhash;

[x] getdifficulty - currently returns difficulty of the best block. Should calculate difficulty for next block. TODO: check pbtc;

[x] getblock - update response with ZCash-specific fields;

[x] gettxout - check if we need non-transparent addresses for this;

[x] gettxoutsetinfo - not implemented in pbtc.

[x] Miner:

[x] getblocktemplate - update with ZCash-specific fields (finalsaplingroot).

[x] Network:

[x] addnode;

[x] getaddednodeinfo;

[x] getconnectioncount.

[x] Raw:

[x] sendrawtransaction;

[x] createrawtransaction - update with ZCash-specific fields + addresses;

[x] decoderawtransaction - not implemented in pbtc.

[x] getrawtransaction - not implemented in pbtc.
opened by svyatonik 4

Disconnect multiple peers during sync

As first mentioned in #95, it appears that valid peers are disconnected, after reporting one of several types of errors. Sequences of disconnect messages 24 hours apart show all the peers in the covered range (1-7 and 4561-4570) erroring out. Moreover, multiple consecutive peers are blamed for causing the very same error, which is a virtual impossibility, like disconnect of 2&3. All other disconnects shown, groups of peers 5-7 and 4561- (except 4562 and 4566) are blamed for the very same error.

2019-04-18 10:17:57 UTC WARN sync Disconnecting from peer#1 due to DoS: Provided wrong block 0000000003f9a4833161d37c1f31ef1a0b71ea8a3e2e9fa721bfcf046e1aab45
2019-04-18 10:18:05 UTC WARN sync Previous header of the first header from peer#2 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-18 10:18:05 UTC WARN sync Disconnecting from peer#2 due to misbehavior: Too many failures.
2019-04-18 10:18:06 UTC WARN sync Previous header of the first header from peer#3 `headers` message is unknown. First: 00000000027e2c0327c34a234ea8998eaf150717d6e72e0c713307df65817d20. Previous: 00000000022f316560ddbfe7c0ac819a5f3a4f476c70bb5e0fd77a6fafb86d6b
2019-04-18 10:18:06 UTC WARN sync Disconnecting from peer#3 due to misbehavior: Too many failures.
2019-04-18 10:18:07 UTC WARN sync Previous header of the first header from peer#4 `headers` message is unknown. First: 00000000027e2c0327c34a234ea8998eaf150717d6e72e0c713307df65817d20. Previous: 00000000022f316560ddbfe7c0ac819a5f3a4f476c70bb5e0fd77a6fafb86d6b
2019-04-18 10:18:07 UTC WARN sync Disconnecting from peer#4 due to misbehavior: Too many failures.
2019-04-18 10:18:36 UTC WARN sync Disconnecting from peer#6 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-18 10:18:36 UTC WARN sync Disconnecting from peer#5 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-18 10:18:46 UTC WARN sync Disconnecting from peer#7 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255

2019-04-19 09:52:57 UTC WARN sync Disconnecting from peer#4561 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-19 09:53:05 UTC WARN sync Disconnecting from peer#4562 due to misbehavior: Got 'headers' message without known blocks
2019-04-19 09:55:18 UTC WARN sync Disconnecting from peer#4563 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-19 09:59:35 UTC WARN sync Disconnecting from peer#4564 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-19 09:59:36 UTC WARN sync Disconnecting from peer#4565 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-19 10:00:35 UTC WARN sync Disconnecting from peer#4566 due to misbehavior: Got 'headers' message without known blocks
2019-04-19 10:00:46 UTC WARN sync Disconnecting from peer#4567 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-19 10:00:47 UTC WARN sync Disconnecting from peer#4568 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-19 10:19:36 UTC WARN sync Disconnecting from peer#4569 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255
2019-04-19 10:26:45 UTC WARN sync Disconnecting from peer#4570 due to misbehavior: Provided after dead-end block 0000000001e75867923b1993eeb5e623547537f02d42bfa39aae968ba96b3255

F2-bug 🐞

opened by wkarshat 3

Workspace dependabot dependencies

The primary reason for this is so that Dependabot will auto-detect them and watch their dependencies for upgrades and known security vulnerabilities. I've included 'test-data' here mostly because we want all dependencies inter-consistent when possible even for test data/code, even if that means 'test-data' gets built during 'cargo build --release'.

opened by dconnolly 2
Do not verify headers twice during synchronization

closes #64

This PR marks allows skip of headers verification during block verification IF this header has been verified before (during headers sync). This optimization will work for almost all cases (except for reorganization + probably for cases when we have accidentally switched to saturated state).
A0-pleasereview 🤓 M4-core ⛓

opened by svyatonik 2
Initial PR
The goal of this PR is mostly to prepare a project for further development + to merge some work I've done recently + ~6 months ago. So the idea is:

cleanup (some) BTC/BCH specific code so that we could start developing ZCash node without regard to other chains (ZCash differs from BTC/BCH a bit more than BCH differs from BTC => creating all-in-one client will need some refactoring in pbtc && I suggest to do it after the ZCash node is ready);

merge my initial ZCash commits - they're kinda dirty && will require further cleanup (and probably replacing with external libraries [equihash from librustzcash?]), but they give us ability to start syncing ZCash chain (the node is able to sync to the first block that contains JointSplit, i.e. 396).

So the state of project after this commit:

we're able to serialize/deserialize blocks and transactions of Sprout era;

we're able to sync to the block 396;

not all consensus rules are implemented (and even have stubs) - this is WIP.
opened by svyatonik 2
Fixed panic when header is verifying for (Verifying | Stored) block

closes #97

This has been introduced recently, when headers verification has been moved to the separate thread. In some (rare) cases, we may have end up in situation when (at the same time) block' header is verifying in light_verification_thread and the block itself is verified in the heavy_verification_thread. Once both verifications are completed, block is stored in DB, but it is marked as Scheduled by the sync.
A0-pleasereview 🤓 M4-core ⛓

opened by svyatonik 1
Optimize equihash implementation
This is the first part of #64 . I've eliminated some allocations + extra loops && measured performance. The test was running verify_equihash_solution_works for 1000 times. Here are some results:

old version of parity-zcash Equihash: 0.02655900600075256 secs / 1000 runs;

librustzcash Equihash: 0.01449104799394263 secs / 1000 runs;

new version of parity-zcash Equihash: 0.010416991004603915 secs / 1000 runs.

So the new implementation is ~61% faster than the previous one && ~28% faster than the librustzcash. q.e.d.
A0-pleasereview 🤓
opened by svyatonik 1

Attempted to Leave Type `linked_hashmap::Node<_>` Uninitialized

When I follow the build instructions and run the executable, I get the following panic. This is on Ubuntu 21.04 with Rust 1.58.

thread 'main' panicked at 'attempted to leave type `linked_hash_map::Node<primitives::hash::H256, db::kv::transaction::KeyState<chain::block_header::BlockHeader>>` uninitialized, which is invalid', /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/linked-hash-map-0.4.2/src/lib.rs:174:52
stack backtrace:
   0: rust_begin_unwind
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/std/src/panicking.rs:498:5
   1: core::panicking::panic_fmt
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:107:14
   2: core::panicking::panic
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/panicking.rs:48:5
   3: core::mem::uninitialized
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/mem/mod.rs:676:9
   4: linked_hash_map::LinkedHashMap<K,V,S>::ensure_guard_node
             at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/linked-hash-map-0.4.2/src/lib.rs:174:52
   5: linked_hash_map::LinkedHashMap<K,V,S>::insert
             at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/linked-hash-map-0.4.2/src/lib.rs:305:9
   6: lru_cache::LruCache<K,V,S>::insert
             at /home/john/.cargo/registry/src/github.com-1ecc6299db9ec823/lru-cache-0.1.1/src/lib.rs:119:23
   7: <db::kv::cachedb::CacheDatabase<T> as db::kv::db::KeyValueDatabase>::write
             at ./db/src/kv/cachedb.rs:27:6
   8: db::block_chain_db::BlockChainDatabase<T>::insert
             at ./db/src/block_chain_db.rs:306:3
   9: <db::block_chain_db::BlockChainDatabase<T> as storage::block_chain::BlockChain>::insert
             at ./db/src/block_chain_db.rs:684:3
  10: pzec::util::init_db
             at ./pzec/util.rs:34:4
  11: pzec::commands::start::start
             at ./pzec/commands/start.rs:87:2
  12: pzec::run
             at ./pzec/main.rs:71:8
  13: pzec::main
             at ./pzec/main.rs:48:20
  14: core::ops::function::FnOnce::call_once
             at /rustc/db9d1b20bba1968c1ec1fc49616d4742c1725b4b/library/core/src/ops/function.rs:227:5

opened by johnwstanford 0

no peers for the testnet

❯ RUST_LOG=info RUST_BACKTRACE=1 ./target/release/pzec --testnet 
2019-10-07 16:02:13  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:02:13  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:02:23  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:02:23  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:02:33  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:02:33  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:02:43  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:02:43  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:02:53  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:02:53  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:03:03  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:03:03  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:03:13  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:03:13  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:03:23  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:03:23  INFO p2p::p2p Outbound connections: (0/10)
2019-10-07 16:03:33  INFO p2p::p2p Inbound connections: (0/10)
2019-10-07 16:03:33  INFO p2p::p2p Outbound connections: (0/10)

~/.opt/parity-zcash master 1m 42s
❯ git log -n 1
commit 0f6d26e048a56260b77400fc31986e405947e717 (HEAD -> master, origin/master, origin/HEAD)
Merge: 94bd4a31 9e791e3d
Author: Deirdre Connolly <[email protected]>
Date:   Mon Jun 10 20:38:44 2019 -0400

    Merge pull request #132 from dconnolly/dependabot/cargo/slab-0.4.2
    
    Bump slab from 0.4.1 to 0.4.2

F3-annoyance 💩 M2-config 📂

opened by soc1c 0

Thread 'Heavy verification' panicked

2019-05-24 13:39:03  INFO sync Processed 3 blocks in 65.38 seconds (0.05 blk/s).	Peers: 10 (act: 0, idl: 10, bad: 0).	Chain: [sch:3040 > req:0 > vfy:1127 > db:533648]
thread 'Heavy verification' panicked at 'internal error: entered unreachable code: Trying to re-verify known block: 0000000000bc082bfee78ba6f8b88215e6a2c1c9ed8afeab1ca6efd1801fa91f', verification/src/chain_verifier.rs:56:5
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
             at src/libstd/sys/unix/backtrace/tracing/gcc_s.rs:39
   1: std::sys_common::backtrace::print
             at src/libstd/sys_common/backtrace.rs:70
             at src/libstd/sys_common/backtrace.rs:58
   2: std::panicking::default_hook::{{closure}}
             at src/libstd/panicking.rs:200
   3: std::panicking::default_hook
             at src/libstd/panicking.rs:215
   4: <std::panicking::begin_panic::PanicPayload<A> as core::panic::BoxMeUp>::get
             at src/libstd/panicking.rs:478
   5: std::panicking::continue_panic_fmt
             at src/libstd/panicking.rs:385
   6: std::panicking::try::do_call
             at src/libstd/panicking.rs:340
Abort trap: 6

F1-panic 🔨

opened by rex4539 2

Multiple errors on sync

I have finally imported the blockchain :)

Now, when I run pzec, I see multiple errors.

2019-04-17 06:36:30  WARN sync Disconnecting from peer#1 due to misbehavior: Got 'headers' message without known blocks
2019-04-17 06:36:30  WARN sync Last peer was marked as non-useful. Moving to saturated state.
2019-04-17 06:36:39  WARN sync Last peer was marked as non-useful. Moving to saturated state.
2019-04-17 06:36:39  WARN sync Disconnecting from peer#4 due to misbehavior: Got 'headers' message without known blocks
2019-04-17 06:36:39  WARN sync Last peer was marked as non-useful. Moving to saturated state.
2019-04-17 06:36:49  WARN sync Failed to get requested block from peer#3 in 5.68 seconds.
2019-04-17 06:36:49  WARN sync Too many failures for peer#3. Excluding from synchronization.
2019-04-17 06:36:49  WARN sync Disconnecting from peer#3 due to misbehavior: Too many failures.
2019-04-17 06:36:49  WARN sync Too many header failures for peer#3. Excluding from synchronization.
2019-04-17 06:36:50  WARN sync Previous header of the first header from peer#6 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:36:50  WARN sync Disconnecting from peer#6 due to misbehavior: Too many failures.
2019-04-17 06:36:50  WARN sync Previous header of the first header from peer#7 `headers` message is unknown. First: 0004b371c02c41c61c189ce04ac147220daf796e9a60ce90cfee31e5a71dda2d. Previous: 0007104ccda289427919efc39dc9e4d499804b7bebc22df55f8b834301260602
2019-04-17 06:36:50  WARN sync Disconnecting from peer#7 due to misbehavior: Too many failures.
2019-04-17 06:37:23  WARN sync Disconnecting from peer#12 due to misbehavior: Error verifying header 001bb0d07e628cccfbf2998d27bf18bd0463a44b64bba5664ef786fa17bd5170 from `headers`: "Pow"
2019-04-17 06:37:31  WARN sync Previous header of the first header from peer#14 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:37:31  WARN sync Disconnecting from peer#14 due to misbehavior: Too many failures.
2019-04-17 06:37:40  WARN sync Previous header of the first header from peer#15 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:37:40  WARN sync Disconnecting from peer#15 due to misbehavior: Too many failures.
2019-04-17 06:37:44  INFO sync Processed 120 blocks in 61.15 seconds (1.96 blk/s).	Peers: 6 (act: 6, idl: 0, bad: 1).	Chain: [sch:84 > req:0 > vfy:1064 > db:515558]
2019-04-17 06:37:49  WARN sync Too many header failures for peer#13. Excluding from synchronization.
2019-04-17 06:37:49  WARN sync Disconnecting from peer#13 due to misbehavior: Too many header failures.
2019-04-17 06:37:50  WARN sync Previous header of the first header from peer#16 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:37:50  WARN sync Disconnecting from peer#16 due to misbehavior: Too many failures.
2019-04-17 06:37:51  WARN sync Previous header of the first header from peer#19 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:37:51  WARN sync Disconnecting from peer#19 due to misbehavior: Too many failures.
2019-04-17 06:37:51  WARN sync Previous header of the first header from peer#18 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:37:51  WARN sync Disconnecting from peer#18 due to misbehavior: Too many failures.
2019-04-17 06:37:51  WARN sync Previous header of the first header from peer#17 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:37:51  WARN sync Disconnecting from peer#17 due to misbehavior: Too many failures.
2019-04-17 06:38:00  WARN sync Previous header of the first header from peer#21 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:38:00  WARN sync Disconnecting from peer#21 due to misbehavior: Too many failures.
2019-04-17 06:38:00  WARN sync Previous header of the first header from peer#20 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:38:00  WARN sync Disconnecting from peer#20 due to misbehavior: Too many failures.
2019-04-17 06:38:00  WARN sync Previous header of the first header from peer#22 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:38:00  WARN sync Disconnecting from peer#22 due to misbehavior: Too many failures.
2019-04-17 06:38:20  WARN sync Previous header of the first header from peer#25 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:38:20  WARN sync Disconnecting from peer#25 due to misbehavior: Too many failures.
2019-04-17 06:38:20  WARN sync Previous header of the first header from peer#24 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:38:20  WARN sync Disconnecting from peer#24 due to misbehavior: Too many failures.
2019-04-17 06:38:20  WARN sync Disconnecting from peer#26 due to misbehavior: Provided after dead-end block 001bb0d07e628cccfbf2998d27bf18bd0463a44b64bba5664ef786fa17bd5170
2019-04-17 06:38:30  WARN sync Previous header of the first header from peer#28 `headers` message is unknown. First: 0003eb875fc001da4a57de8465f68a2730c24ca086f37c6f14780ac9ee3ea3d5. Previous: 00052461a5006c2e3b74ce48992a08695607912d5604c3eb8da25749b0900444
2019-04-17 06:38:30  WARN sync Disconnecting from peer#28 due to misbehavior: Too many failures.
2019-04-17 06:38:44  INFO sync Switched to saturated state.	Chain: [sch:0 > req:0 > vfy:1027 > db:515679]
2019-04-17 06:39:09  WARN sync Disconnecting from peer#30 due to misbehavior: Got 'headers' message without known blocks
2019-04-17 06:39:09  WARN sync Last peer was marked as non-useful. Moving to saturated state.
2019-04-17 06:41:10  WARN sync Disconnecting from peer#32 due to misbehavior: Got 'headers' message without known blocks
2019-04-17 06:41:10  WARN sync Last peer was marked as non-useful. Moving to saturated state.

Is this normal?

F3-annoyance 💩 P7-nicetohave 🐕

opened by rex4539 3

Very short test chain
regtest-like short chain which covers all (or most) key consensus features

to be served as an integration test

is fed directly to sync/import code

maybe shared between implementations (@kaplannie ?)

state-machine-like of acceptance evaluation
opened by NikVolf 3