Commit Graph

1644 Commits

Author SHA1 Message Date
Olaoluwa Osuntokun
98fae7f329
lnd: properly disconnect peer and clean up resources after critical errors 2016-07-13 16:40:07 -07:00
Olaoluwa Osuntokun
5912322995
lnd: unregister to htlcSwitch with nil chanPoint deletes all inks for interface 2016-07-13 16:35:52 -07:00
Olaoluwa Osuntokun
b9c29ad9fc
lnd: consolidate peerManager and queryHandler 2016-07-13 16:34:27 -07:00
Olaoluwa Osuntokun
496d1e8edc
lnd: manually set sig pending bit in commitment state machine
This commit fixes a class of bug which would trigger a never ending
loop of “null” commitment updates between two peers.
2016-07-13 16:31:50 -07:00
Olaoluwa Osuntokun
2926988710
cmd/lncli: implement one-off HTLC payments 2016-07-12 17:47:30 -07:00
Olaoluwa Osuntokun
91509681df
lnd: implement bi-directional streaming SendPayment in rpcserver 2016-07-12 17:46:31 -07:00
Olaoluwa Osuntokun
88949e181a
lnd: implement per-channel state-machine driver within peer
With this commitment, the daemon is now able to properly send+redeem
single-hop HTLC’s with another daemon running on the same network.

The htlcManager gains an additional channel which is reads from
receiving updates from either downstream peers, or the rpc server. An
htlcManager is spawned for each active channel with the remote peer. As
a result, the readHandler must now de-multiplex any messages which
update a known channel to the proper htlcManager.

Batching HTLC add updates with a trickle timer has not yet been
implemented, but will be in the near future along with several other
optimizations.
2016-07-12 17:45:36 -07:00
Olaoluwa Osuntokun
af7cfd6c8b
lnd: add basic HtlcSwitch logic for forwarding L2 payments 2016-07-12 17:40:39 -07:00
Olaoluwa Osuntokun
9b29fa3a52
lnd: use channel barriers to synchronize on-chain events and a peer's readHandler 2016-07-12 17:38:14 -07:00
Olaoluwa Osuntokun
09f6ecef1f
lnrpc: add bi-directional streaming SendPayment RPC 2016-07-12 17:36:40 -07:00
Olaoluwa Osuntokun
7dea354711
lnwallet: properly handle HTLC settles in channel state-machine
We no longer track HTLC’s by their r-hash within the log into the
index, as we may have multiple HTLC’s that can be redeemed by the same
pre-image. Instead we now use a separate index which is keyed by a
log-index.

Additionally, the SettleHTLC method now also returns the index of the
HTLC being settled which allows the remote party to quickly locate the
HTLC within their log.

This commit also introduces a few trace/debug log messages which will
likely be pruned in the near future
2016-07-12 17:35:57 -07:00
Olaoluwa Osuntokun
06f062e678
lnwallet: sync revocation state after receiving a revocation 2016-07-12 17:32:42 -07:00
Olaoluwa Osuntokun
14d669dfd1
lnwallet: decrease initial revocation window to 4 2016-07-12 17:31:01 -07:00
Olaoluwa Osuntokun
56fb414767
channeldb: add method to sync revocation state to disk 2016-07-12 17:26:53 -07:00
Olaoluwa Osuntokun
e1d5878df4
lnd: introduce the InvoiceRegistry
This commit introduces the invoice registry which is a central
repository of all outstanding invoices related to the daemon.

This registry will be used by the goroutines which manage the htlc’s
for a particular channel, and later by the point-to-point workflow
which negotiates the conditions for payment along with signed recipes.
2016-07-12 17:14:16 -07:00
Olaoluwa Osuntokun
0b86c01067
lnwire: fix CommitSignature max payload length
This commit increase the max allowed payload length for the
CommitSignature method in order to account for the added 8 byte log
index.
2016-07-12 17:07:40 -07:00
Olaoluwa Osuntokun
c8de0924ba
lnwire: properly display channel points in .String() methods 2016-07-12 17:05:18 -07:00
Olaoluwa Osuntokun
9b5e487893
lndc: remove print debug print statements 2016-07-12 17:04:14 -07:00
Olaoluwa Osuntokun
850feed877
lnd: switch to nested a main function, fix defer execution
This commit adds a new nested main function “lndMain”, within the
packages’s normal main function. This nesting is required in order to
properly execute all queued defer statements in the case of a forced
exit.
2016-07-12 17:03:33 -07:00
Olaoluwa Osuntokun
48491a7fee
channeldb: fix commit key state corruption bug
This commit fixes a bug caused by overriding the prefix key for storing
commitment keys with the first few bytes of a channel’s channel point.

Once a channel was deleted, then all future channels would result in a
panic due to a nil pointer deference since the prefix key was mutated,
causing all future stores/gets to fail.
2016-07-12 17:00:08 -07:00
Olaoluwa Osuntokun
4548e4497d
lnd: set up messaging chans between peer and htlcSwitch
Each active channel now gains its a dedicated htlcManager goroutine
which currently accepts to two golang channels, and a lightning
channel. The “downstream” channel will be used for dispatched multi-hop
payments sent from the htlcSwitch, while the “upstream” channel will be
used once the readHandler de-multiplexes hltc add/timeout/settle
messages.

Each time a new channel is fully created after N confirmations, the
peer’s channelManager registers the new link with the htlcSwitch. Once
the channel is closed either cooperatively or non-cooperatively, then
the link is unregistered.
2016-07-09 16:41:54 -07:00
Olaoluwa Osuntokun
5fab6ea39e
lnd: redirect channel closure reqs from server to htlcSwitch 2016-07-09 16:36:31 -07:00
Olaoluwa Osuntokun
2dd662837e
lnd: introduce the HtlcSwitch service within daemon
This commit introduces the HtlcSwitch service into the daemon. The
purpose of the switch is to manage the message passing between the
goutiness within he peer managing each active channel. The switch
treats connected peers as interfaces, and their active channels as
links. All multi-hop, single-hop, and channel closure orchestration
will be managed by various goroutines within the HtlcSwitch.

The HtlcSwitch will also serve as the L2 contact point between the
yet-to-be-written LightningRouter and the switch, forwarding the new
htlc packet on the proper interface. Additionally, the switch will
handle dispatching htlc’s created locally via RPC, and multi-hop
forwarding initiated by peers.
2016-07-09 16:35:45 -07:00
Olaoluwa Osuntokun
4590364d04
channeldb: return nil for error if openChanBucket not created
This avoids an unnecessary panic in the case that the channeldb has
been wiped independently while a new peer connects.
2016-07-09 16:21:32 -07:00
Olaoluwa Osuntokun
40d9f0da31
cmd/lncli: implement pendingchannels for the cli client 2016-07-07 15:36:42 -07:00
Olaoluwa Osuntokun
a4e92fac8e
cmd/lncli: implement async+sync calls to [open|close]channel 2016-07-07 15:35:10 -07:00
Olaoluwa Osuntokun
07166fe88b
lnd: implement pendingchannels RPC
This commit implements the “pendingchannels” RPC within the rpcserver.
This RPC allows callers to receive details concerning the current
pending channels associated with the daemon. Pending channels are those
waiting for additional confirmations before they can be considered
opened/closed.

At the time of this commit, only open channels are shown. A future
commit will also add the confirmation updates, along with information
for close channels.
2016-07-07 15:33:58 -07:00
Olaoluwa Osuntokun
c0383679d2
lnd: use asynchronous streaming responses for [open|close]channel RPC's
This commit switches the implementation of the open/close channel RPC’s
from a fully blocking synchronous model to one that’s async by default,
allowing callers to add a sync wrapper.

The new proto specs also allow for “updates” for the pending channels
in the form of new confirmations which progress the pending status of
the channel. At this point, only the final open/close updates have been
implemented. Obtaining confirmation notifications requires a bit of
re-working within the current ChainNotifier interface, thus this has
been deferred to a later time.
2016-07-07 15:31:07 -07:00
Olaoluwa Osuntokun
dd9acfdd4d
lnrpc: add pendingchannels RPC call, regenerate protos 2016-07-07 15:24:58 -07:00
Olaoluwa Osuntokun
c7f49e19aa
lnrpc: make close/open channel into streaming RPC calls 2016-07-07 15:24:39 -07:00
Olaoluwa Osuntokun
4d7bd2eb5d
cmd/lncli: implement cli "getting" call 2016-07-05 18:58:49 -07:00
Olaoluwa Osuntokun
c5cc96a524
lnd: implement the getinfo RPC call 2016-07-05 18:57:14 -07:00
Olaoluwa Osuntokun
6ef6506c3d
cmd/lnshell: remove the now obsolete lnshell 2016-07-05 18:55:58 -07:00
Olaoluwa Osuntokun
630561326c
lnrpc: add initial basic getinfo RPC 2016-07-05 18:52:13 -07:00
Olaoluwa Osuntokun
2512fecf88
lnd: populate lightning id within server 2016-07-05 18:49:08 -07:00
Olaoluwa Osuntokun
94c242073a
lnwallet: finish initial draft of LightningChannel state machine
This commit finishes the initial draft of the commitment state machine.
A full re-write of the prior protocol which combines aspects of the
former ‘lnstate’ package has replaced the prior un-finished
stop-and-wait protocol.

This new protocol is designed to operate in an asynchronous environment
and to facilitate non-blocking batched and pipelined updates to the
committed channel states. The protocol is also de-synchronized meaning
that either side can propose new commitment states independent of the
actions of the other party.

The state machine implemented is very similar to that of c-lightning,
however we allow multiple unrevoked commentates in order to minimize
blocking, and also to reduce latency across several hops in a
bi-directional setting.

The current implementation consists of 3 main data structures: a
commitment chain which consist of unrevoked commitment transactions
(one for each side), and a (mostly) append-only log of HTLC updates
shared between both sides. New commitments proposed index into the log
denoting which updates they include, this allows both parties to
progress chains independent of one another. Revoked commitments, reduce
the length of the chain by one, and free up space within the revocation
window.

At this point only basic tests are in place for the state machine,
however more extensive testing infrastructure along with formal proofs
using PlusCall are planned.
2016-07-05 17:02:03 -07:00
Olaoluwa Osuntokun
8775107454
lnwallet: keep commitments cold at all times, store sig instead
This commit changes prior behavior which stored a “hot” commitment
transaction, meaning one which all the sigScript fully assembled and
able to be broadcast.

Instead, we now store the current signature for our commitment
transaction as a separate field within the database and within memory.
As a result, this eliminates a class of bugs which would erroneously
broadcast a fully loaded commitment transaction, either leading to a
loss of funds, or suspending availability to funds for a period of
time.
2016-07-05 16:55:47 -07:00
Olaoluwa Osuntokun
f03122e697
lnwallet: correct comment in revoke derivation explanation 2016-07-05 16:49:27 -07:00
Olaoluwa Osuntokun
1f7d9b6425
channeldb: also store their current revocation hash
We now also store their current revocation hash which is given to us
along with the revocation key once an initial HTLC is added to a
commitment transaction.
2016-07-05 16:48:31 -07:00
Olaoluwa Osuntokun
06af4b130f
channeldb: remove theirCommitTx, store latest commit sig 2016-07-05 16:44:52 -07:00
Olaoluwa Osuntokun
927db9cfd5
lnd: update the FundingManager to new revoke key funding workflow 2016-06-30 12:15:06 -07:00
Olaoluwa Osuntokun
2c187209eb
lnwallet: update internal wallet reservations to use revoke keys
This update the wallet to implement the new single funder workflow
which uses revocation keys rather than revocation hashes for the
commitment transactions.
2016-06-30 12:13:50 -07:00
Olaoluwa Osuntokun
1b490c52ed
lnwallet: createCommitTx now a revocation key 2016-06-30 12:12:19 -07:00
Olaoluwa Osuntokun
d85719b5a7
lnwallet: add elkrem root derivation function
The derivation is current bed on an HKDF invocation using our private
key as the secret, and the node’s channel multi-sig key as the salt.
This scheme allows us to derive the key on the fly given data known to
only us and the remote node.

The current derivation is just a place-holder and will be re-visited at
a later time.
2016-06-30 12:09:42 -07:00
Olaoluwa Osuntokun
78346c81e7
lnwallet: update reservation workflow to revoke keys
With this commit, the reservation workflow for the single funder use
case is now aware of the usage of revocation keys.

The changes are relatively minor:
  * contributions now have RevocationKeys instead of RevocationHashes
  * CompleteReservationSingle now takes the initiators revocation key
2016-06-30 12:02:51 -07:00
Olaoluwa Osuntokun
6dcefac868
lnwire: update CommitRevocation for revoke key scheme
With this commit a revocation message now carries 3 items:

  1. A pre-image revoking the lowest unrevoked commitment transaction
in the commitment chain.
  2. A new key which extends the current revocation window by 1. This
key is to be used for new commitment transactions.
  3. A new hash which also extends the current revocation window by 1.
This hash is to be used for new HTLC revocation hashes.
2016-06-30 11:59:46 -07:00
Olaoluwa Osuntokun
7c7ed5e638
lnwire: add a LogIndex field to CommitSignature
This commit updates the CommitSignature message to match the latest
version of the state-machine protocol. The log index specifies up to
which index in the receiver’s HTLC log the sender’s signature covers.
2016-06-30 11:58:39 -07:00
Olaoluwa Osuntokun
bba9b665ef
lnwire: all hashes within the protocol are now 32-bytes
We now enforce that the site of all revocation pre-images+hashes (used
for HTLC’s) are now 32-bytes.

Additionally, all payment pre-images are now required to be 32-bytes
not he wire. There also exists a Script level enforcement of the
payment pre-image size at a lower level.

This commit serves to unify the sizes of all hashes/pre-images across
the codebase.
2016-06-30 11:53:21 -07:00
Olaoluwa Osuntokun
fd02c1c1aa
lnwire: update single funder workflow to use revocation keys
This commit updates the messages sent during a single funder workflow
to utilize revocation keys rather than revocation hashes. This now
matches the latest updates to the commitment transaction.

The changes to the workflow are as follows:
  * the response message now carries the responder’s revocation key
  * the complete message now carries the initiator’s revocation key

Once the initiator receives the response message, it can construct both
versions of the commitment transaction as it now knows the responder’s
commitment key. The initiator then sends their initial revocation key
over to the responder allowing it to construct the commitment
transactions and give the initiator a sig for their version.
2016-06-30 11:50:27 -07:00
Olaoluwa Osuntokun
582b83ada3
channeldb: update channel state to revocation keys + new elkrem API
This commit updates the stored on-disk channel state to store a current
revocation key rather than a revocation hash. This change coincides
with the new commitment transaction format which uses revocation keys
rather than hashes.

Additionally, this commit updates the decoding/encoding of local+remote
elkrem trees to the latest changes in the elkrem API.
2016-06-30 11:40:12 -07:00