It would be good to make simple merkle a trait (and/or use generics) to make it take any parameter that can be hashable or to make it easy to swap the underlying hash algo. See comment in: #59 (review)

While at it, we can also rename the method's name: #59 (comment)

As per some RPC incompatibilities being discovered, namely #88 and #4, we should have the CI spin up a tendermint node, eg. using the latest docker image, and run the currently ignored integration tests against it (via cargo test -- --ignored) - see #88 (comment)

I've tested the (ignored) integration tests for rpc against a tendermint 0.32.7 version and the following tests fail:

abci_info and genesis

• genesis fails with: called Result::unwrap() on an Err value: Error { code: ParseError, message: "Parse error. Invalid JSON", data: Some("invalid digit found in string at line 11 column 26") }
• abci_info with: called Result::unwrap() on an Err value: Error { code: ParseError, message: "Parse error. Invalid JSON", data: Some("missing field last_block_height at line 9 column 5") }

#85 (comment)

I've also noted that example responses on https://docs.tendermint.com/master/rpc/#/ have a numeric id (every JSON rpc request comes with such an id):

{
  "jsonrpc": "2.0",
  "id": 0,
  "result": {

while on my local 0.32.7 returns a string based id "id": "",.

We should make sure to support both as the spec says:

An identifier established by the Client that MUST contain a String, Number, or NULL value if included.

https://www.jsonrpc.org/specification#request_object

Compatibility with some tendermint version is also relevant in the context of a light client making requests via rpc.

I am trying to use the client RPC to interact with the basic abci-cli kvstore application.
I have run tendermint node and abci-cli kvstore from two terminals.
RPC calls with curl as in the examples here all work as expected.

To try and broadcast a transaction from rust I use the following code:

use tendermint::rpc::Client;

fn main() {
    let client = Client::new(&"tcp://127.0.0.1:26657".parse().unwrap()).unwrap();

    let j = "abcd";

    let tx = tendermint::abci::transaction::Transaction::new(j.as_bytes().to_owned());
    let response = client.broadcast_tx_sync(tx).unwrap();
    println!("{:?}", response);
}

I am getting the error

thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: ParseError, message: "Parse error. Invalid JSON", data: Some("invalid type: integer `0`, expected a string at line 5 column 13") }', src/libcore/result.rs:1084:5

When calling curl 'localhost:26657/abci_query?path=""&data="abcd"&prove=false' afterwards, I do get a response where I can see that abcd was indeed stored successfully, so the problem is with parsing the response on the client side.

From some poking around it seems that this has to do with the Code field in the response, perhaps it should be "0" and not 0.

Any help solving this is appreciated. Is this a problem of the RPC documentation?

The light client is coming together well, and has some integration tests starting from JSON data generated from Tendermint in Go to test the verify and check_support functions (see tests/lite.rs).

Now that the abstractions are cleaner, we should be adding unit tests to the lite module that use simple mocks for all the traits. These mocks should look basically like what we find in the TLA+ spec, ie. where validator ids are simply integers and a commits just contain the ids of the validators that signed.

As per #110 and #111, we should simplify the public API and have a single primary public function for trying to update the trusted state without making any intermediate requests. The bisection function should use this function. Then we shouldn't need to test verify and check_support independently, as they'd be covered by this new function. Then we'd have two kinds of tests:

1. tests of the new function which cover a "single step". this would be effectively what IBC would use. We'd test for errors like expiration, invalid data, not enough voting power, etc, and we'd test various non-error cases
2. tests for bisection (ie. the current verify_header function). We'd build some mock of a blockchain and instantiate a Requester with it so we can test bisection against different possible existing chains. We'd want to ensure the set of requested headers is correct, as well as all verification results.

In both cases, the tests should map clearly to possible traces from TLC, so that we can generate new tests by running TLC.

We also need a third class of tests:

3. tests for the specific implementations of the traits, primarily of voting_power_in. This would check various actual instantiations of the Tendermint Commit structure and a Validator Set. Would need to ensure nil-votes don't count towards the voting power, and that we error on invalid signatures and on signatures for the wrong block id.

The RPC client presently uses a synchronous blocking I/O-based approach, built on a now ancient hyper v0.10 as the HTTP client.

Upstream hyper is just about to land tokio v0.2 support: hyperium/hyper#2025

...and soon thereafter, will hopefully have a v0.13 release with stable-ish async/await.

When that happens, it'd be great to update the RPC client to use it.

The RPC client encodes the data field for the abci_query endpoint into a JSON array of byte values, but the Tendermint side expects a hex string. This means every request fails, even with an empty data field.

The Commit and CommitSig struct in Go code has been updated to Commit and CommitSig , while we are using the older version which looks like this:
type Commit struct { BlockID BlockID, Precommits []*CommitSig } and type CommitSig Vote

This makes the current Rust implementation incompatible with the current Go implementation and we cannot validate these SignedHeader.

I was looking into the RPC endpoints and noticed that the integration tests are not running anymore.

I think that is because the tests directory got moved out of the module and is now a separate directory. Moving them back into a module (e.g. the tendermint directory fixes this). Alternatively, tests could be a separate crate referred to by the root Cargo.toml.

(related #38 #4)

Tendermint RPC has some endpoints which allow you to specify height parameter, but if left empty it will return information from the latest height. This is distinct from RPC requests with height=0 set explicitly, which return errors.

The RPC client should respect this. For instance, this was done for the /commit endpoint here: 7477c9d. It should be done for others as well.

That said, these RPC methods shouldn't take a Height that can be 0 - they should instead take an enum that contains either a Height, or some indicator for LatestHeight, which maps to empty parameters in the underlying RPC call - ie. #117 (comment)

Now that the library logic and bisection are nearing completion in #96 and the relevant follow up issues (#110, #111), we should implement the daemon that puts it all together.

This requires:

• initial config with subjective initialization and list of peers
• simple address book to track peers and manage primary/backups
• detection module to make requests from backup peers, search for conflicts, and publish any verified ones
• concrete implementation of the store
• command line tool

To start, let's get a simple command line tool that works in the single peer case with a simple store, and then work on the detection module for detecting conflicts from backup peers.

I've noticed that the badges in the readme still point to those of the kms (license, build).

Also, I think it would be a good idea to enable clippy in circle-ci. The kms repo has an example on howto do so:
https://github.com/tendermint/kms/blob/3b3aabf8eab64959dad29ee2d5b747dc5fe813ac/.circleci/config.yml#L16-L20

Secret Connection is a bit heavy duty for this library. It's currently needed by the KMS, and will likely see some upgrades in the near term that will need to be closely integrated with the KMS (ie. to support timeouts via async/await - #2). See also the relevant dependency issue #11 and PR #21.

We likely won't won't need Secret Connection here for a while as we're focusing first on the light client and deterministic simulation of reactors, and by the time we look to integrate with peers, with any luck, a libp2p solution will be ready for Tendermint adoption.

Copying/pasting this from the original issue at tendermint/tmkms#310

The Secret Connection implementation presently has no notion of timeouts for things like connecting/"dialing" validators or reading from/writing to sockets.

Without timeouts, there are many cases which could potentially deadlock indefinitely inside of blocking I/O operations, and at least one user has experienced this.

Here are a few recommendations:

• futures/tokio: this is the up-and-coming ecosystem solution to this general problem, and the one I'd recommend. It's a full asynchronous event model which solves, among other things, timeouts. When async/await support ships in Rust 1.38 (scheduled to be released in August), migrating from blocking I/O should be fairly straightforward.
• libc crate + poll(2) system call: if we wanted to stick with blocking I/O, the poll(2) system call, as invoked through the libc crate, can be used to determine I/O readiness prior to performing a blocking I/O call, and also takes a timeout as an argument. This would probably be the lowest impact way to implement timeouts as it wouldn't involve switching away from blocking I/O.

I would suggest migrating to futures-rs/Tokio to solve this problem, and leveraging the async/await syntax when it lands later this month.

Follow up to #110 Module Structure:

• lite -> light
• Remove dependency of light on tendermint::Hash
• Move light to be its own crate in the workspace
• Rename light_impl -> light (since the old light will be moved up into its own crate)
• Rename light/types.rs to light/interface.rs and break out an errors.rs (#100 (comment))
• Add example to doc
• Unpublicize verify_commit_full and verify_commit_trusting (6bf0675)

Currently there are a handful of cases where the From trait is implemented and the implementation can panic. This is usually addressed with a conversion to a TryFrom implementation. See 71f0cd3 and https://rust-lang.github.io/rust-clippy/master/index.html#fallible_impl_from

Copying/pasting this from tendermint/tmkms#233 as reported by @mdyring

error: tmkms fatal error: config error: error loading config from '/opt/tmkms/config/tmkms.toml': parse error: invalid tcp:// address: tcp://4c65d33a701e10db9cbc33986aefe6c1d839c691@[2a05:d014:c32:e844:673e:bfa7:6700:4f1e]:26658 for key `validator.addr`

Not sure if this is only a parsing problem or IPv6 networking is not supported at all?

Would greatly appreciate if this could be supported.

Tracking TODOs for the Light client impl

Feedback / Review of #84

• Move additional checks to validate_vals_and_commit and make it function of Commit(?): #84 (comment) - done in #109
• redundant check for sigs: #84 (comment), tendermint/spec#61 (comment)
• #84 (comment) (and general organizational issues: e.g. crate vs module etc)
  • remove dependencies on tendermint types (account::Id, Hash)
• add example to doc: #84 (comment)
• From<SystemTimeEror> for lite::Error and #84 (comment). Done in #109
• #84 (comment) (return OK?) - Done in #109
• remove Validator trait ? #84 (comment) - done in #105
• how to handle if/when votes don't contain validator id? probably worth discussing in separate issue: #84 (comment) - done, added a comment in #109
• next steps: #84 (comment)
• rename types.rs to interface.rs - #100 (comment)
• consider Client type and have can_trust be a method on the Client. Also put trust_threshold and trusting_period in the trusted state? #100 (comment)
• enforce off-by-one issues in the type system if possible, eg. TrustedState::new taking header h-1 and validators for h. #100 (comment). Also verify taking vals for the right height #100.
• Error::RequestFailed should wrap underlying requester errors. #100 (comment)
• Improve naming of variables like h1_xxx and h2. This should also be done simultaneously with the spec. eg. #100 (comment) and #100 (comment) and https://github.com/interchainio/tendermint-rs/pull/100/files#r360479080
• how to get latest height from a node? use height=0 ? #100 (comment). Could get rid of get_smaller_or_equal (#100). Need to do with spec.
• improve logic of check_support to better clarify the 3 conditions: ok (update state), real error (faulty node or system), not-enough-voting-power (not real error, just need to bisect)
• make trust_level satisfy Copy or Clone and don't pass by reference #100

The struct for the /commit rpc response is currently different from the go-lang implementation. This could be on purpose: commits were or are about to be refactored (to consist of only signatures).
The light client will talk to the rpc endpoint exposed by tendermint. Hence, the types should now match the go implementation (or introduce a new compatible type exclusively for the light client if desired).

Current SignedHeader in Rust:
https://github.com/interchainio/tendermint-rs/blob/5844dc5c0faa537b4225c5221cd863285b97d8ce/tendermint/src/rpc/endpoint/commit.rs#L44-L47

SignedHeader in golang:
https://github.com/tendermint/tendermint/blob/51dc810d041eaac78320adc6d53ad8b160b06601/types/block.go#L708-L713

encapsulated in the ResultCommit response:
https://github.com/tendermint/tendermint/blob/51dc810d041eaac78320adc6d53ad8b160b06601/rpc/core/types/responses.go#L34-L37

by this endpoint:
https://github.com/tendermint/tendermint/blob/51dc810d041eaac78320adc6d53ad8b160b06601/rpc/core/blocks.go#L317

ref: #31 #36

Github Actions is an alternative to circleci. It looks worth exploring! Things like code coverage and uploading to codecov.io looks much simpler for instance (it's a bit like circleci's orbs but integrated into github; also the snippets are hosted here on this platform)

Discussion started here:
#134 (comment)

Since TrustedState is supposed to be stored, so it'll need serialization. But users can't implement trait for external types, so it's better to builtin?

Replacement for elements of #96 more specific to Rust implementation style and architecture.

We should update the ADR with the relevant changes from here as well.

Types:

• Make validate_vals_and_commit a method on Commit (#84 (comment))
• Use validate_next_vals !
• Introduce a Client type to hold Store and Requester (?) (#100 (comment))
• Put trust_threshold and trusting_period in the Store (?) (#100 (comment))
• Enforce off-by-one issues in the type system, eg.:
  • TrustedState::new taking header h-1 and validators for h (#100 (comment))
  • verify taking vals for the right height (#100)
• make trust_level satisfy Copy or Clone and don't pass by reference (#100)
• memoize results of methods that don't take args, eg. .hash() (#96 (comment))
• use an enum for height to get the latest state instead of special-casing 0 (#118)
• introduce a simple event type and let bisection function (or a Client structure it's a method on) take a closure that will fire events. this can be used for logging so we don't need a print statement or logger inside the functions

Module Structure:

• Remove dependency on tendermint types, eg. Hash
• Make it a crate ?
• Rename types.rs to interface.rs (#100 (comment))
• Add example to doc
• Simplify the public API and make it harder/impossible to use incorrectly
• Unexpose verify_single once json tests are updated (525c89f#diff-f0c5bdd887eaf26a3fd9ec5bdc93e2d9R106 and 9fbb749#diff-afc724a3f81219fadc771326ccca3a84R8)

Errors:

• Error::RequestFailed should wrap underlying requester errors (#100 (comment))
• Deduplicate the Error::InvalidSignature with ErrorKind::SignatureInvalid
• Move to an error.rs file
• voting_power_in can't detect signatures from validators not in the current validator set (can't detect signatures from validators not in the current validator set)
• need two distinct errors for InsufficientVotingPower - one when it's insufficient to skip (ie. so do bisection) and one when it's insufficient to verify (ie. return error) #119

This first block in Tendermint is unique in that all of the last_xxx fields are actually empty, while in normal operation they are required to not be empty. On the other hand, some fields can be empty in normal operation (eg. app_hash, data_hash, evidence_hash). Recent PRs like #66 have been dealing with this by making all fields that can be empty Options, but it may be clearer if there is actually an explicit FirstBlock type that doesn't have the empty fields and and we reserve Option only for the fields that can be empty in normal operation. See the discussion in #66.

Another possibility is to clean this up by making a chance in the underlying tendermint protocol, see tendermint/tendermint#4241

We could look into https://github.com/libra/libra/blob/ead737947aa59499ea75b5a926d221ac089ce803/.circleci/config.yml#L51-L58
and
https://github.com/libra/libra/blob/ead737947aa59499ea75b5a926d221ac089ce803/scripts/coverage_report.sh#L97-L104
for a good example how to do this.

Original issue here: tendermint/tmkms#48

Follow up to #110 Types:

• memoize results of methods that don't take args, eg. .hash() (#96 (comment))
• introduce a simple event type and let bisection function take a closure that will fire events. this can be used for logging so we don't need a print statement or logger inside the functions

Also follow up to PR review:

• #132 (review)

Currently we have fn simple_hash_from_byte_slices(byte_slices: &[&[u8]]) -> Hash

But this leads to some complexities in the few places it's so far used:

• https://github.com/interchainio/tendermint-rs/blob/10a3026cfbd4ab333752d344645a4f07ecdc29f7/tendermint/src/validator.rs#L23-L35
• https://github.com/interchainio/tendermint-rs/pull/36/files#diff-a1644bb72a1c83c54d82738ef71ce095R126 (ie. the need for a separate variable followed by as_slice would go away)

Right now we have a ton of diverse functionality directly under src. Might be better to organize this a bit better, for instance, at a high level:

src/
  abci/
    abci/
    abci.rs
  amino/
    amino_types/
    amino_types.rs
  types/
    block/
    block.rs
    chain/
    chain.rs
    consensus
    consensus.rs
    evidence.rs
    genesis.rs
    hash.rs
    time.rs
    timeout.rs
    validator.rs
    version.rs
    vote/
    vote.rs
  config/
    config/
    config.rs
  crypto/
    merkle.rs
    private_key.rs
    public_key.rs
    signature.rs
  error.rs
  lib.rs
  p2p/
    channel/
    channel.rs
    moniker.rs
    net.rs
    node
    node.rs
    secret_connection/
    secret_connection.rs
  rpc/
    rpc/
    rpc.rs
  serializers.rs

Then for things like

  amino/
    amino_types/
    amino_types.rs

and

  abci/
    abci/
    abci.rs

we can probably consolidate further.

Copying/pasting this from tendermint/tmkms#301 as reported by @devashishdxt

Batched RPC requests are supported by tendermint since v0.31.6

tendermint/tendermint#3534

Replacement for elements of #96 more specific to specification. These need to be updated synchronously with the spec:

• capture the validation functions more explicitly in the spec and align with their use in the code
• redundant check for sigs (#84 (comment), tendermint/spec#61 (comment))
• Improve naming of variables like h1_xxx and h2 (#100 (comment), #100 (comment))
• how to get latest height from a node? use height=0 ? Could get rid of get_smaller_or_equal (#100 (comment))
• improve logic of check_support to better clarify the 3 conditions: ok (update state), real error (faulty node or system), not-enough-voting-power (not real error, just need to bisect)
• possible move validity checks from check_support to valdiate_vals_and_commit ...
• add a single function that can be called by IBC that doesn't use a requester but otherwise does all checks necessary to update the store with a new trusted state. Ideally this function can be used by a function that does use the Requester

After chatting with @Shivani912, this comment here #150 (comment) should probably be made into a short ADR instead.

While at it, verify there are still places where this comment applies, mention in a sentence in the ADR and modify the code too: #158 (comment)

We need to differentiate between voting power erorrs originating from skipping and verification. Reference

As per #110 (comment):

• ensure that time in headers is monotonic, ie. untrusted_header.bft_time() > trusted_header.bft_time() in verify_single (see #142)
• check that the blockchain is not ahead of our local clock, ie. untrusted_header.bft_time() < now + X for every header we fetch

In theory, if we check that time is monotonic, we only need to check that the highest height we're trying to sync to is not ahead of our local clock (ie. we don't need to check this for every header, since all the other headers are less than the highest one). However, if we only check for monotonic time after we've trusted a pivot header, its possible we would trust a pivot header who's time is too far ahead of our local clock, and hence might be outside the trusting period.

Follow up to #110 Errors.

• Error::RequestFailed should wrap underlying requester errors (#100 (comment))
• Other error types should wrap relevant data
• Remove Error::InvalidSignature? It's not used directly by the light package, only by implementations

After merging in #146 master fails to build. Although github didn't show any merge conflicts this due to the change in error handling. I'll fix in a bit!

This is sth we should keep in mind with other PRs related to the light client.

enable https://dependabot.com/ to handle version upgrades for the repo.

In light of recent discussions regarding the spec and ADR processes for Tendermint, would it make sense to have a docs or adr folder in the tendermint-rs repo to allow us to discuss and record architectural decisions specific to the Rust implementation?

An example of what would require such an ADR: in implementing a reactor-style model in a similar manner to the Go version of Tendermint, should we roll our own again or should we make use of some kind of Tokio-based framework such as Actix? And if we go with a framework, how do we create/design/document some kind of interface to it that doesn't lock us into using that particular framework?

• make sure we return Error everywhere and not Kind (#149 (comment))
• use anomaly::fail: #151 (comment)
• not really error related but intro a expires_at variable #149 (comment)

Discuss absorbing the rust-abci repo as its own crate within this repo.

We've been tracking everything in a CHANGES.md but in a relatively unstructured way. We should be separating changes into Breaking/Features/Improvements/Fixes and reduce the need to copy links. We can import some discipline from the tendermint repo re it's CHANGELOG.md and CHANGELOG_PENDING.md (see here for description), and the linkify_changelog.py script.

We can also adopt some best practices from https://keepachangelog.com/en/1.0.0/

Recently we haven't been enforcing pull requests to update the changes file, which we should start doing. I've added a PR template in #92 that includes a check for this.

We also need to determine when a contributor should be added to the authors section of the config.toml ...

Acceptance test: done for v0.16.0

We need a merkle.SimpleHashFromByteSlices equivalent in the rust code base to be able to recompute the hash of the header.

This will also be relevant in the light client.

The ring crate (BoringSSL crypto primitives wrapped in Rust) is two versions out-of-date (currently 0.14, latest 0.16), and unfortunately like most other Rust crates, does not allow two versions to be linked simultaneously. I just updated Signatory and yubihsm-rs to use ring 0.16, but they're presently incompatible with the KMS due to the older version used by this crate:

$ cargo test --all --all-features -- --test-threads 1
    Updating crates.io index
error: failed to select a version for `ring`.
    ... required by package `yubihsm v0.27.0`
    ... which is depended on by `tmkms v0.6.3 (/Users/bascule/src/tmkms)`
versions that meet the requirements `^0.16` are: 0.16.6, 0.16.5, 0.16.4, 0.16.3, 0.16.2, 0.16.1, 0.16.0

the package `ring` links to the native library `ring-asm`, but it conflicts with a previous package which links to `ring-asm` as well:
package `ring v0.14.0`
    ... which is depended on by `tendermint v0.10.0`
    ... which is depended on by `tmkms v0.6.3 (/Users/bascule/src/tmkms)`

failed to select a version for `ring` which could resolve this conflict

All ring is used for is the ChaCha20Poly1305 implementation, which for me it seems like a particularly heavyweight dependency if we're only using it for that.

I've been contributing to the chacha20 crate as part of RustCrypto stream ciphers, which provides a potential replacement.

The KMS needs to know the correct round step of the consensus state for double signing detection:

https://github.com/interchainio/tendermint-rs/blob/566dfb6/src/amino_types/vote.rs#L170

See this PR for how the KMS is parsing it:

tendermint/tmkms#348

As per #19, one of the decisions we have to make is whether to roll our own reactor framework (as in the Go version of Tendermint) or use an existing framework (such as Actix, based on Tokio) to handle all that for us.

Whichever approach we choose, we should abstract the relevant reactor functionality in such a way that we can swap out the framework at a later stage if necessary. This would potentially also allow us to have multiple implementations and swap them out by way of feature flags.

My preference is to design the abstract reactor pattern we want, and then if Actix will allow us to facilitate that design then we go with Actix (at least at first, to give us some momentum).

Right now there's an Ord impl on consensus::State which I think needs to be rewritten to better match the Tendermint consensus spec:

impl Ord for State {
    fn cmp(&self, other: &State) -> Ordering {
        if self.height < other.height {
            Ordering::Less
        } else if self.height == other.height {
            if self.round < other.round {
                Ordering::Less
            } else if self.round == other.round {
                self.step.cmp(&other.step)
            } else {
                Ordering::Greater
            }
        } else {
            Ordering::Greater
        }
    }
}

First, I think this should be changed to PartialOrd, and consensus::State shouldn't have or derive Ord. Namely there are some cases (particularly with the handling of <nil> block IDs) where the state comparison is invalid, and these are the specific cases we want to handle for double signing. Being able to allow a partial ordering while recognizing some comparisons are invalid is precisely why PartialOrd exists.

The current consensus::State has a block_id: Option<block::Id> field which I think should be changed to just block_id: block::Id. Namely, the block::Id type is already able to capture the case of the hash being <nil> in that the block hash can be Hash::Null. By leveraging this variant, it should be able to add the BlockID.IsZero() and BlockID.IsComplete() functions to tendermint-rs's block::Id type, and with those implement a PartialOrd that faithfully reflects the spec.

Copying/pasting this from tendermint/tmkms#286 as reported by @devashishdxt

In tendermint/tendermint#3643, tags were changed to events (event now have an event_type and a list of tags). This change will affect RPC calls such as /block_results (https://github.com/tendermint/kms/blob/master/tendermint-rs/src/abci/responses.rs#L71).

• Make a better diagram
• Rename the "Manager" to eg. "Syncer" - #54 (comment)
• Consider abstracting away individual signature checking from the traits - #54 (comment)

Follow up to one point in #110:

The voting_power_in method can't detect signatures from validators not in the current validator set. While this isn't really a big deal, since we can't be fooled into accepting something that wasn't correctly signed, there is no good reason for us to receive a commit with a signature from a validator who's not in the validator set, and thus we should be able to detect it and mark the full node we got it from as faulty.

• Related discussion: #149 (comment)

• Reasoning in abscissa repo: iqlusioninc/abscissa#144

• Good read: https://blog.yoshuawuyts.com/error-handling-survey/

Currently:
https://github.com/interchainio/tendermint-rs/blob/f9287e04ee84e6659ea209529a1bb700ab53e45b/tendermint/Cargo.toml#L36

Used in:

• tendermint-rs/error.rs
• tendermint-rs/amino_types/validate.rs
• tendermint-rs/rpc/error.rs

We should switch to a combination of thiserror + anonmaly for the whole code base as done in #151 and #149 for the light client module.

The config options introduces in #121 are causing some confusion. Maybe we should revert them, or, simply wait until they hit stable and close this issue then. Until then I'll keep this here for context for cointributors: You can ignore the warnings below: