This makes it more practical for users to track channels prior to
funding, especially if the channel fails because the peer rejects
it for a parameter mismatch.
We cannot expose ReadOnlyNetworkGraph::get_addresses as is in C as
it returns a list of references to an enum, which the bindings
dont support. Instead, we simply clone the result so that it
doesn't contain references.
During the event of a channel close, if the funding transaction
is yet to be broadcasted then a DiscardFunding event is issued
along with the ChannelClose event.
If we attempt to send a payment, but the HTLC cannot be send due to
local channel limits, we'll provide the user an error but end up
with an entry in our pending payment map. This will result in a
memory leak as we'll never reclaim the pending payment map entry.
Users no longer need to verify the amounts of received payments as
the payment secret will protect us against the probing attacks such
verification was intended to fix.
This is because we want the ability to retry completely failed
payments.
Upcoming commits will remove these payments on timeout to prevent
DoS issues
Also test that this removal allows retrying single-path payments
When we are prepared to forward HTLCs, we generate a
PendingHTLCsForwardable event with a time in the future when the
user should tell us to forward. This provides some basic batching
of forward events, improving privacy slightly.
After we generate the event, we expect users to spawn a timer in
the background and let us know when it finishes. However, if the
user shuts down before the timer fires, the user will restart and
have no idea that HTLCs are waiting to be forwarded/received.
To fix this, instead of serializing PendingHTLCsForwardable events
to disk while they're pending (before the user starts the timer),
we simply regenerate them when a ChannelManager is deserialized
with HTLCs pending.
Fixes#1042
Previously we'd simply overwritten "the" first hop path to each
counterparty when routing, however this results in us ignoring all
channels except the last one in the `ChannelDetails` list per
counterparty.
We want to reuse send_payment internal functions for retries,
so some need to now be parameterized by PaymentId to avoid
generating a new PaymentId on retry
If a counterparty (or an old channel of ours) uses a non-segwit
script for their cooperative close payout, they may include an
output which is unbroadcastable due to not meeting the network dust
limit.
Here we check for this condition, force-closing the channel instead
if we find an output in the closing transaction which does not meet
the limit.
There is little reason for users to be paying out to non-Segwit
scripts when closing channels at this point. Given we will soon, in
rare cases, force-close during shutdown when a counterparty closes
to a non-Segwit script, we should also require it of our own users.
546 sat/vbyte is the current default dust limit on most
implementations, matching the network dust limit for P2SH outputs.
Implementations don't currently appear to send any larger dust
limits, and allowing a larger dust limit implies higher payment
failure risk, so we'd like to be as tight as we can here.
There isn't a lot of user-utility for cloning `NetworkGraph`
directly (its a rather large struct, and there probably isn't a lot
of reason to have *multiple* `NetworkGraph`s). Thus, when locks
were pushed down into it, the `Clone`-ability of it was dropped as
well.
Sadly, mapping the Java memory model onto:
* `Read`-ing a `NetworkGraph`, creating a Java-owned
`NetworkGraph` object that the JVM will destruct for us,
* Passing it to a `NetGraphMsgHandler`, which now expects to own
the `NetworkGraph`, including destructing it,
isn't really practical without adding a clone in between.
Given this, and the fact that there's nothing inherently wrong with
clone-ing a `NetworkGraph`, we simply re-add `Clone` here.
Associated types in C bindings is somewhat of a misnomer - we
concretize each trait to a single struct. Thus, different trait
implementations must still have the same type, which defeats the
point of associated types.
In this particular case, however, we can reasonably special-case
the `Infallible` type, as an instance of it existing implies
something has gone horribly wrong.
In order to help our bindings code figure out how to do so when
referencing a parent trait's associated type, we specify the
explicit type in the implementation method signature.
When we landed custom messages, we used the empty tuple for the
custom message type for `IgnoringMessageHandler`. This was fine,
except that we also implemented `Writeable` to panic when writing
a `()`. Later, we added support for anchor output construction in
CommitmentTransaction, signified by setting a field to `Some(())`,
which is serialized as-is.
This causes us to panic when writing a `CommitmentTransaction`
with `opt_anchors` set. Note that we never set it inside of LDK,
but downstream users may.
Instead, we implement `Writeable` to write nothing for `()` and use
`core::convert::Infallible` for the default custom message type as
it is, appropriately, unconstructable.
This also makes it easier to implement various things in bindings,
as we can always assume `Infallible`-conversion logic is
unreachable.
For the same reason as `get_route`, a slice of objects isn't
practical to map to bindings - the objects in the bindings space
are structs with a pointer and some additional metadata. Thus, to
create a slice of them, we'd need to take ownership of the objects
behind the pointer, place them into a slace, and then restore them
to the pointer.
This would be a lot of memory copying and marshalling, not to
mention wouldn't be thread-safe, which the same function otherwise
would be if we used a slice of references instead of a slice of
objects.
