Adjusted tx occurs when a previous aggregated claim tx has
seen one of its outpoint being partially claimed by a remote tx.
To pursue claiming of the remaining outpoint a adjusted claim tx
is generated with leftover of claimable outpoints.
Previously, in case of block-rescan where a partial claim occurs,
we would generate duplicated adjusted tx, wrongly inflating feerate
for next bumps. At rescan, if input has already been dropped from
outpoints map from a claiming request, don't regenerate again
a adjuste tx.
3d640da5c3 changed the indexes for
some enums in ChannelMonitor deserialization but not serialization.
Thus, the chanmon_deser_target fuzz target failed on travis on at
least one PR.
Enforce a minimum htlc_minimum_msat of 1.
Instead of computing dynamically htlc_minimum_msat based on feerate,
relies on user-provided configuration value. This let user compute
an economical-driven channel parameter according to network dynamics.
If rust-lightning tells us to disconnect a socket after we read
some bytes from the socket, but before we actually give those bytes
to rust-lightning, we may end up calling rust-lightning with a
Descriptor that isn't registered anymore.
Sadly, there really isn't a good way to solve this, and it should
be a pretty quick event, so we just busy-wait.
Failing this requirement at sending means a strict receiver would
fail our channel while processing a HTLC routed from a third-party.
Fix by enforcing check on both sender and receiver side.
This was the way DataLossProtect was originally written, however it
didn't match other implementations at the time during testing. It
turns out, other implementations didn't agree with each other
anyway (depending on the exact timeline), so the spec was clarified
somewhat in https://github.com/lightningnetwork/lightning-rfc/pull/550
. This updates us to be in line with the new guidance and appears
to solve out-of-sync issues in testing.
Fixes issue #493 and should resolve some issues where other nodes
(incorrectly) reject channel_update/node_announcement messages
which have a serial number that is not a relatively recent
timestamp.
This is a somewhat-obvious oversight in the capabilities of
rust-lightning, though not a particularly interesting one until we
start relying on node_features (eg for variable-length-onions and
Base AMP).
Sadly its not fully automated as we don't really want to store the
list of available addresses from the user. However, with a simple
call to ChannelManager::broadcast_node_announcement and a sensible
peer_handler, the announcement is made.
This reintroduces a check_spends!() removed in 3d640da5c3
due to check_spends not being able to check a transaction which
spends multiple other transactions.
It also simplifies a few calls in claim_htlc_outputs_single_tx by
using check_spends!().
The API to rust-bitcoin to check a transaction correctly spends
another changed some time ago, but we still have a lot of needless
.clone()s in our tests.
Instead of passing a Vec of Vecs drop them into one as we go in
ChannelMonitor, hopefully avoiding a bit of memory fragmentation
and improving readability.
Encapsulates tracking and bumping of in-flight transactions in
its own component. This component may be latter abstracted
to reuse tracking and RBF for new features (e.g dual-funding,
splicing)
Build all transactions generation in one place. Also as fees
and signatures are closely tied, what keys do you have determine
what bumping mode you can use.
This tests Router serialization round-trip at the end of each
functional test in the same way we do ChannelMonitors and
ChannelManagers to catch any cases where we were able to get into
a state which would have prevented reading a Router back off disk.
We further walk all of the announcements which both the original
and deserialized Routers would send to peers requesting initial
sync to ensure they match.
This is a cheap way to fix an error in Router serialization
roundtrip due to us calling read_to_end during the read of
channel/node announcement/updates. During normal message reading,
we only have limited bytes to read (specifically the message buffer)
so this is fine, however when we read them inside Router, we have
more data from other fields of the Router available as well. Thus,
we end up reading the entire rest of the Router into one message
field, and failing to deserialize.
Because such fields are always stored in Option<>s, we can simply
use a LengthLimitingStream in the Option<> serialization format and
make only the correct number of bytes available.
By using a variable-length integer for the new field, we avoid
wasting space compared to the existing serialization format.
This makes Readable symmetric with Writeable and makes sense -
something which is Readable should be Readable for any stream which
implements std::io::Read, not only for a stream type it decides on.
This solves some lifetime-compatibility issues in trying to read()
from a LengthLimitingReader in arbitrary Readable impls.
This provides a simple wrapper for deserializing right into an
Arc<ChannelManager>, which improves UX a tiny bit when working with
SimpleArcChannelManager types.
This disables building the lightning-net-tokio crate on 1.34.2 on
Travis in anticiption of relying on async/await for
lightning-net-tokio, with the nice side-effect of reducing the
amount of work done on our slowest Travis job.
This also adds 1.39.0 to Travis as that is the new MSRV for
lightning-net-tokio and uses that for codecov generation.
This also moves fuzzing to Rust stable, as honggfuzz broke its MSRV
and it seems likely it will again in the future.
