f3849f5c10
* 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 |
||
|---|---|---|
| .. | ||
| close_complete_test.go | ||
| close_complete.go | ||
| close_request_test.go | ||
| close_request.go | ||
| commit_revocation_test.go | ||
| commit_revocation.go | ||
| commit_signature_test.go | ||
| commit_signature.go | ||
| ESCROWED_HTLC_NOTES | ||
| funding_request_test.go | ||
| funding_request.go | ||
| funding_response_test.go | ||
| funding_response.go | ||
| funding_signaccept_test.go | ||
| funding_signaccept.go | ||
| funding_signcomplete_test.go | ||
| funding_signcomplete.go | ||
| htlc_addaccept_test.go | ||
| htlc_addaccept.go | ||
| htlc_addreject_test.go | ||
| htlc_addreject.go | ||
| htlc_addrequest_test.go | ||
| htlc_addrequest.go | ||
| htlc_settleaccept_test.go | ||
| htlc_settleaccept.go | ||
| htlc_settlerequest_test.go | ||
| htlc_settlerequest.go | ||
| htlc_timeoutaccept_test.go | ||
| htlc_timeoutaccept.go | ||
| htlc_timeoutrequest_test.go | ||
| htlc_timeoutrequest.go | ||
| lnwire_test.go | ||
| lnwire.go | ||
| message.go | ||
| README.md | ||
Funding (segwit+CSV)
This is two-party funder for a single Funding Transaction (more efficient and makes the channel creation atomic, but doesn't work for CSV-no-malleability-fix).
Funding Request
Someone wants to open a channel. The requester provides any inputs and relevant information on how much they want to fund and the parameters, these paramters are a proposal.
Funding Response
If the responder accepts the request, they also provide any inputs, and returns with parameters as well. These parameters are now considered "Committed" and the negotation has finished. If the requester doesn't agree with the new conditions, they stop. The response also contains the first Commitment pubkey provided by the responder, which refunds the initial balance back to both parties.
Funding SignAccept
The requester now has sufficient information to get a refund if the transaction is ever broadcast. The requester signs the Funding Transaction and this message gives the signature to the responder. The requester also provides the signature for the initial Commitment Transaction.
Funding SignComplete
The responder has sufficient information to broadcast the Funding Transaction (with the ability to receive a refund), the responder broadcasts on the blockchain and returns the txid to the requester, with the signature of the Funding Transaction. This is provided as a courtesy, it cannot be relied upon with non-cooperative channel counterparties and the Funding Transaction can be braodcast without this message being received by the requester. After the necessary number of confirmations, Lightning Network transactions can proceed.
Cooperative Channel Close
This is when either party want to close out a channel with the current balance. Requires the cooperation of both parites for this type. In the event of non-cooperation, either party may broadcast the most recent Commitment Transaction.
Close Request
One party unilaterally sends their sig and fee amount to the other party. No further channel updates are possible. In the future, we might include HTLCs in the outputs, but for now, we're assuming all HTLCs are cleared out.
Close Complete
Returns the Txid and sig as a courtesy. The counterparty might not send this if they're being non-cooperative.