Alexis Sellier

Futures-based client API

3

Currently, the client API is channel based, via `crossbeam-channel`. It would be worth exploring what a futures-based API might look like around `Client` and `client::Handle`.

:massage:

To have a higher chance to connect to peers with `NODE_COMPACT_FILTERS` support, we could use the service bit filtering functionality of DNS seeds. This is not a very well documented...

Starting thinking about how a C FFI would look, as the API stabilizes. For now, this FFI should only be around the `nakamoto-client` crate.

BIP 151

4

Peer-to-peer layer encryption. https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki This hasn't landed yet in Core (see: https://github.com/bitcoin/bitcoin/pull/14032), but is really on-brand for nakamoto, so it would be cool to support it.

Currently, peer latency is measured in the `PingManager`, but not used. * We should keep track of latencies, persist them (either in the `client::peer::Cache` or some where else. * Use...

Initial block (header) download can be made faster by syncing from multiple peers. To do this, we can use the hard-coded checkpoints to request multiple block ranges.

We should keep track of how much data is read and written to the network. This can be done through the `Reactor`.

It used to be possible to clear textures, but since upgrading to 0.47 I can't figure out how to do that anymore. What's the way?