This commit adds additional test cases to test both cases (initiator vs
responder) for a single funder channel workflow. Additionally, the
previous dual funder tests have been extended in order to detect proper
funding channel broadcast, and the ChainNotifier’s role in notifying
upstream callers that a funding transaction has been embedded in the
chain at a sufficient depth.
At this point the tests certainly need to be cleaned up. bobNode should
be replaced with a second instance of the wallet modeling a remote
peer.
This commit modifies the existing workflow to add additional paths to
be used when on the responding side of a single funder workflow.
Additionally, several bugs encountered within the existing dual funder
workflow logic have been fixed, and modified to account for the wallet
being on the igniting side of a single funder workflow.
The previous logic incorrectly assumed the returned address was already
a p2wkh address. Instead, a p2sh address was returned. So we now
correctly craft both the sigScript and witness stack for a nested p2sh
spend.
This is required since for single funder channels, we don’t contribute
any funds so we don’t need to select any change or coins for input into
the funding transaction.
This commit adds 3 methods to lnwallet.ChannelReservation intended to
facilitating a single funder channel workflow between two nodes. A
single funder workflow is characterized as the initiator committing all
the funds to a channel, with the responder only providing public keys,
and a revocation hash.
The workflow remains the same for the initiator of the funding
transaction, however for the responder, the following methods are
instead called in order:
* .ProcessSingleConribution()
* .CompleteSingleContribution()
* .FinalizeReservation()
These methods are required for the responder as they are never able to
construct the full funding transaction, and only receive the out point
of the funding transaction once available.
A cooperative closure of a LightningChannel proceeds in two steps.
First, the party who wishes to close the channel sends a signature for
the closing transaction. Next, the responder reconstructs the closing
transaction identically as the initiator did using a canonical
input/output ordering, and the currently settled balance within the
channel. At this point, the responder then broadcasts the closure
transaction. It is the responsibility of the initiator to watch for
this transaction broadcast within the network to clean up any resources
they committed to the active channel.
Only nested p2sh or pure witness outputs are used when selecting coins
for inputs to a funding transaction.
The funding transaction output now uses p2wsh rather than regular p2sh.
All tests have been updated accordingly.
This method has been added in order to allow lnd to collect eligible
unspent witness programs outputs from the wallet controller for use as
inputs to the funding transaction.
Additionally, the change address functions now also specify whether the
generated change address should be payable to a witness program or not.
The WalletController will serve as a layer of separation between “base”
Bitcoin wallet logic, and the higher level Lightning Network logic. As
a result LightningWallet will no behave as an overly wallet, relying on
the lower wallet for basic services such as new address, signing etc.
Within this higher level lies the awareness of channel types, chain
monitoring, HTLCs, and so on.
* Previously, if the call to SetUp(..) returned an error, then the test
harness would fail to stop the running bcd process, and clean up the
test directories. This would cause any subsequent tests to fail. This
commit remedies this scenario.
Allows us to remove a lot of duplicated code pertaining to wallet
setup. We also gain hooks into the wallet to trigger callbacks once the
wallet is created/opened.
Instead of creating “fake” utxos for bob, and alice. We now employ a
dedicated mining node to hand out utxos, and generate blocks with hand
picked transactions.
A major change for btcwallet adding a new RPC wallet, refactoring parts
of the wallet, and introducing new functionality has been introduced.
This commit updates lnwallet to the API changes. A future commit will
change lnwallet to use some of the new functionality such as the
notification server, etc.
Select over the quit channel in order to shutdown goroutines waiting
for funding txn confirmations. Without this we may leak goroutines
which are blocked forever if the process isn’t exiting when the walet
is signaled to shutdown.
* Hooks into the ChainNotifier infrastructure to receive a notification
once the funding transaction gets enough notifications.
* Still need to set up the notification grouting within a
LightningChannel to watch for uncooperative closures, and broadcasts
and revoked channel states.
* In preparation for regression testing once nodetest is finished.
* These sections we’re previously uncommented to allow for testing the
wallet without a full-node hooked up.
