This commit adds support for pushing funds during the funding process
to the helper method in the integration testing framework.
Additionally, we also modify the simple testBasicChannelFunding test to
also push over an amount in order to test the functionality within the
daemon.
With this commit we have gained a new interaction tests which excursus
all the possible multi-hop error cases aside from:
* sphinx packet corruption
The case can’t be adequately tested with the current integration
testing framework as we can’t arbitrary modify packets en route to
peers within the proto test network. In a future commit, the p2p test
framework whcih has been started by andrew.shvv will be used to ensure
proper handling of this error.
This commit ensures that any extra nodes that were created as part of
the integration tests are shutdown at the end of the test after it
completes successfully. This should speed up the tests as we’ll no
longer have lingering nodes in the background of the test consuming
resources.
This commit adds an additional test case to the `testSingleHopInvoice`
test in order to exercise the proper parsing and dispatching of encoded
payment requests using the zpay32 encoding scheme.
With this test we ensure that the daemon properly encodes payreq’s upon
the creation of invoices, and also that the SendPayment RPC is able to
parse the payment request and properly complete a payment based off of
one.
testMultiHopPayments was failing intermittently due to a lack of
thread-safety in the gRPC stream. This commit takes payment sending out
of goroutines so that they execute serially.
This commit makes a large number of minor changes concerning API usage
within the deamon to match the latest version on the upstream btcsuite
libraries.
The major changes are the switch from wire.ShaHash to chainhash.Hash,
and that wire.NewMsgTx() now takes a paramter indicating the version of
the transaction to be created.
As we’re switching to a more up to date btcd branch that properly
guards the activation of the soft-forks we rely on, we’ll also need to
ensure the two soft-forks have activated.
Moved transaction states from in-memory maps to persistent BoltDB
buckets. This allows channel force closes to operate reliably if the
daemon is shut down and restarted at any point during the forced
channel closure process.
This commit adds a much needed feature to the daemon, namely the
ability to force close a channel while the source daemon doesn’t have
an active connection to the counter party. Previously this wasn’t
possible as ALL channel closures were routed through the htlcSwitch
which is only able to trigger a channel closure if the peer is online.
To remedy this, if the closure type is “force” then, we now handle the
channel closure and related RPC streaming updates from the call handler
site of the RPC itself. As a result, there are now only two htlcSwitch
channel closure types: breach, and regular. The logic that’s now in the
rpcSever should likely be refactored into a distinct sub-system, but
getting the initial functionality in is important.
Finally, the channel breach integration test has been modified to skip
connection the peers before attempting the forceful channel closure of
a revoked state as the remote peer no longer needs to be online.
This commit adds a short sleep before a channel assertion in the
`testMaxPendingChannels` test. This sleep serves to give the nodes
enough time to propagate the new channel announcement over the
authenticated gossip system. Without this sleep, the call may be issued
in a state wherein only half of the channel announcement has fully
propagated.
This commit slightly refactors the logic for the new outgoing payment
related RPC’s to more closely match the style of the rest of the
codebase. Additionally the tests have been updated to reflect the
changes to the protos of the new RPC’s.
Go-fmt files. Refactored code according to the guidelines.
Enhanced payment test: add error checking
and individual context for each API call.
Add Timestamp field to payment struct.
This commit modifies the channel closing logic to remove the hard coded
bools indicating which side is attempting the closure. With the recent
changes, the initiator must always pay the channel closure fees.
This information is recently stored on disk, therefore we can use the
boolean to ensure that the closure transaction is created properly no
matter who initiates the close.
This fixes a bug.
This commit introduces a new sub-system into the daemon whose job it is
to vigilantly watch for any potential channel breaches throughout the
up-time of the daemon. The logic which was moved from the utxoNursery
in a prior commit now resides within the breachArbiter.
Upon start-up the breachArbiter will query the database for all active
channels, launching a goroutine for each channel in order to be able to
take action if a channel breach is detected. The breachArbiter is also
responsible for notifying the htlcSwitch about channel breaches in
order to black-list the breached linked during any multi-hop forwarding
decisions.
This commit modifies the invoices generated during the
testRevokedCloseRetribution integration test to ensure that the
invoices are globally unique within the context of the integration
tests.
This commit adds a new rather extensive integration tests to excerise
uncooperative channel breaches triggered by a counter-party
broadcasting a previously revoked commitment state.
In order to programmatically script such logic using the integration
testing framework, the test manually manipulates the database files of
one of the nodes within the test network in order to force Bob to
travel back in time to a revoked commitment state. With this
manipulation, we then force Bob to broadcast the revoked state,
triggering Alice’s retribution logic which sweeps ALL the funds within
the channel.
This commit slightly modifies the existing CT struct in order to
maintain consistency with code-style. As a result of the name change,
all references have also been renamed from `ct` to `t`.
The Error and Errorf methods have been removed in favor of forcing
everything to be reported via `Fatalf`. Additionally a new method
(ProcessErrors) has been introduced to the networkHarness class in
order to encapsulate the underlying channel.
This commit uses the context package’s WithTimeout to ensure tests
which rely on asynchrony behaviors cannot block the execution of the
integration tests for ever. All tests which rely on async gRPC
notifications now perform a 3 way select: on the timeout channel
closure, an error, and the response itself.
Additionally some slight refactoring has taken place within the current
set of integration tests, eliminating some unneeded factory functions.
This commit adds a new RPC command: `channelbalance` which returns the
sum of all available channel capacity across all open channels. The
total balance is currently returned in units of `satoshis`. Additionally
the `networkHarness` has been modified slightly to allow specifying the
additional "extra" command line parameters when creating the initial
seed nodes. Minor refactoring within the integration tests has been
undertaken in order to increase code re-use across tests.
Closes#29.
This commit adds a basic test to exercise the scenario of forced
channel closure between to nodes with an existing channel open. The
test ensures that the latest commitment transaction it broadcast to the
chain and additionally that all time-locked outputs are sweeped with a
single transaction as soon as the inputs are mature enough.
At times when testing one requires access to the logs of a particular
node in order to aide with debugging. Before this commit, one needed to
manually modify the networkHarness code in order to print either the
location of the logs or the logs themselves. With this commit, tests
can now programmatically examine the logs of any node created within
the networkHarness.
It’s worth noting that at times the logs dumped may not be the most up
to date version of the logs files as the logging library employs
intermediate buffering.
This commit fixes some flakiness exhibited in the current basic funding
workflow tests. This test can fail occasionally in resource constrained
environment due to a race condition which arises after Alice learns of
the channel, but Bob is still waiting for Alice’s notification. As a
temporary fix, we now only check Alice’s state for the existence of the
channel.
This commit adds some new networkHarness helper methods which are
mean’t to reduce the verbosity of the previous basic tests, and also to
enable developers to right tests mote easily five a higher level
interface.
This commit increases the robustness of the current test and also
reduces it’s running time considerably as all “time.Sleep”s have now
been removed.
Rather than sleeping some random amount of time, the test now waits for
a particular async notification to be dispatched before proceeding.
This tightens up the execution of the tests quite a bit.
This commit adds a new feature to the network harness enabling callers
to receive async notifications once a particular transaction is seen on
the network. Such a feature is useful when due to the asynchronous
behavior of node communications.
With this new feature, tests can now wait for a particular transaction
to be seen within the network before proceeding.
This commit fixes the build for version 1.6.3 of golang. In go 1.7, the
“context” package was moved into the standard library, however go 1.6.3
doesn’t have that change, so we must refer to the prior WIP package
until a new version of Go is released.
