lnwire/README.md: Hopefully this will be legible
This commit is contained in:
parent
85590e0f6c
commit
84c0f56330
@ -1,33 +1,32 @@
|
|||||||
Funding (segwit+CSV)
|
# Funding (segwit+CSV)
|
||||||
====================
|
|
||||||
|
|
||||||
This is two-party funder for a single Funding Transaction (more efficient and
|
This is two-party funder for a single Funding Transaction (more efficient and
|
||||||
makes the channel creation atomic, but doesn't work for
|
makes the channel creation atomic, but doesn't work for
|
||||||
CSV-no-malleability-fix).
|
CSV-no-malleability-fix).
|
||||||
|
|
||||||
Funding Request
|
### Funding Request
|
||||||
---------------
|
|
||||||
Someone wants to open a channel. The requester provides any inputs and relevant
|
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
|
information on how much they want to fund and the parameters, these paramters
|
||||||
are a proposal.
|
are a proposal.
|
||||||
|
|
||||||
Funding Response
|
### Funding Response
|
||||||
----------------
|
|
||||||
If the responder accepts the request, they also provide any inputs, and returns
|
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
|
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,
|
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
|
they stop. The response also contains the first Commitment pubkey provided by the
|
||||||
responder, which refunds the initial balance back to both parties.
|
responder, which refunds the initial balance back to both parties.
|
||||||
|
|
||||||
Funding SignAccept
|
### Funding SignAccept
|
||||||
------------
|
|
||||||
The requester now has sufficient information to get a refund if the transaction
|
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
|
is ever broadcast. The requester signs the Funding Transaction and this message
|
||||||
gives the signature to the responder. The requester also provides the signature
|
gives the signature to the responder. The requester also provides the signature
|
||||||
for the initial Commitment Transaction.
|
for the initial Commitment Transaction.
|
||||||
|
|
||||||
Funding SignComplete
|
### Funding SignComplete
|
||||||
---------------
|
|
||||||
The responder has sufficient information to broadcast the Funding Transaction
|
The responder has sufficient information to broadcast the Funding Transaction
|
||||||
(with the ability to receive a refund), the responder broadcasts on the
|
(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
|
blockchain and returns the txid to the requester, with the signature of the
|
||||||
@ -37,28 +36,26 @@ braodcast without this message being received by the requester. After the
|
|||||||
necessary number of confirmations, Lightning Network transactions can proceed.
|
necessary number of confirmations, Lightning Network transactions can proceed.
|
||||||
|
|
||||||
|
|
||||||
Cooperative Channel Close
|
# Cooperative Channel Close
|
||||||
=========================
|
|
||||||
|
|
||||||
This is when either party want to close out a channel with the current balance.
|
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
|
Requires the cooperation of both parites for this type. In the event of
|
||||||
non-cooperation, either party may broadcast the most recent Commitment
|
non-cooperation, either party may broadcast the most recent Commitment
|
||||||
Transaction.
|
Transaction.
|
||||||
|
|
||||||
Close Request
|
### Close Request
|
||||||
-------------
|
|
||||||
One party unilaterally sends their sig and fee amount to the other party. No
|
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
|
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.
|
the outputs, but for now, we're assuming *all* HTLCs are cleared out.
|
||||||
|
|
||||||
Close Complete
|
### Close Complete
|
||||||
----------------------
|
|
||||||
Returns the Txid and sig as a courtesy. The counterparty might not send this if
|
Returns the Txid and sig as a courtesy. The counterparty might not send this if
|
||||||
they're being non-cooperative.
|
they're being non-cooperative.
|
||||||
|
|
||||||
|
|
||||||
Commitments and HTLCs
|
# Commitments and HTLCs
|
||||||
=====================
|
|
||||||
|
|
||||||
This is designed to be non-blocking where there can be multiple Commitments per
|
This is designed to be non-blocking where there can be multiple Commitments per
|
||||||
person and the Commitments do not need to match. A HTLC is only believed to be
|
person and the Commitments do not need to match. A HTLC is only believed to be
|
||||||
@ -69,10 +66,10 @@ by the counterparty.
|
|||||||
As a result, there can easily be hundreds of state updates/payments per second
|
As a result, there can easily be hundreds of state updates/payments per second
|
||||||
per channel.
|
per channel.
|
||||||
|
|
||||||
Commitment States
|
### Commitment States
|
||||||
-----------------
|
|
||||||
|
|
||||||
Commitments:
|
Commitments:
|
||||||
|
|
||||||
1. HTLCs, can be modified. Any add/settlement/timeout/etc. gets added to
|
1. HTLCs, can be modified. Any add/settlement/timeout/etc. gets added to
|
||||||
staging.
|
staging.
|
||||||
2. Signed, more than one signed state at a time may exist per party. Takes
|
2. Signed, more than one signed state at a time may exist per party. Takes
|
||||||
@ -101,10 +98,10 @@ Messages:
|
|||||||
CommitSignature: Signature to establish COMMIT\_SIGNED state
|
CommitSignature: Signature to establish COMMIT\_SIGNED state
|
||||||
CommitRevocation: Revoke prior states
|
CommitRevocation: Revoke prior states
|
||||||
|
|
||||||
ADD HTLCs
|
### ADD HTLCs
|
||||||
---------
|
|
||||||
|
|
||||||
Requester Add HTLC states (Adding HTLCs):
|
Requester Add HTLC states (Adding HTLCs):
|
||||||
|
|
||||||
1. Pre-staged, don't know if the other person wants it
|
1. Pre-staged, don't know if the other person wants it
|
||||||
2. Staged, both parties agree to add this HTLC. If a staging request packet is
|
2. Staged, both parties agree to add this HTLC. If a staging request packet is
|
||||||
received, then BOTH PARTIES will have it in their next Commitment. Nothing
|
received, then BOTH PARTIES will have it in their next Commitment. Nothing
|
||||||
@ -152,10 +149,10 @@ HTLCAddRequest: Request to add to staging
|
|||||||
HTLCAddAccept: Add to staging (both parties have added when recv)
|
HTLCAddAccept: Add to staging (both parties have added when recv)
|
||||||
HTLCAddReject: Deny add to staging (both parties don't have in staging)
|
HTLCAddReject: Deny add to staging (both parties don't have in staging)
|
||||||
|
|
||||||
HTLC Settle (payment success)
|
### HTLC Settle (payment success)
|
||||||
-----------------------------
|
|
||||||
|
|
||||||
Requester Settle HTLC states (Fulfill HTLCs):
|
Requester Settle HTLC states (Fulfill HTLCs):
|
||||||
|
|
||||||
1. Pre-staged, don't know if the other person will agree to settle
|
1. Pre-staged, don't know if the other person will agree to settle
|
||||||
2. Staged, both parties agree to settle this HTLC
|
2. Staged, both parties agree to settle this HTLC
|
||||||
3. Signed and sent Commitment Tx to the counterparty, there is now the
|
3. Signed and sent Commitment Tx to the counterparty, there is now the
|
||||||
@ -184,10 +181,10 @@ HTLCSettleAccept: Add to staging the removal from Commitment.
|
|||||||
(There is no HTLCSettleReject as the counterparty should immediately close out
|
(There is no HTLCSettleReject as the counterparty should immediately close out
|
||||||
or at worst ignore if it's getting garbage requests)
|
or at worst ignore if it's getting garbage requests)
|
||||||
|
|
||||||
Timeout (falure/refund)
|
### Timeout (falure/refund)
|
||||||
-----------------------
|
|
||||||
|
|
||||||
Requester Timeout HTLC States:
|
Requester Timeout HTLC States:
|
||||||
|
|
||||||
1. Pre-staged
|
1. Pre-staged
|
||||||
2. Staged, both parties agree to time out the HTLC and refund the money
|
2. Staged, both parties agree to time out the HTLC and refund the money
|
||||||
3. Signe dnad sent commitment to the counterparty, there is now the possibility
|
3. Signe dnad sent commitment to the counterparty, there is now the possibility
|
||||||
@ -208,12 +205,12 @@ TIMEOUT\_SIGNING\_AND\_REVOKING
|
|||||||
TIMEOUT\_COMPLETE
|
TIMEOUT\_COMPLETE
|
||||||
|
|
||||||
|
|
||||||
Example (this section to be removed)
|
### Example (this section to be removed)
|
||||||
------------------------------------
|
|
||||||
|
|
||||||
A bit redundant, but this was written first... will merge with "Add" example
|
A bit redundant, but this was written first... will merge with "Add" example
|
||||||
|
|
||||||
Adding a single HTLC process:
|
Adding a single HTLC process:
|
||||||
|
|
||||||
1. Requester flags as pre-staged, and sends an "add requeset"
|
1. Requester flags as pre-staged, and sends an "add requeset"
|
||||||
2. Responder decides whether to add. If they don't, they invalidate it. If they
|
2. Responder decides whether to add. If they don't, they invalidate it. If they
|
||||||
do, they send a message accepting the staging request. It is now marked as
|
do, they send a message accepting the staging request. It is now marked as
|
||||||
|
Loading…
Reference in New Issue
Block a user