Archives/lnbook
2
0
Fork 0
mirror of https://github.com/lnbook/lnbook synced 2024-11-01 03:20:53 +00:00
Code Issues Projects Releases Wiki Activity

Typo "the the"

Browse Source
This commit is contained in:
Frnk 2021-04-05 17:25:17 +02:00
parent 1f51de2b51
commit 9852fa8592
2 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
channel-construction.asciidoc
View File

@ -55,7 +55,7 @@ While your funds on the Lightning Network are called to be "off-chain" they are
One thing about the Lightning Network is however messing with this understanding of ownership.
On the Lightning Network there exist several presigned Transactions which allocate some of the bitcoin to you and some to your channel partner.
Without the the ability to sequence transaction and invalidate old ones via the penalty based revocation mechanism (or other techniques) we could not define clear ownership as the funds would be distributed among its two owners according to which ever transaction would first be broadcasted and successfully mined.
Without the ability to sequence transaction and invalidate old ones via the penalty based revocation mechanism (or other techniques) we could not define clear ownership as the funds would be distributed among its two owners according to which ever transaction would first be broadcasted and successfully mined.
If the last paragraph of this summary was confusing: No worries! We are getting there now!
****

2
channel-operation.asciidoc
View File

@ -129,7 +129,7 @@ The `revoke_and_ack` Lightning message contains three data fields.
* [`point`:`next_per_commitment_point`]
While it is really simple and straight forward it is very crucial.
Bob shares the the `per_commitment_secret` of the old commitment transaction which serves as the revocation key and would allow Alice in future to penalize Bob if he publishes the old commitment transaction without the HTLC output.
Bob shares the `per_commitment_secret` of the old commitment transaction which serves as the revocation key and would allow Alice in future to penalize Bob if he publishes the old commitment transaction without the HTLC output.
As in a future Alice and Bob might want to negotiate additional commitment transactions he already shares back the `next_per_commitment_point` that he will use in his next commitment transaction.
Alice checks that the `per_commitment_secret` produces the last `per_commitment_point` and constructs her new commitment transaction with the HTLC output.