rust-lightning

Rustfmt touched methods

Add docs to `commitment_signed_dance_return_raa`

Make `AttributionData` actually pub since its used in the public API

`AttributionData` is a part of the public `UpdateFulfillHTLC` and
`UpdateFailHTLC` messages, but its not actually `pub`. Yet again
re-exports bite us and leave us with a broken public API - we
ended up accidentally sealing `AttributionData`.

Instead, here, we just make `onion_utils` `pub` so that we avoid
making the same mistake in the future.

Note that this still leaves us with arather useless public
`AttributionData` API - it can't be created, updated, or decoded,
it can only be serialized and deserialized, but at least it exists.

Update crate version numbers post v0.2 release

We bump the `+git` version numbers, fixing the SemVer checks.

Rustfmt handle_monitor_update_completion_actions

Rustfmt channel methods

Clean up changes in previous commits.

Support async fetching of commitment point during channel reestablish

`HolderCommitmentPoint` currently tracks the current and next point used
on counterparty commitments, which are unrevoked. When we reestablish a
channel, the counterparty sends us the commitment height, along with the
corresponding secret, for the state they believe to be the latest. We
compare said secret to the derived point we fetch from the signer to
know if the peer is being honest.

Since the protocol does not allow peers (assuming no data loss) to be
behind the current state by more than one update, we can cache the two
latest revoked commitment points alongside `HolderCommitmentPoint`, such
that we no longer need to reach the signer asynchronously when handling
`channel_reestablish` messages throughout the happy path. By doing so,
we avoid complexity in needing to pause the state machine (which may
also result in needing to stash any update messages from the
counterparty) while the signer response is pending.

The only remaining case left to handle is when the counterparty presents
a `channel_reestablish` with a state later than what we know. This can
only result in two terminal cases: either they provided a valid
commitment secret proving we are behind and we need to panic, or they
lied and we force close the channel. This is the only case we choose to
handle asynchronously as it's relatively trivial to handle.

Rustfmt modified fns

Inline error variable

Drop required `Box`ing of `lightning` trait `Future`s

Now that our MSRV is 1.75, we can return `impl Trait` from trait
methods. Here we use this to clean up `lightning` crate trait
methods, dropping the `Pin<Box<dyn ...>>`/`AsyncResult` we had to
use to have trait methods return a concrete type.

Trivially replace `Box::pin` with `pin!` in a few places

Now that our MSRV is above 1.68 we can use the `pin!` macro to
avoid having to `Box` various futures, avoiding some allocations,
especially in `lightning-net-tokio`, which happens in a tight loop.

Fix compiler warning

Support capturing `tx_abort` send within channel reestablish tests

Provide the same docs in `ChangeDestinationSource` as the sync one

Copy async docs from async bump transaction objects to sync ones

When we added the async traits and wrapper structs for the
transaction-bumping logic, we didn't bother copying the
documentation to the sync wrappers as we figured the links
sufficed. Sadly, however, this means that our bindings logic will
have no docs but a broken link to an async object that doesn't
exist.

Instead, here, we copy the docs from the async objects to the sync
ones, at least leaving behind a comment noting that both need
updating whenever one gets updated.

We also fix one bogus link in `Wallet`'s docs.

Mark async traits and structs no-export

We do not currently support async traits or methods in our
home-grown bindings logic, so here mark them no-export.

Add `readme` fields to most crates' `Cargo.toml`s

`crates.io` will show any README/README.md which apears in the
crate which is uploaded, but it doesn't consider the README from
the workspace, only if its in the crate itself.

Instead, add the `readme` field so that the workspace README also
gets uploaded.

Remove `Send + Sync` bounds when `no-std`

Add fmt::Debug implementation for FundedChannel

To aid with debugging in tests.

Don't broadcast manual-funded chan closing txn on HTLC timeouts

In 6c5ef049b8d0ec174d7368d48b7b429efffb4a61 we prevented broadcast
of the commitment transactions if the funding transaction has not
yet appeared on-chain for manual-broadcast channels to avoid
spurious bumps or unbroadcastable transactions. However, we missed
the case where a channel is closed due to HTLCs timing out.

Here we fix that by doing the same broadcast-gating when
automatically force-closing a channel due to HTLC timeouts.

Implement Holder HTLC claim chunking for 0FC channels

Otherwise, we could hit the max 10_000vB size limit on V3 transactions
(BIP 431 rule 4).

Also introduce a `max_tx_weight` parameter to `select_confirmed_utxos`.
This constraint makes sure anchor and HTLC transactions in 0FC channels
satisfy the `TRUC_MAX_WEIGHT` and the `TRUC_CHILD_MAX_WEIGHT`
maximums.

Expand the coin-selection algorithm provided for any `T: WalletSource`
to satisfy this new constraint.

Bump `electrsd` to 0.36.1

We bump our `electrsd` dependency to the latest version, allowing us to
remove the `home` pin.

Doc and comment fixes from #4167

This fixes incorrect docs and comments introduced by
e95ebf8b9a3d43108176e21c8b4c6bd82f3aaabf and
491b6949fec743e34c74c3a472cf0a2cb83d7ab3

Only pause read in `PeerManager` `send_data` not `read_event`

We recently ran into a race condition on macOS where `read_event`
would return `Ok(true)` (implying reads should be paused) due to
many queued outbound messages but before the caller was able to
set the read-pause flag, the `send_data` calls to flush the
buffered messages completed. Thus, when the `read_event` caller got
scheduled again, the buffer was empty and we should be reading, but
it is finally processing the read-pause flag and we end up hanging,
unwilling to read messages and unable to learn that we should start
reading again as there are no messages to `send_data` for.

This should be fairly rare, but not unheard of - the `pause_read`
flag in `read_event` is calculated before handling the last
message, so there's some time between when its calculated and when
its returned. However, that has to race with multiple calls to
`send_data` to send all the pending messages, which all have to
complete before the `read_event` return happens. We've (as far as I
recall) never hit this in prod, but a benchmark HTLC-flood test
managed to hit it somewhat reliably within a few minutes on macOS
and when a synthetic few-ms sleep was added to each message
handling call.

Ultimately this is an issue with the API - we pause reads via a
returned flag but unpause them via a called method, creating two
independent "stream"s of pause/unpauses which can get out of sync.
Thus, here, we stick to a single "stream" of pause-read events from
`PeerManager` to user code via `send_data` calls, dropping the
read-pause flag return from `read_event` entirely.

Technically this adds risk that someone can flood us with enough
messages fast enough to bloat our outbound buffer for a peer before
`PeerManager::process_events` gets called and can flush the pause
flag via `read_event` calls to all descriptors. This isn't ideal
but it should still be relatively hard to do as `process_events`
calls are pretty quick and should be triggered immediately after
each `read_event` call completes.

Assure BroadcasterInterface packages of len > 1 are child-with-parents

Implementations MUST NOT assume any topological order on the
transactions.

While Bitcoin Core v29+ `submitpackage` RPC allows packages of length 1
to be submitted via `submitpackage`, it still requires any package
submitted there to be a `child-with-parents` package.

So we remove the possibility that a batch of transactions passed to
a `BroadcasterInterface` implementation contains unrelated transactions,
or multiple children.