* 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.
* Currently depends on the wallet, but that will change in the near
future due to new additions to btcwallet currently under review.
* Re-orgs aren’t intelligently handled yet. To be done along with tests
in a later commit.
* So far very simple, only notifications for tx confirmations, and
outpoint spends.
* Our two cases are: waiting for the funding transaction to reach a
depth of N confirmations, and open channels being notified of the
counterpart trying to cheat them by broadcasting an invalidated
commitment tx.
* 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.
* Structs and wire messages for HTLCs
* Wire protocol for a state machine with no blocking(!!!)
(I will write the state machine)
TL;DR: Can do multiple HTLC modifications in-flight, dead simple wire
protocol. Both sides can update their Commitments unliaterally without
waiting for the other party's signature. Will have basic/preliminary
notes in the README
* Added **swp to .gitignore because of vim annoyances
* FundingSignAccept and FundingSingComplete had *[]btcec.Signature and
instead it's now []*btcec.Signature to match other slice types.
* Refactored lnwire's when doing readElement/writeElement on slices
* 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.
* Added field
* Renamed FundingAmount and ReserveAmount to specify in FundingRequest
and FundingResponse that it is for RequesterFundingAmount or
ResponderFundingAmount
* Added PaymentAmount field to FundingRequest
* Added MinDepth field to FundingRequest and FundingResponse
* Fixed .Serialize() to show inputs/etc. only if there are fields
available (prevents trying to dereference nil value)
* Add a bunch of Validate() conditions
* MASSIVE REFACTOR of tests (removed tons of redundancy)
