This commit adds a document which outlines some of the traits desired
in future contributions to the daemon. It’s my hope that this document
will allow new contributors to quickly get up to speed on what is
desired in new contributions, possibly directly speeding up review
times.
This commit implements message chunking within the implementation of
net.Conn which implements our initial handshake, then uses the crypto
to read/write messages.
With this change it’s now possible to send message larger than 65535
bytes over a p2p crypto connection by properly chunking the messages on
the side of the connection that’s writing.
This commit modifies the current implementation of the p2p crypto
protocol to further constrain the max allowed payload size. With this
change we now use 16-bits (2-bytes) for the maximum payload length.
This change puts us closer to strict adherence of the Noise spec, and
simplifies the memory management w.r.t implementing the current version
of our scheme.
Note that this doesn’t restrict the size of messages that are able to
be sent over the wire within the LN p2p protocol. Larger message can
safely be encapsulated within the crypt messages via fragmentation that
will detected take place if a larger message is detected.
This commit modifies lnwire.NetAddress by adding a .Network() method.
With this added method the struct now implements the net.Addr interface
meaning that it can now be transparently passed into any context where
a net.Addr is requested.
This change paves the way to integration of btcd’s new connmgr into the
daemon to handle establishing persistent connections to all channel
counter parties.
This commit modifies both the Sphinx packet generation and processing
for recent updates to the API.
With the version 1 Sphinx specification, the payment hash is now
included in the MACs in order to thwart any potential replay attacks.
As a result, any attempts to replay previous HTLC packets MUST re-use
the same payment hash, meaning that the first-hop node can simply
settle the HTLC immediately, thwarting the attacker.
Additionally, within the Sphinx packet, each hop now gets a per-hop
payload which contains the necessary details (CTLV value, fee, etc) for
the node to successfully forward the payment. This per-hop payload is
protected by a packet-wide MAC.
This commit modifies the existing p2p connection authentication and
encryption scheme to now use the newly designed ‘brontide’
authenticated key agreement scheme for all connections.
Additionally, within the daemon lnwire.NetAddress is now used within
all peers which encapsulates host information, a node’s identity public
key relevant services, and supported bitcoin nets.
This commit modifies a few of the RPC call which previously took a
lightning_id as their paramter to instead take a compressed public key
field. With this change must of the code within the daemon can be
simplified as we only use public keys everywhere throuhgout the daemon.
Signed-off-by: Olaoluwa Osuntokun <laolu32@gmail.com>
This commit takes advantage of the newly added
channeldb.FetchAllChannels method to return the state of all active
channels for the ListChannels RPC command. With this change the state
of all channels can now be queried regardless of if any/all the peers
are currently online.
In a future modification a bit will be added to the channel information
which indicates if the LinkNode the channel was created with is
currently online or not.
This commit modifies the server-side handling of the streaming
SendPayment RPC to launch a new goroutine which is dedicated to reading
new requests from the client from the bi-directional stream. This
modification decouples error handling from stream reading allowing
errors to be returned to the client as the arise rather than after the
next payment has been sent.
This commit modifies the existing channel reservation workflow slightly
to thread through the IP address that we were able to reach the node
at, or the one which the node reached us via. Additionally, rather than
using OpenChannel.FullSync() at the end of the reservation workflow, we
now use OpenChannel.FullSyncWithAddr() in order to create the
relationship in the database between the channel, and the p2p node we
created the channel with.
All tests, as well as a portion of the fundingManager have been updated
accordingly,
This commit introduces a new method to channeldb: ‘FetchAllChannels’.
This method can be used to obtain the state of all active (currently
open) channels within the database. This method can be used for compute
basic channel-based metrics or exposed as an RPC in order to allow
clients to display/query channel data.
This commit adds a new method ‘FullSyncWithAddr’ which is identical to
the existing ‘FullSync’ method other than it also creates an
association from the channel to a LinkNode object within the database.
This new method is required in order to create persistent links between
channels and link nodes which will later allow the development of
heuristics which decided when it “makes sense” to close a channel due
to inactivity. Additionally, this new association will allow for a
sub-system within the daemon to attempt to establish persistent
connections out to all LinkNodes in order to strive for channel
availability.
This commit modifies the lnwallet code and related tests in order to
adhere to the recent field-name change to channeldb.OpenChannel.
Instead of having the field ‘TheirLNID’ which is the sha256 of the
node’s public key, we now instead use the public key directly in all
contexts.
This commit slightly modifies the existing structure of the channeldb
scheme to replace the former concept of a “nodeID” with simply the
compressed public key of the remote node. This change paves the way for
adding useful indexes mapping a node to all it’s active channels and
the other way around.
Additionally, the current channeldb code was written before it was
agreed by many of those implementing Lightning that a node’s ID will
simply be its compressed public key.
This commit adds a new bucket to the database which is dedicated to
storing data pertaining to p2p related reachability for direct channel
counter parties. The data stored in this new bucket can be used within
heuristics when deciding to unilaterally close a channel due to
inactivity. Additionally, all known reachable IP addresses for a
particular LinkNode are to be stored and updated within the database in
order to facilitate the establishment of persistent connections to
direct channel counter parties.
This commit fixes a panic bug caused by two calls to a process’
cmd.Wait() method. If two nodes incurred a fatal error as soon as they
were created, then both the goroutine detected to recovering the stderr
data and the defer statement would case a double channel close due to
the simultaneous calls to Wait().
This commit slightly modifies the existing CT struct in order to
maintain consistency with code-style. As a result of the name change,
all references have also been renamed from `ct` to `t`.
The Error and Errorf methods have been removed in favor of forcing
everything to be reported via `Fatalf`. Additionally a new method
(ProcessErrors) has been introduced to the networkHarness class in
order to encapsulate the underlying channel.
This commit fixes a bug which was introduced when the routing table was
switched over to store full pub keys rather then public key hashes. The
switch was change was required in order to properly support onion
routing within the daemon. During the change the source node vertex
when receiving a message wasn’t converted to use public keys instead of
pubkeyhashes. As a result, nodes would be blind to any topology related
updates sent by its neighbors.
This commit fixes the bug by setting the source node of the received
message to the serialized public key rather than the pubkeyhash.
This commit introduces Brontide: an authenticated key agreement
protocol in three acts. Brontide is the successor to lndc within lnd,
and ultimately within the greater Lighting Network. Brontide uses the
Noise_XK handshake for initial key agreement, then implements an AEAD
scheme which encrypts+authenticates both packets, and the lengths of
the packets on the wire. The initial authentication handshake preserves
the responder’s identity by never transmitting it to the initiator and
performing mutual authentication via an incremental Triple-DH based on
ECDH of secp256k1 and an HKDF which uses SHA-256.
Bronzed isn’t yet integrated within the wider daemon yet. Full
integration will land in a future pull request.
