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

Use a vs an consistently

Browse Source
This commit is contained in:
practicalswift 2018-02-08 14:49:30 +01:00 committed by Rusty Russell
parent 5fe7fc3d62
commit 316882fcc5
3 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
03-transactions.md
View File

@ -111,7 +111,7 @@ This output sends funds to the other peer and thus is a simple P2WPKH to `remote
#### Offered HTLC Outputs
This output sends funds to either a HTLC-timeout transaction after the HTLC-timeout or to the remote node using the payment preimage or the revocation key. The output is a P2WSH, with a witness script:
This output sends funds to either an HTLC-timeout transaction after the HTLC-timeout or to the remote node using the payment preimage or the revocation key. The output is a P2WSH, with a witness script:
# To remote node with revocation key
OP_DUP OP_HASH160 <RIPEMD160(SHA256(revocationpubkey))> OP_EQUAL
@ -345,14 +345,14 @@ The commitment transaction `weight` is calculated as follows:
* The offered HTLC of 5000 satoshis is above 546 + 3315 and results in:
* an output of 5000 satoshi in the commitment transaction
* a HTLC-timeout transaction of 5000 - 3145 satoshis that spends this output
* an HTLC-timeout transaction of 5000 - 3145 satoshis that spends this output
* `weight` increases to 896
* The offered HTLC of 1000 satoshis is below 546 + 3315 so is trimmed.
* The received HTLC of 7000 satoshis is above 546 + 3590 and results in:
* an output of 7000 satoshi in the commitment transaction
* a HTLC-success transaction of 7000 - 3590 satoshis that spends this output
* an HTLC-success transaction of 7000 - 3590 satoshis that spends this output
* `weight` increases to 1068
* The received HTLC of 800 satoshis is below 546 + 3515 so is trimmed.

2
05-onchain.md
View File

@ -426,7 +426,7 @@ timeout, as there's no way to signal early failure.
If an HTLC is too small to appear in *any commitment transaction*, it
can be safely failed immediately. Otherwise,
if a HTLC isn't in the *local commitment transaction* a node needs to make sure
if an HTLC isn't in the *local commitment transaction* a node needs to make sure
that a blockchain reorganization or race does not switch to a
commitment transaction that does contain it before the node fails it: hence
the wait. The requirement that the incoming HTLC be failed before its

2
07-routing-gossip.md
View File

@ -576,7 +576,7 @@ here for simplicity:
* `amt_to_forward` = 4999999
* `outgoing_cltv_value` = current-block-height + 9 + 42
**A->B->C.** If A were to send an 4,999,999 millisatoshi to C via B, it needs to
**A->B->C.** If A were to send 4,999,999 millisatoshi to C via B, it needs to
pay B the fee it specified in the B->C `channel_update`, calculated as
per [HTLC Fees](#htlc_fees):