In 67659677d4 we relaxed the bounds
set on `UtxoLookup` to enable those using `RoutingMessageHandler`
other than `P2PGossipSync` to use `UtxoLookup`. Sadly, because this
requires having a concrete `PeerManager` type which does *not* use
`UtxoLookup` in the `RoutingMessageHandler` type, this broke users
who were directly using `P2PGossipSync`.
We could split `UtxoLookup` into two, with different bounds, for
the two use-cases, but instead here we simply switch to storing a
reference to the `PeerManager` via a `dyn Fn` which allows us to
wake the `PeerManager` when we need to.
Fixes#2813
ChainHash is more appropriate for places where an arbitrary BlockHash is
not desirable. This type was introduced in later versions of the bitcoin
crate, thus BlockHash was used instead.
Using ChainHash also makes it easier to check if ChannelManager is
compatible with an Offer.
Our tests should generally not rely on internet access, and should
not rely on the behavior of any given remote server. However, one
of the `endpoint_tests` in `lightning-block-sync::http` relied on
`foo.com` resolving to a single socket address, which both might
change in the future and makes our tests fail without internet.
The BOLT spec mandates that channels not be announced until they
have at least six confirmations. This is important to enforce not
because we particularly care about any specific DoS concerns, but
because if we do not we may have to handle reorgs of channel
funding transactions which change their SCID or have conflicting
SCIDs.
In LDK, we expect users operating nodes on the public network to
implement the `UtxoSource` interface in order to validate the
gossip they receive from the network.
Sadly, because the DoS attack of flooding a node's gossip store
isn't a common issue, and because we do not provide an
implementation off-the-shelf to make doing so easily, many of our
downstream users do not have a `UtxoSource` implementation.
In order to change that, here we implement an async `UtxoSource`
in the `lightning-block-sync` crate, providing one for users who
sync the chain from Bitcoin Core's RPC or REST interfaces.
This is actually a valid response in some cases, at least for the
`gettxout` command, where `null` is returned if no corresponding
UTXO was found, but the command otherwise succeeded.
`rust-bitcoin v0.30.0` made some changes in this area that no longer
allow us to work with the previously exposed `U256` type. While `Work`
and `Target` (they're inverses of each other) essentially represent the
same concept, it makes more sense from their API's perspective to only
expose difficulty transitions and adjustments on `Target`s.
In general, only one request will be in flight at a time in
`lightning-block-sync`. Ideally we'd only have one connection, but
without using the `futures` mutex type.
Here we solve this narrowly for the one-request-at-a-time case by
caching the connection and takeing the connection out of the cache
while we work on it.
Some how I'd understood that `futures` had reasonable MSRV
guarantees (e.g. at least Debian stable), but apparently that isn't
actually the case, as they bumped it to upgrade to syn (with
apparently no actual features or bugfixes added as a result?) with
no minor version bump or any available alternative (unlike Tokio,
which does LTS releases).
Luckily its relatively easy to just drop the `futures` dependency -
it means a new connection for each request, which is annoying, but
certainly not the end of the world, and its easier than trying to
deal with pinning `futures`.
See https://github.com/rust-lang/futures-rs/pull/2733
`serde` doesn't bother with MSRVs, so its expected to break
frequently. Yesterday, the `derive` feature had its MSRV broken in
a patch version without care.
Luckily its trivial for us to remove the `serde` dependency in
`lightning-block-sync`, using only `serde_json` for the JSON
deserialization part. It even ends up net-negative on LoC.
Users of the RpcClient had no way to access the error code
returned by bitcoind's rpc. We embed a new RpcError struct
as the inner error for the returned io::Error. Users can access
both the code and the message using this inner struct.
