* 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.
* Updates to the channel are made atomic, and consistent via a proxy
object: “ChannelUpdate” which encapsulates an update transaction. Only
one update transaction may be outstanding at any time.
* Update transactions are initiated via AddHTLC or SettleHTLC.
* Once a transaction has been begun, in order to complete the update
the transaction must first be presented with a signature from the
counter-party for our new version of the commitment tx
(VerifyNewCommitmentSigs), and finally to atomically commit the
transaction, the counterparty’s pre-image to their previous revocation
hash must be validate (Commit).
* Workflow along with expected call orders have been documented.
* With this, the initial iteration of ChannelReservation is mostly
complete.
* However, there are still some unfinished steps internally within the
wallet related to processing. Such as factoring proper tx fees,
splitting fees, some node interaction etc.
* 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.
