mirrors/lightning-bolts
1
0
Fork 0
mirror of https://github.com/lightning/bolts.git synced 2024-11-19 01:50:03 +01:00
Code Issues Projects Releases Wiki Activity

BOLT 5: Add TOC, Authors section, add BOLT URL references.

Browse Source 
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-05-11 11:16:05 +09:30
parent 6340cf0db5
commit 67efbd0872
1 changed files with 20 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

25
05-onchain.md
View File

@ -6,15 +6,27 @@ Lightning allows for two parties (A and B) to make transactions off-chain, by bo
There are three ways a channel can end:
1. The good way (*mutual close*): at some point A and B agree on closing the channel, they generate a *closing transaction* (which is similar to a *commitment transaction* without any pending payments), and publish it on the blockchain (see "BOLT #2: Channel close").
1. The good way (*mutual close*): at some point A and B agree on closing the channel, they generate a *closing transaction* (which is similar to a *commitment transaction* without any pending payments), and publish it on the blockchain (see [BOLT #2: Channel Close](02-peer-protocol.md#channel-close)).
2. The bad way (*unilateral close*): something goes wrong, without necessarily any evil intent on either side (maybe one party crashed, for instance). Anyway, one side publishes its latest *commitment transaction*.
3. The ugly way (*revoked transaction close*): one of the parties deliberately tries to cheat by publishing an outdated version of its *commitment transaction* (presumably one that was more in her favor).
Because Lightning is designed to be trustless, there is no risk of loss of funds in any of these 3 cases, provided that the situation is properly handled. The goal of this document is to explain exactly how node A should react to seeing any of these on-chain.
## Table of Contents
TODO
# Table of Contents
* [General Nomenclature](#general-nomenclature)
* [Commitment Transaction](#commitment-transaction)
* [Mutual Close Handling](#mutual-close-handling)
* [Unilateral Close Handling](#unilateral-close-handling)
* [On-chain HTLC Output Handling: Our Offers](#on-chain-htlc-output-handling-our-offers)
* [On-chain HTLC Output Handling: Their Offers](#on-chain-htlc-output-handling-their-offers)
* [On-chain HTLC Transaction Handling](#on-chain-htlc-transaction-handling)
* [Revoked Transaction Close Handling](#revoked-transaction-close-handling)
* [Penalty Transactions Weight Calculation](#penalty-transactions-weight-calculation)
* [General Requirements](#general-requirements)
* [Appendix A: Expected weights](#appendix-a-expected-weights)
* [Expected weight of the to-local penalty transaction witness](#expected-weight-of-the-to-local-penalty-transaction-witness)
* [Expected weight of the received-htlc penalty transaction witness](#expected-weight-of-the-received-htlc-penalty-transaction-witness)
* [Authors](#authors)
# General Nomenclature
@ -82,7 +94,7 @@ A and B each hold a *commitment transaction*, which has 4 types of outputs:
As an incentive for A and B to cooperate, an `OP_CHECKSEQUENCEVERIFY` relative timeout encumbers A's outputs in A's *commitment transaction*, and B's outputs in B's *commitment transaction*. If A publishes its commitment transaction, she won't be able to get her funds immediately but B will. As a consequence, A and B's *commitment transactions* are not identical, they are (usually) symmetrical.
See "BOLT #3: Bitcoin Transaction and Script Formats" for more details.
See [BOLT #3: Commitment Transaction](03-transactions.md#commitment-transaction) for more details.
# Mutual Close Handling
@ -429,6 +441,9 @@ The *expected weight* is calculated as follows (some calculations have already b
- witness_script_length: 1 byte
- witness_script (accepted_htlc_script)
# Authors
FIXME
![Creative Commons License](https://i.creativecommons.org/l/by/4.0/88x31.png "License CC-BY")
<br>