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.

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

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.

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).

• [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.

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

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'.

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).

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.

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.

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:

1. old version of parity-zcash Equihash: 0.02655900600075256 secs / 1000 runs;
2. librustzcash Equihash: 0.01449104799394263 secs / 1000 runs;
3. 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.

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

❯ 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

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

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?

• 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