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.
There is a sleep after channels are opened to ensure the channel is
removed from the set of pending reservations. We can avoid this sleep
and get better guarantees of the channel being opened by deleting the
reservation just before updating channel state to active instead of
after.
This helps catch issues in the RPC tests faster by putting a timeout
on all SendPayment requests. Otherwise, if a payment stalled, the test
would run until the test suite timeout, 10 minutes. Also simplifies
some code with a helper function and using SendPaymentSync where
possible.
There is an issue currently where if an error occurs in Start() before
the LightningClient is initialized, the process won't be killed and
the program will segfault (because Stop() tries to call a method on
the nil LightningClient). This handles some of those edge cases.
If an lnd node encounters a fatal process errors, we now log the error
asynchronously, instead of calling Fatalf on the test instance. This
is because calling Fatalf in a separate goroutine does not actually
end the test immediately as expected, but rather just kills the
goroutine. This ensures that we see server errors on all nodes before
the test process exits.
This moves the commitment transaction generation code out of
fetchCommitmentView into createCommitmentTx. Aside from being a pretty
clean logical split, this allows the transaction generation code to be
unit tested more effectively.
The fee estimation for funding transactions now properly accounts for
different types of UTXOs spent, whereas previously it assumed all
inputs were spending native P2WKH outputs.
This is a rewrite of feature vectors in lnwire. This has a few
benefits:
1) a simpler interface
2) separate structs for a plain set of feature bits and a feature
vector with associated feature names
their respective feature sets
3) loosened requirements that bits MUST be assigned in pairs
4) fix endianness of encoding/decoding
Jim Posen