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 2: typo fixes.

Browse Source 
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This commit is contained in:
Rusty Russell 2017-05-02 16:18:01 +09:30
parent 6849b2bbc6
commit c3b078bad2
2 changed files with 10 additions and 12 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
.aspell.en.pws
View File

@ -1,4 +1,4 @@
personal_ws-1.1 en 260
personal_ws-1.1 en 258
secp
sig
unguessable
@ -87,8 +87,8 @@ ammag
computeBlindingFactor
wsh
multiScalarMult
onionpacket
OnionPacket
onionpacket
ikm
fillerSize
txinput
@ -108,7 +108,7 @@ delayedsig
hopDataSize
I'th
segwit
HTLC
htlc
ChaCha
len
ciphertext
@ -220,12 +220,10 @@ num
numStreamBytes
txout
HTLCs
htlcs
HTLC's
retransmission
decrypted
sessionKey
sessionkey
sessionKey
PRIVMSG
routingInfoSize
hostname

12
02-peer-protocol.md
View File

@ -173,7 +173,7 @@ The *channel reserve* is specified by the peer's `channel-reserve-satoshis`; 1%
The sender can unconditionally give initial funds to the receiver using a non-zero `push-msat`, and this is one case where the normal reserve mechanism doesn't apply. However, like any other on-chain transaction, this payment is not certain until the funding transaction has been confirmed sufficiently (may be double-spent) and may require a separate method to prove payment via on-chain confirmation.
The `feerate-per-kw` is generally only a concern to the sender (who pays the fees), but that is also the feerate paid by HTLC transactions; thus unresonably large fee rates can also penalize the reciepient.
The `feerate-per-kw` is generally only a concern to the sender (who pays the fees), but that is also the feerate paid by HTLC transactions; thus unreasonably large fee rates can also penalize the recipient.
#### Future
@ -301,7 +301,7 @@ negotiation begins.
| |--(1)----- shutdown ------->| |
| |<-(2)----- shutdown --------| |
| | | |
| | <complete all pending htlcs> | |
| | <complete all pending HTLCs> | |
| A | ... | B |
| | | |
| |<-(3)-- closing_signed F1----| |
@ -780,7 +780,7 @@ preimage for the previous commitment transaction in a `revoke_and_ack`
message.
This message also implicitly serves as an acknowledgement of receipt
This message also implicitly serves as an acknowledgment of receipt
of the `commitment_signed`, so it's a logical time for the `commitment_signed` sender
to apply to its own commitment, any pending updates it sent before
that `commitment_signed`.
@ -882,7 +882,7 @@ retransmit any channel messages which may not have been.
This is fairly straightforward in the case of channel establishment
and close where messages have an explicit order, but in normal
operation acknowlegements of updates are delayed until the
operation acknowledgments of updates are delayed until the
`commitment_signed` / `revoke_and_ack` exchange, so we cannot assume
the updates have been received. This also means that the receiving
node only needs to store updates upon receipt of `commitment_signed`.
@ -908,7 +908,7 @@ so the effects of `update_fulfill_htlc` is not completely reversed.
On reconnection, a node MUST retransmit old messages which may not
have been received, and MUST NOT retransmit old messages which have
been explicitly or implicitly acknowledged. The following table
lists the acknowledgement conditions for each message:
lists the acknowledgment conditions for each message:
* `open_channel`: acknowledged by `accept_channel`.
* `accept_channel`: acknowledged by `funding_created`.
@ -921,7 +921,7 @@ lists the acknowledgement conditions for each message:
* `shutdown`: acknowledged by `closing_signed`.
The last `closing_signed` (if any) must always be retransmitted, as there
is no explicit acknowledgement.
is no explicit acknowledgment.
Before retransmitting `commitment_signed`, the node MUST send
appropriate `update_` messages (the other node will have forgotten