Commit Graph

129 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
e05ec619ca
peer: ensure no messages are sent/processed _before_ all channels loaded
This commit fixes a bug which could at times cause channels to be
unusable upon connection. The bug would manifest like the following:
two peers would connect, one loads their channels faster than the
other, this would result in the winning peer attempting to extend their
revocation window. However, if the other peer hadn’t yet loaded the
channel, then this would appear to them to be an unknown channel.

We properly fix this issue by ensure all channels are loaded _before_
any of the goroutines needed for the operation of the peer are
launched.
2017-05-11 15:21:00 -07:00
Olaoluwa Osuntokun
d47f004fbd
peer+rpcserver+breacharbiter: usel latest ChainNotifier API 2017-05-11 15:20:55 -07:00
Olaoluwa Osuntokun
071aa3ad75
peer: log which channel point when revocation window exhausted 2017-05-04 17:39:42 -07:00
Olaoluwa Osuntokun
62d6ac6a8f
peer: properly manage channel close lifecycle within the database
Within this commit the peer will now properly manage the channel close
life cycle within the database. This entails marking the channel as
pending closed either once the closing transaction has been broadcast
or the close request message has been sent to the other side.

Once the closing transaction has been confirmed, the transaction will
be marked as fully closed within the database. A helper function has
been added to factor out “waiting for a transaction to confirm” when
handling moth local and remote cooperative closure flows.

Finally, we no longer delete the channel state within wipeChannel as
this will now be managed distinctly by callers.
2017-05-04 17:39:40 -07:00
Olaoluwa Osuntokun
4cb76071a2
server+peer: re-write persistent connection handling
The prior methods we employed to handle persistent connections could
result in the following situation: both peers come up, and
_concurrently_ establish connection to each other. With the prior
logic, at this point, both connections would be terminated as each peer
would go to kill the connection of the other peer. In order to resolve
this issue in this commit, we’ve re-written the way we handle
persistent connections.

The eliminate the issue described above, in the case of concurrent peer
connection, we now use a deterministic method to decide _which_
connection should be closed. The following rule governs which
connection should be closed: the connection of the peer with the
“smaller” public key should be closed. With this rule we now avoid the
issue described above.

Additionally, each peer now gains a peerTerminationWatcher which waits
until a peer has been disconnected, and then cleans up all resources
allocated to the peer, notifies relevant sub-systems of its demise, and
finally handles re-connecting to the peer if it's persistent. This
replaces the goroutine that was spawned in the old version of
peer.Disconnect().
2017-04-23 19:58:03 -07:00
Olaoluwa Osuntokun
00a7f140ff
peer: add WaitForDisconnect method
This commit adds a new method to the peer struct: WaitForDisconnect().
This method is put in place to be used by wallers to synchronize the
ending of a peer’s lifetime. A follow up commit will utilize this new
method to re-write the way we handle persistent peer connections.
2017-04-23 19:29:44 -07:00
Olaoluwa Osuntokun
0ef36dca9b
peer: remove the Stop() method in favor of only Disconnect() 2017-04-23 19:25:22 -07:00
Olaoluwa Osuntokun
52ffb026af
peer: return more detailed errors from the Start() method 2017-04-23 19:24:33 -07:00
Olaoluwa Osuntokun
adce64e21c
peer: we now load active channel during startup, not creation 2017-04-23 19:23:22 -07:00
Olaoluwa Osuntokun
010373fe0f
peer: modify readMessage/writeMessage to be message oriented
This commit modifies both readMessage and writeMessage to be further
message oriented. This means that message will be read and written _as
a whole_ rather than piece wise. This also fixes two bugs: the
readHandler could be blocked due to an sync read, and the writeHandler
would unnecessarily chunk up wire messages into distinct crypto
messages rather than writing it in one swoop.

Also with these series of changes, we’re now able to properly parse
messages that have been padded out with additional data as is allowed
by the current specification draft.
2017-04-20 15:45:59 -07:00
Olaoluwa Osuntokun
f867252139
peer: switch to new WriteMessage/ReadMessage after wire msg changes 2017-04-19 16:23:22 -07:00
Olaoluwa Osuntokun
feec611531
lnwire+peer: implement new ping/pong messages and behavior
This commit implements the new ping/pong messages along with their new
behavior. The new set of ping/pong messages allow clients to generate
fake cover traffic as the ping messages tells the pong message how many
bytes to included and can also be padded itself.
2017-04-16 18:11:45 -07:00
Olaoluwa Osuntokun
193936374a
peer: fix deadlock bug, block readHandler when waiting for chan open
This commit fixes a deadlock bug within the readHandler of the peer.
Previously, once a channel was pending opening, _no_ other message
would be processed by the readHandler as it would be blocked waiting
for the channel to open. On testnet this would be manifsted as a node
locking up, until the channel was detected as being open.

We fix this bug by tracking which channel streams are active. If a
channel stream is active, then we can send the update directly to it.
Otherwise, we launch a goroutine that’ll block until the channel is
open, then in a synchronized manner, update the channel stream as being
active and send the update to the channel.
2017-04-16 15:45:24 -07:00
Olaoluwa Osuntokun
60c0cebfd5
lnd: switch over internal indexes to use the new Channel ID's 2017-04-16 15:41:19 -07:00
Olaoluwa Osuntokun
609cba95d7
funding+peer: switch to using new channel ID's
This commit modifies the way the fundingManager tracks pending funding
workflows internally. Rather than using the old auto-incrementing
64-bit pending channel ID’s, we now use a 32-byte pending channel ID
which is generated using a CSPRG. Additionally, once the final funding
message has been sent, we now de-multiplex the FundingLocked message
according to the new Channel ID’s which replace the old ChannelPoint’s
and are exactly 32-bytes long.
2017-04-16 15:34:29 -07:00
Olaoluwa Osuntokun
d146411712
peer: lower logCommitTimer check to 100ms 2017-04-14 11:25:03 -07:00
Olaoluwa Osuntokun
b51a0eb094
peer: increase initial handshake timeout to 15 seconds 2017-04-13 14:48:43 -07:00
Olaoluwa Osuntokun
54c63f4aa1
peer: remove unused lastNMessages map
This map was added very early on as a possible path to implement proper
retransmission. However, we now have a proper persistent retransmission
sub-system being proposed as a PR, therefore we no longer have any use
for this.
2017-04-13 14:32:00 -07:00
Olaoluwa Osuntokun
178f26b8d5
peer: restore the htlcManager's logCommitTimer to a persistent ticker
This commit patches a whole in our optimistic channel synchronization
logic by making the logCommitTimer a persistent ticker rather than one
that is activated after receiving a commitment, and disabled once we
send a new commitment ourself. In the setting of batched full-duplex
channel updates, the prior approach could at times result in a benign
state desync caused by one side being one commitment ahead of the other
because one of the nodes failed to, or was unable to provide the other
with a state update during the workflow.
2017-04-11 22:02:44 -07:00
Olaoluwa Osuntokun
3393f3a8db
peer: simplify channel state update handling by using
This commit simplifies the channel state update handling by doing away
with the commitmentState.pendingUpdate method all together. The newly
added LightningChannel.FullySynced method replace the prior state and
also replaced all other uses of PendingUpdates.

By moving to using channel.FullySynced() we also eliminate class of
desynchronization error caused by a node failing to provide the other
side with the latest commitment state.
2017-04-11 22:02:36 -07:00
Andrey Samokhvalov
d4055d7830 discovery+funding: add validation of the announcement messages
Add validation functions and include validation checks in the
annoncement process function.
2017-03-29 19:49:05 -07:00
Andrey Samokhvalov
fbf766e3c6 discovery+funding: add 'AnnounceSignature' proof exchange
Add the interaction between nodes of announce signature messages, which
will allow us to exhcnage the half channel announcemen proofs later.
2017-03-29 19:49:05 -07:00
Andrey Samokhvalov
c3b2854428 lnwire: converge discovery part of messages with specification
Change the name of fields of messages which are belong to the discovery
subsystem in a such way so they were the same with the names that are
defined in the specification.
2017-03-29 19:49:05 -07:00
Andrey Samokhvalov
4c52b6e6a4 lnd: replace 'routing' with 'discovery' package
Add usage of the 'discovery' package in the lnd, now discovery service
will be handle all lnwire announcement messages and send them to the
remote party.
2017-03-29 19:49:05 -07:00
Olaoluwa Osuntokun
0e96d273d9
peer: enforce strict timeout on opening handshake
This commit modifies the logic around the opening p2p handshake to
enforce a strict timeout around the receipt of the responding init
message. Before this commit, it was possible for the daemon and certain
RPC calls to deadlock as if a peer connected, but didn’t respond with
an init msg, then we’d be sitting there waiting for them to respond.
With this commit, we’ll now time out, kill the connection and then
possible attempt to re-connect if the connection was persistent.
2017-03-29 19:00:40 -07:00
Olaoluwa Osuntokun
505421db2c
htlcswitch: add HTLC overflow flow-control via bounded channels
This commit fixes a prior bug which would cause the set of HTLC’s on a
node’s commitment to potentially overflow if an HTLC was accepted or
attempted to be forwarded that but the commitment transaction over the
maximum allowed HTLC’s on a commitment transaction. This would cause
the HTLC to silently be rejected or cause a connection disconnect. In
either case, this would cause the two states to be desynchronized any
pending HTLC’s to be ignored.

We fix this issue by introducing the concept of a bounded channel,
which is a channel in which the number of items send and recevied over
the channel must be balanced in order to allow a new send to succeed
w/o blocking. We achieve this by using a chan struct{} as a semaphore
and decrement it each time a packet it sent, increasing the semaphore
one a packet is received. This creates a channel that we can use to
ensure the switch never sends more than N HTLC’s to a link before any
of the HTLC’s have been settled.

With this bug fix, it’s now once again possible to trigger sustained
bursts of payments through lnd nodes.
2017-03-24 16:40:02 -07:00
Olaoluwa Osuntokun
ac83b8ae06
peer: fix bug in handshake wherein RevokeAndAck would be sent first
This commit fixes a bug in the opening handshake between to peers. The
bug would arise when on or many channels were active between a node
establishing a new connection. The htlcManager goroutines will
immediately attempt to extend the revocation window once they’re
active. However, at this time, the init message may not yet have been
sent as the two executions are in distinct goroutines.

We fix this bug by manually writing the init message directly to the
socket, rather than traveling through the queueHandler goroutine. With
this, we ensure that the init message is _always_ sent first.
2017-03-16 19:45:16 -07:00
Olaoluwa Osuntokun
f217093c00
multi: replace usage of fastsha256 with crypto/sha256
This commit removes all instances of the fastsha256 library and
replaces it with the sha256 library in the standard library. This
change should see a number of performance improvements as the standard
library has highly optimized assembly instructions with use vectorized
instructions as the platform supports.
2017-03-15 18:56:41 -07:00
Andrey Samokhvalov
143a6e01bb lnd: fix unconvert warnings 2017-03-13 16:30:23 -07:00
Olaoluwa Osuntokun
b5a6098dd5
peer: don't load channels on connect that are still pending
This commit modifies the peer struct’s loadActiveChannels method to
ensure that it skips over channels that aren’t actually active. This
fixes a bug that could possibly cause a peer to get stuck in a circular
wait loop and also de-sync a channel’s state machine.
2017-02-24 16:32:00 -08:00
bryanvu
eb490b8833 lnwire: add FundingLocked message
When the funding transaction has been confirmed, the FundingLocked
message is sent by the peers to each other so that the existence of the
newly funded channel can be announced to the network.

This commit also removes the SingleFundingOpenProof message.
2017-02-24 11:37:33 -08:00
bryanvu
e549a3f0ed fundingmanager: move final funding steps from wallet to funding manager.
Once a channel funding process has advanced to the point of broadcasting
the funding transaction, the state of the channel should be persisted
so that the nodes can disconnect or go down without having to wait for the
funding transaction to be confirmed on the blockchain.

Previously, the finalization of the funding process was handled by a
combination of the funding manager, the peer and the wallet, but if
the remote peer is no longer online or no longer connected, this flow
will no longer work. This commit moves all funding steps following
the transaction broadcast into the funding manager, which is available
as long as the daemon is running.
2017-02-24 11:37:33 -08:00
bryanvu
0dd6cb99c1 fundingmanager: moved channel barriers from peer to funding manager.
Because peers may become disconnected or otherwise unavailable,
the channel barriers must be stored and managed within the fundingmanager.
2017-02-24 11:37:33 -08:00
Olaoluwa Osuntokun
e910b12d33
lnd: fix issues reported by golint+govet
github.com/lightningnetwork/lnd  master ✗

                                           0m ◒
▶ golint
htlcswitch.go:292:4: should replace numUpdates += 1 with numUpdates++
htlcswitch.go:554:6: var onionId should be onionID
htlcswitch.go:629:7: var onionId should be onionID
lnd_test.go:133:1: context.Context should be the first parameter of a
function
lnd_test.go:177:1: context.Context should be the first parameter of a
function
networktest.go:84:2: struct field nodeId should be nodeID
peer.go:1704:16: should omit 2nd value from range; this loop is
equivalent to `for invoice := range ...`
rpcserver.go:57:6: func newRpcServer should be newRPCServer

github.com/lightningnetwork/lnd  master ✗

                                        9m ⚑ ◒  ⍉
▶ go vet
features.go:12: github.com/lightningnetwork/lnd/lnwire.Feature
composite literal uses unkeyed fields
fundingmanager.go:380: no formatting directive in Errorf call
exit status 1
2017-02-22 14:58:37 -08:00
Andrey Samokhvalov
4c4ce93730 peer: fix panic during peer connection 2017-02-22 14:50:48 -08:00
bryanvu
b21bd351e8 fundingmanager: change funding messages to use server.sendToPeer
Previously, during the channel funding process, peers sent wire
messages using peer.queueMsg. By switching to server.sendToPeer, the
fundingManager is more resilient to network connection issues or system
restarts during the funding process. With server.sendToPeer, if a peer
gets disconnected, the daemon can attempt to reconnect and continue the
process using the peer’s public key ID.
2017-02-21 19:21:19 -08:00
Olaoluwa Osuntokun
2dfab8c6d7
routing+lnd: provide payment premiere as response to SendPayment 2017-02-21 01:43:48 -08:00
Olaoluwa Osuntokun
5e216b8bf9
peer: properly use block height when logging channel closure height 2017-02-21 01:43:42 -08:00
Olaoluwa Osuntokun
4a48b91e31
peer: update channel commitment updates to match spec
This commit modifies a peer’s htlcManager goroutine in order to
properly implement the new state machine defined by the specification.
The major change to this new state machine is that we can no longer
have a limited number of unrevoked commitment states. As a result, we
no longer need to track how many outsanding changes we have, and only
need to track if we have a pending change or not. This simplifies the
logic a bit.

Additionally, when receive a new signature we FIRST send an
RevokeAndAck, THEN we if we need to send a signature in response or
not. This is the major change to the state machine from the PoV of the
htlcManager. Previously, the order was flipped.
2017-02-21 01:43:21 -08:00
Andrey Samokhvalov
ae15a193e2 lnwire+features: transition to the user friendly list of features 2017-02-21 01:25:05 -08:00
Andrey Samokhvalov
6ce9ea29da server+peer: add 'init' message support
In this commit the support for global and local feature vectors were
added in 'server' and 'peer' structures respectively. Also with commit
additional logic was added and now node waits to receive 'init'
lnwire.Message before sending/responding on any other messages.
2017-02-17 13:27:29 +08:00
Olaoluwa Osuntokun
906c0451c8
peer: check for existence of channel when handling a remote close
This commit patches a bug in the code for handling a remote cooperative
channel closer. Previous if the region node didn’t know of the channel
which was being requested to close, then a panic would occur as the
entry read from the map would be nil.

To fix this bug, we now ensure that the channel exists before we
perform any actions on it. In a later commit which overhauls the
channel opening and closing to match that of the specification, this
logic will be modified to properly send an error message in response to
the failed channel closure.
2017-02-07 16:49:04 -08:00
Olaoluwa Osuntokun
8c059631df
peer+server: ensure the remote TCP connection is always closed 2017-02-06 15:05:07 -08:00
Olaoluwa Osuntokun
f4b403679b
lnwallet: remove BlockChainIO as a dependency to LightningChannel
This commit removes the BlockChainIO interface as a dependency to the
LightningChannel struct as the interface is no longer used within the
operation of the LightningChannel.
2017-02-02 17:05:40 -08:00
Olaoluwa Osuntokun
4eebc7c994
peer: refactor the queueHandler to aggressively drain queue
This commit refactors the queueHandler slightly to be more aggressive
when attempting to drain the pending message queue.

With this new logic the queueHandler will now attempt to _completely_
drain the pendingMsgs queue by sending it all to the writeHandler
_before_ attempting to accept new messages from the outside
sub-systems. The previous queueHandler was a bit more passive and would
result in messages sitting the the pendingMessage queue longer than
required.
2017-02-01 17:02:03 -08:00
Olaoluwa Osuntokun
6333dfea8f
peer: fix memory alignment for integers used atomically on 32-bit archs
This commit fixes a panic that can occur on 32-bit systems to the
misalignment of a int64/uint64 that’s used atomically using the atomic
package. To fix this issue, we now move all int64/unit64 variables that
are used atomically to the top of the struct in order to ensure
alignment.

Cleaning up some dead-code, satoshisSent/satoshisReceived have been
removed as they aren’t currently used. Instead those values are
accessed directly from the channel themselves.
2017-01-30 00:53:17 -08:00
Olaoluwa Osuntokun
3c5a23b2c1
peer: estimate RTT to peer using the ping and pong messages
This commit enhances the peer struct slightly be attempting to measure
the ping time to the remote node based on when we send a ping message
an dhow long it takes for us to receive a pong response.

The current method used to measure RTT is rather rough and could be
make much more accurate via the usage of an EMA/WMA and also via
attempting to measure processing time within the readMessage and
writeMessage functions.
2017-01-25 18:21:01 -08:00
Olaoluwa Osuntokun
9906e07087
peer: correct logging messages (to:writeMessage, from:readMessage) 2017-01-24 17:49:17 -08:00
Olaoluwa Osuntokun
019edc9035
peer: display the src peer when logging read error 2017-01-23 20:33:29 -08:00
Olaoluwa Osuntokun
97bb8744c4
peer: fix logging message when receiving updates for unknown channel
The previous logging message was broken as that target chanpoint was
being overshadowed by the local variable declaration. The new logging
message will properly print the unknown channel point as well as the
peer who sent the message.
2017-01-22 14:37:08 -08:00