This commit fixes a lingering bug within the logic for the
peer/htlcswitch/channellink. When the link needs to fetch the latest
update to send to a sending party due to a violation of the set routing
policy, previously it would modify the timestamp on the message read
from disk. This was incorrect as it would invalidate the signature
within the message itself. We fix this by instead
This commit adds another conditional send select statement to ensure
that when sending the finalized contract to the breach arbiter, the
peer doesn’t possible cause the daemon to hang on shutdown.
This commit modifies the logic when we are loading alll the channels
that we have with a particular peer to grab the current committed
forwarding policy from disk rather then using the default forwarding
policy. We do this as it’s now possible for active channels to have
distinct forwarding policies.
This commit adds a new method to the HtlcSwitch:
UpdateForwardingPolicies. With this method callers are now able to
modify the forwarding policies of all, or some currently active links.
We also make a slight modification to the way that forwarding policy
updates are handled within the links themselves to ensure that we don’t
override with a zero value for any of the fields.
This commit fixes an lingering bug within the path finding logic of the
router. Previously we used the edge policy directly attached to the
outgoing channel of the node we were traversing to calculate the fees
and time lock information. This is incorrect, as we instead should be
using the policy of the *connecting* node as we’ll need to pay for
transit as they dictate.
To remedy this, we now grab the incoming+outgoing edges and use those
accordingly when building the initial path.
This commit adds a new method to the AuthenticatedGossiper:
PropagateFeeUpdate. This new method will allow callers to update the
fee schedule advertised for a particular channel, or all currently
active channels. With this method exposed, the AuthenticatedGossiper
will now craft the new channel update messages, sign the new state,
commit the new policy to the underlying graph, and finally add the
message to the next announcement epoch batch.
This commit updates the tail end of the funding workflow to properly
include the ChainHash field when crafting ChannelAnnouncements and the
initial ChannelUpdate messages. Additionally, we now properly generate
the proper signatures to match the changes to BOLT0007.
This commit modifies the generation and parsing of errors to abandon
usage of the Code field, and instead use the first byte of the Data
field to store the error codes that we currently use. With this change,
we ensure that our error messages properly match BOLT-0002.
This commit implements the simplification within the latest version of
BOLT-0007. With this change, we simply sign the message hash directly
with the bitcoin keys, rather than signing the node keys themselves.
This commit modifies the node.ForEachChannel to *also* return the
incoming edge as well as the outgoing edge. We make this modification
as when we’re doing path finding, we need to return the incoming edge
as well, since we need to use the to properly compute the time lock and
fees for transit on that edge.
This commit updates the script we use to match the current
specification. The change is minor: we can say an extra byte by moving
the OP_CHECKSIG to the end of the script, and swapping the checks and
seqverify operations in the second clause. However, the witness remains
the same!
This commit does away with the ErrorCode field in order to ensure that
we’re properly compatible with BOLT-0002. In the future the error code
field may be re-introduced as it’s much easier to check against an
internet error rather than interpret a byte slice describing the error.
This commit modifies the NodeAnnouncement message to ensure that it
matches the current spec ordering. The spec was recently modified to
place the feature vector first to allow for future changes to the
fields to be forwards compatible.
This commit updates the encoding/decoding for the onion errors to
properly match BOLT-0004. This commit does to major things: we increase
the max message size to 256 bytes to account for recent modifications
to the ChannelUpdate message, and also fold in the error code into the
failure message encapsulation itself.
This commit adds a new type to the lnwire package: MilliSatoshi. A
milli-satoshi is simply 1/1000th of a satoshi, and will be used for all
internal accounting when sending payments, calculating fees, updating
commitment state, etc. Two helper methods are added: ToBTC(), and
ToSatoshis() to make manipulation of the values easy.
This commit modifies the Select method for the
ConstrainedPrefAttachment attachment heuristic slightly. Previously, it
was possible for an autopilot.Agent to go over the allotted number of
channels as it would unconditionally attempt to establish channel with
all returned Attachment Directives. To remedy this, we now assume that
we already have active, or pending channels to each of the nodes in the
set of skipNodes. Therefore, we now use the size of the skipNodes map
as an upper limit within the primary selection loop.
In this commit, we ensure that we grab the mutex for the pending open
channel state when we attempt to merge the pending state with the
committed state.
This commit prevents the case where btcd stops before lnd is fully
started, thus making lnd_test hang on trying to stop lnd using
`StopDaemon`. The underlying issue is that while lnd is trying to
start the server and subscribe to block notifications from btcd,
btcd stops, and lnd continues to attempt to reconnect before it
ever starts the interrupt handler. This reversal avoids that issue
by making sure lnd is stopped before btcd.
This commit fixes a possible deadlock bug that may arise during
shutdown due to an unconditional send on a channel to the breach
arbiter. We do this on two occasions within the peer: when loading a
new contract to give it the live version, and also when closing a
channel to ensure that it no longer watches over it.
Previously it was possible for these sends to block indefinitely in the
scenario that the server was shutting down (which means the breach
arbiter) is. As a result, the channel would never be drained, meaning
the server couldn’t complete shutdown as the peer hadn’t exited yet.
