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.
