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.
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
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This update the wallet to implement the new single funder workflow
which uses revocation keys rather than revocation hashes for the
commitment transactions.
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.
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
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.
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.
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.
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.
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.
As noted in the comment on the method, this serialization method isn’t
strictly necessary assuming the root is derived via a cryptographically
secure, yet deterministic procedure. The method is supplied only for
convenience.
