We upstream the `lightning-liquidity` into the `rust-lightning`
workspace.
Files are copied over as per commit c80eb75f5a31bea5c2b73e41c50ca382ec0020f8.
When a lightning node wishes to send payments to a BIP 353 human
readable name (using BOLT 12), it first has to resolve that name to
a DNS TXT record. bLIP 32 defines a way to do so over onion
messages, and this completes our implementation thereof by adding
the server side.
It operates by simply accepting new messages and spawning tokio
tasks to do DNS lookups using the `dnsse_prover` crate. It also
contains full end-to-end tests of the BIP 353 -> BOLT 12 -> payment
logic using the new server code to do the resolution.
Note that because we now have a workspace crate which sets the
"lightning/dnssec" feature in its `dev-dependencies`, a naive
`cargo test` will test the "dnssec" feature.
Previously, we used the `bdk_macros` dependency for some simple proc
macros in `lightning-transaction-sync`. However, post-1.0 BDK doesn't
further maintain this crate and will at some point probably yank it
together with the old `bdk` crate that was split up.
Here, we create a new crate for utility proc macros and ~~steal~~ add
what we currently use (slightly modified for the latest `syn` version's
API though). In the future we may want to expand this crate, e.g., for
some `maybe_async` macros in the context of an `async KVStore`
implementation.
In order to ensure our crates depend on the workspace copies of
each other in test builds we need to override the crates.io
dependency with a local `path`.
We can do this in one of two ways - either specify the `path` in
the dependency listing in each crate's `Cargo.toml` or use the
workspace `Cargo.toml` to `patch` all dependencies. The first is
tedious while the second lets us have it all in one place. However,
the second option does break `cargo *` in individual crate
directories (forcing the use of `cargo -p crate *` instead) and
makes it rather difficult to depend on local versions of workspace
crates.
Thus, here we drop the `patch.crates-io` from our top-level
`Cargo.toml` entirely.
Still, we do update the `ci/ci-tests.sh` script here to use
`cargo -p crate` instead of switching to each crate's directory as
it allows `cargo` to use a shared `target` and may speed up tests.
`lightning-invoice` currently has a dependency on the entire
`lightning` crate just because it wants to use some of the useful
types from it. This is obviously backwards and leads to some
awkwardness like the BOLT 11 invoice signing API in the `lightning`
crate taking a `[u5]` rather than a `Bolt11Invoice`.
This is the first step towards fixing that - moving the common
types we need into a new `lightning-types` crate which both can
depend on.
Since we're using a new crate and can't depend on the existing
`lightning` hex utility to implement `Display`, we also take this
opportunity to switch to the new `Display` impl macro in
`hex_conservative`.
This uses the newly introduced conditional configuration checks that are
now configurable withint Cargo (beta).
This allows us to get rid of our custom python script that checks for
expected features and cfgs.
This does introduce a warning regarding the unknown lint in Cargo
versions prior to the current beta, but since these are not rustc errors,
they won't break any builds with the "-D warnings" RUSTFLAG.
Moving to this lint actually exposed the "strict" feature not being
present in the lightning-invoice crate, as our python script didnt
correctly parse the cfg_attr where it appeared.
In the next commit we'll drop the `ahash` dependency in favor of
directly calling `getrandom` to seed our hash tables. However,
we'd like to depend on `getrandom` only on certain platforms *and*
only when certain features (no-std) are set.
This introduces an indirection crate to do so, allowing us to
depend on it only when `no-std` is set but only depending on
`getrandom` on platforms which it supports.
Rather than using the std benchmark framework (which isn't
maintained and is unlikely to get any further maintenance), we swap
for criterion, which at least gets us a variable number of test
runs so our benchmarks don't take forever.
We also fix the RGS benchmark to pass now that the file in use is
stale compared to today's date.
Because `lightning-transaction-sync` does not have an MSRV (and
because its dev-dependencies are huge), we can't build it by
default when devs run `cargo test`, so it is moved out of the
top-level workspace.
For some reason rustc, at some point, decided that our optimization
of dependencies implies we want to also build with LTO. This causes
our test builds to take substantially longer to compile, even with
only a trivial change. By hard-disabling this (even keeping the
optimization of the test and in-tree libraries enabled) the time
required to build with only a trivial change to
`functional_tests.rs` goes from 0m25.635s wall clock/1m14.220s CPU
time to 0m17.841s wall clock/0m17.828s CPU time on my i7-13700K on
rustc 1.63.
The changes in test execution time appear to be within noise.
While we're at it, we also bump dependencies to build with -O2
because their build time is now substantially reduced cost.
BOLT 1 specifies a custom message type range for use with experimental
or application-specific messages. While a `CustomMessageHandler` can be
defined to support more than one message type, defining such a handler
requires a significant amount of boilerplate and can be error prone.
Add a crate exporting a `composite_custom_message_handler` macro for
easily composing pre-defined custom message handlers. The resulting
handler can be further composed with other custom message handlers using
the same macro.
This requires a separate crate since the macro needs to support "or"
patterns in macro_rules, which is only available in edition 2021.
https://doc.rust-lang.org/edition-guide/rust-2021/or-patterns-macro-rules.html
Otherwise, a crate defining a handler for a set of custom messages could
not easily be reused with another custom message handler. Doing so would
require explicitly duplicating the reused handlers type ids, but those
may change when the crate is updated.
This crate provides utilities for syncing LDK via the transaction-based
`Confirm` interface. The initial implementation facilitates
synchronization with an Esplora backend server.
To ensure no-std is honored across dependencies, add a crate depending
on lightning crates supporting no-std. This should ensure any
regressions are caught. Otherwise, cargo doesn't seem to catch some
incompatibilities (e.g., f64::log10 unavailable in core) and seemingly
across other dependencies as describe here:
https://blog.dbrgn.ch/2019/12/24/testing-for-no-std-compatibility/
This makes a small difference for NetworkGraph deserialization
as it enables more inlining across different files, hopefully
better matching user performance as well.
As of this commit, on an Intel 2687W v3, the serialization
benchmarks take:
test routing::network_graph::benches::read_network_graph ... bench: 2,037,875,071 ns/iter (+/- 760,370)
test routing::network_graph::benches::write_network_graph ... bench: 320,561,557 ns/iter (+/- 176,343)
Other includes calling timer_chan_freshness_every_minute() and in the
future, possibly persisting channel graph data.
This struct is suitable for things that need to happen periodically and
can happen in the background.
Defines an interface and related types for fetching block headers and
data from a block source (e.g., Bitcoin Core). Used to keep lightning in
sync with chain activity.
Intended to be a cross-platform implementation of the
channelmonitor::Persist trait.
This adds a new lightning-persister crate, that uses the
newly exposed lightning crate's test utilities.
Notably, this crate is pretty small right now. However, due to
future plans to add more data persistence (e.g. persisting the
ChannelManager, etc) and a desire to avoid pulling in filesystem
usage into the core lightning package, it is best for it to be
separated out.
Note: Windows necessitates the use of OpenOptions with the `write`
permission enabled to `sync_all` on a newly opened channel's
data file.
In 9e03087d6a we started setting
`opt-level` only on profile.test and not profile.dev. When that
commit was authored I tested only that rustc was being called with
opt-level set in its flags, not that the resulted run ran at the
speed I expected. It seems profile.test isn't applied properly to
dependencies or so, resulting in tests running much slower than
they do at profile.dev.opt-level=1.
Until we get the bindings generation process super stable, let the
bindings get stale with respect to the main repo while still letting
`cargo check` pass.
