This commits slightly rewrites the newly introduced
logic for private channels. Instead of keeping the
channel announce preference in a database within
fundingManager, it is stored as part of the
OpenChannel struct.
In addition, the ChanOpenStatus_Open update is now
sent after the channel is added to the router, instead
of waiting until the 6 blocks confirmation has passed.
This commit adds some comments and does some cleanup
of the logic that makes sure non-public channels
(channels with no AuthProof) are not broadcasted
to the network.
This commit adds the ChannelFlags field, of type
lnwire.FundingFlags, to the OpenChannel struct,
including serialization for database storage.
This is done to preserve the flags that were
sent during channel opening, currently used
to determine whether a channel should be made
public or not after opening.
This commit introduces some new interdependent functionality. As
soon as the fundingLocked message is sent, the channel is
immediately added to the ChannelRouter's internal topology.
Finally, channels are now only broadcasted to the greater
network after six confirmations on the funding transaction
has been reached.
On testate as times the fee estimation can swing widely. As we
currently don’t yet use vsize everywhere internally, we’re forced to
manually scale to weight for the moment. If the returned fee rate is
too low, then it can cause our estimate to go to zero. This also has
the effect of meaning that the chanCloser doesn’t currently advance if
the initial starting fee is zero.
All implementations of the ChainNotifier interface support registering
notifications on transaction confirmations. This struct is intended to
be used internally by ChainNotifier implementations to handle much of
this logic.
This simplifies the pending payment handling code because it allows it
be handled in nearly the same way as forwarded HTLCs by treating an
empty channel ID as local dispatch.
The src/dest terminology for routing packets is kind of confusing
because the source HTLC may not be the source of the packet for
settles/fails traversing the circuit in the opposite direction. This
changes the nomenclature to incoming/outgoing and always references
the HTLCs themselves.
Previously, some methods on a LightningChannel like SettleHTLC and
FailHTLC would identify HTLCs by payment hash. This would not always
work correctly if there are multiple HTLCs with the same payment hash,
so instead we change these methods to identify HTLCs by their unique
identifiers instead.
This changes the circuit map internals and API to reference circuits
by a primary key of (channel ID, HTLC ID) instead of paymnet
hash. This is because each circuit has a unique offered HTLC, but
there may be multiple circuits for a payment hash with different
source or destination channels.
The constructor functions have no additional logic other than passing
function parameters into struct fields. Given the large function
signatures, it is more clear to directly construct the htlcPacket in
client code than call a function with lots of positional arguments.
In this commit, we ensure that we actually advertise our desired value
for the smallest HTLC we’ll accept as incoming. Before this commit, the
value advertised was always zero.
Before this commit, during a reservation, we wouldn’t ever specify our
minHTL value. We don’t yet fully validate all channel constrains, but
doing this now serves to ensure that once those features are merged,
we’ll actually be setting a valid value for minHTLC.
