This commit introduces the fundingManger which is used as a bridge
between the wallet’s internal ‘ChannelReservation’ workflow, and the
wire protocol’s funding messages.
The funding manger is responsible for progressing the workflow, and
communicating any errors generated during the workflow back to the
source 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.
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.
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.
* moved sorting of transaction outside of createCommitTx also us to add
HTLC’s before sorting
* On the fence about the proxy object design, will re-visit once we
start to implement the p2p code.
* As a result in order to not over-shadow the Start/Stop methods of
btcwallet.Wallet, the Start/Stop methods on LightningWallet have been
renamed to Startup/Shutdown.
* Initial draft of brain dump of chandler. Nothing yet set in stone.
* Will most likely move the storage of all structs to a more “column”
oriented approach. Such that, small updates like incrementing the total
satoshi sent don’t result in the entire struct being serialized and
written.
* Some skeleton structs for other possible data we might want to store
are also included.
* Seem valuable to record as much data as possible for record keeping,
visualization, debugging, etc. Will need to set up a time+space+dirty
cache to ensure performance isn’t impacted too much.
* Contribution from remote host necessary to construct the initial
commitment transaction is now also expected
* All message structs and handlers updated accordingly
* AddContribution now also generates both commitment tnxs, and
generates a signature for their version of the commitment transaction
* Future commit will ditch all the thread-safe “getter” like methods.
We’re all adults just make sure to grab the lock.
* All wallet mutation funcs will also document which fields are set
after completion of the request
* Set shaChain, delivery address, commitment key
