akovalenko/lnd.xprv
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

fix typos

Browse Source
This commit is contained in:
Andrey Samokhvalov 2016-10-30 17:54:59 +03:00
parent f37956e38e
commit 8dcf274a2d
2 changed files with 6 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

8
lnwire/commit_signature.go
View File

@ -10,8 +10,8 @@ import (
)
// CommitSignature is sent by either side to stage any pending HTLC's in the
// reciever's pending set which has not explcitly been rejected via an
// HTLCAddReject message. Implictly, the new commitment transaction constructed
// receiver's pending set which has not explicitly been rejected via an
// HTLCAddReject message. Implicitly, the new commitment transaction constructed
// which has been signed by CommitSig includes all HTLC's in the remote node's
// pending set. A CommitSignature message may be sent after a series of HTLCAdd
// messages in order to batch add several HTLC's with a single signature
@ -21,7 +21,7 @@ type CommitSignature struct {
// CommitSignature applies to.
ChannelPoint *wire.OutPoint
// LogIndex is the index into the reciever's HTLC log to which this
// LogIndex is the index into the receiver's HTLC log to which this
// commitment signature covers. In order to properly verify this
// signature, the receiver should include all the HTLC's within their
// log with an index less-than-or-equal to the listed log-index.
@ -35,7 +35,7 @@ type CommitSignature struct {
// CommitSig is Alice's signature for Bob's new commitment transaction.
// Alice is able to send this signature without requesting any additional
// data due to the piggybacking of Bob's next revocation hash in his
// prior CommitRevocation message, as well as the cannonical ordering
// prior CommitRevocation message, as well as the canonical ordering
// used for all inputs/outputs within commitment transactions.
CommitSig *btcec.Signature
}

4
peer.go
View File

@ -980,7 +980,7 @@ out:
// update in some time, check to see if we have any
// pending updates we need to commit. If so, then send
// an update incrementing the unacked counter is
// succesful.
// successfully.
if !state.channel.PendingUpdates() &&
len(state.htlcsToSettle) == 0 {
continue
@ -1221,7 +1221,7 @@ func (p *peer) handleUpstreamMsg(state *commitmentState, msg lnwire.Message) {
// If any of the htlc's eligible for forwarding are pending
// settling or timeing out previous outgoing payments, then we
// can them from the pending set, and signal the requster (if
// can them from the pending set, and signal the requester (if
// existing) that the payment has been fully fulfilled.
var bandwidthUpdate btcutil.Amount
settledPayments := make(map[lnwallet.PaymentHash]struct{})