In this commit BOLT№2 retranmission logic for the channel link have
been added. Now if channel link have been initialised with the
'SyncState' field than it will send the lnwire.ChannelReestablish
message and will be waiting for receiving the same message from remote
side. Exchange of this message allow both sides understand which
updates they should exchange with each other in order sync their
states.
This commit adds a test for an lnd instance experiecing a reorg,
making sure a channel that is in the channel graph (using the
describegraph rpc call) will no longer be after the funding tx
gets reorged out.
In this commit, we modify the assertNumOpenChannelsPending to poll
every 200ms rather than just a single attempt. The goal of this commit
is to reduce the number of flakes on travis caused by slow instances.
In this commit, we extend the testMultiHopPayments test case to add an
additional node to the multi-hop payment route: Dave.
Related to #391 as it uses the provided code fragment to reproduce the
bug. With this test in place, we’ll now be able to notice any
regressions in this area.
In this commit we modify all the test that involve sending payments to
use the payreq returned rather than manually populating the
payhash+dest fields in the SendRequest proto argument to SendPayment.
This is required as if we don’t use the payreq returned, then the
receiving node will reject the payment as it’ll use the global final
CLTV delta value, rather than the value (within the pay req) that the
receiver is expecting.
In order to maintain the original essence of the test, we need to clear
the state of missionControl with each attempt, essentially advancing
time between each payment attempt.
This commit fixes a bug related to swallowing an error that should go
to the switch in the case of an insufficient balance error when
attempting to add a new HTLC to the channel state machine. In this
case, an error would never be returned back to the client/switch, and
the internal processing within the channelLink would loop forever,
attempting to add an HTLC that can’t be added due to insufficient
balance to state machine itself.
We fix this issue by only treating the lnwallet.ErrMaxHTLCNumber as the
only error that prompts adding an HTLC to the overflow queue rather
than sending the error directly back to the switch.
This commit alters the existing retribution
post breach conf test case with the intention
of testing the correct response in event that
the remote party broadcasts a prior state
while HTLCs have been extended. This serves
as a preliminary integration for an expansion
of the breach arbiter integration tests.
The primary change involves using the new
htlchodl mode for debugging, which causes the
remote peer to ignore any intent to settle
incoming HTLCs. The result is that any
payments sent to the remote party are held in
limbo, allowing us to test for these
conditions more accurately.
Currently the test case only tests that the
justice transaction is mined. After we have
fully integrated the breach arbiter to sweep
2nd layer HTLCs, this test will be altered
to check for spends from the appropriate
inputs.
This commit adds a breached contract retribution storage layer using
boltdb to the breach arbiter. The breach arbiter now stores retribution
state on disk between detecting a contract breach, broadcasting a
justice transaction that sweeps the channel, and finally witnessing the
justice transaction confirm on the blockchain. It is critical that such
state is persisted on disk, so that if our node restarts at any point
during the retribution procedure, we can recover and continue from the
persisted state.
This commit modifies the HTLC integration tests to be mindful of the
max payment size. Rather than sending the payment in one large batch,
we instead now send it in chunks of the max payment size.
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.
In the "multiple channel creation" test, in some cases the
responder (Bob) was not yet considering the first channel
to be opened (activeReservation still not deleted in
fundingManager) when Alice tried to open the second channel.
This would cause the test to fail. This commit adds a small
sleep before the creation of the second channel, to give
Bob some time to finish the opening process.
This commit updates the integration tests to reflect the reality after
removing code that would always attempt to increment the current update
timestamp by one for each channel announcement. Without connecting
directly to carol, it isn’t guaranteed that Alice will receive that
announcement as Bob would have already processed one for Carol when
their channel was created.
Make the fundingmanager send an updated node announcement
each time it opens a new channel. This is to make sure
our node announcement is propagated in the network, since
peers will ignore our node announcements if we haven't
opened any channels yet.
Within the network, it's important that when an HTLC forwarding failure
occurs, the recipient is notified in a timely manner in order to ensure
that errors are graceful and not unknown. For that reason with
accordance to BOLT №4 onion failure obfuscation have been added.
This commit fixes a minor bug in the goroutine that’s launched to check
the sync status of a particular node. Previously, the goroutine could
end up infinitely stuck on a send as once the chain has been detected
as synced, it didn't exit.
We fix this now by ensure that the goroutine always terminates after
the initial notification to the caller. Additionally, we not ensure
that both the internal and exterior goroutine are both reading off of
the peer’s quit channel.
This commit modifies the travis build script, and our local test script
to ensure that the race condition builds are conducted in a parallel
build. After this commit two travis builds will be kicked off for each
push/commit: one that runs the race condition tests in isolation, and
another that runs the integration tests then the coverage tests.
In order to do the above cleanly, the integration tests are now guarded
behind a build flag. In order to run the integration tests, one now
needs to specify the `-tags rpctest` flag when running the `go test`
command.
In this commit additional test have been added which tests the ability
of Alice and Bob asynchroniously exchange the payment between each
other. This scenario will be higly frequent in the payment between
payment providers.
In order to not close the payment stream on payment error the additional
field have been added in payment response. Now error from stream Recv()
function means that something has happend inside the client and we unable
to process any payment farther, and error inside the payment response
means, that something wrong has happend with payment itself.
This commit replaces the hard-coded 5000 satoshi fees with calls to the
FeeEstimator interface. This should provide a way to cleanly plug in
additional fee calculation algorithms in the future. This change
affected quite a few tests. When possible, the tests were changed to
assert amounts sent rather than balances so that fees wouldn't need to
be taken into account. There were several tests for which this wasn't
possible, so calls to the static fee calculator were made.
This commit changes the SingleHop and MultiHop integration tests to
assert amounts sent rather than balances. Because fees can be odd
amounts, this change makes it such that fee amounts don't need to be
explicitly taken into account in the tests.
This commit changes t.Fatal to t.Fatalf in TestCheckDustLimit so as to
provide more information. This commit also makes some column width
adjustments and minor spelling/formatting changes.
