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.
This commit fixes a bug in the htlcSwitch’s logic to unregister links
after a peer has signaled that a channel has been closed. This bug
would arise when multiple channels were opened with a single peer, and
any of the channels were attempted to be closed. The cause of the bug
was that the slice reference within the map wasn’t previously updated
with the re-slicing to truncate the (duplicated, unneeded) element from
the slice. By updating the map’s reference directly, we fix this
behavior.
The safe handling of adding/removing links/interfaces between the
htlcSwitch’s two goroutines has sprawled a bit, and can be hard to
follow due to the map usage. In the future this section of the code
will be cleaned up and the redundant indexes removed.
This commit consists of a mass variable renaming to call the pkScript being executed for segwit outputs the `witnessScript` instead of `redeemScript`. The latter naming convention is generally considered to be reserved for the context of BIP 16 execution. With segwit to be deployed soon, we should be using the correct terminology uniformly through the codebase.
In addition some minor typos throughout the codebase has been fixed.
This commit fixes a build error for go 1.6.3. Before go 1.7, the
context package was under the experimental go packages, therefore to
maintain compatibility across our currently supported versions, we must
use the ‘/x/net’ import path.
This commit adds a few workarounds in order to concurrently support the
REST proxy as well as the regular gRPC interface. Additionally,
concrete support for the following RPC calls has been added:
GetTransactions, SubscriptTransactions, SubscribeInvoices, and
NewWitnessAddress.
This commit adds a REST interface to the existing gRPC server by
employing a simple http proxy auto-generated from the existing protobuf
files. Currently full-support for any streaming RPC’s are currently
untested. In addition to auto-generating a REST proxy server, a
swagger.json is also generated which allows for gRPC-like native
objects with higher-level clients, and also for auto-generated
documentation.
Due to limitations with accepting raw byte strings as parameters, some
RPC’s have been modified to take both raw-bytes and string arguments.
Additionally a new RPC has been added ‘NewWitnessAddress’ since the
proxy doesn’t currently support enum-based arguments.
Currently the proxy server is embedded within the daemon as an active
HTTP server, however we may want to package the proxy server as a
separate binary in the future. Similarly, we may want to add additional
configuration information which controls the optional inclusion of the
REST proxy.
Atm, just like the current gRPC interface, the REST API is fully
unauthenticated. Before moving to an initial alpha release after making
the necessary changes to meet the spec drafted in Milan, authentication
of the RPC interfaces will be addressed.
This commit returns the BtcWallet wrapper struct back to conformance to
the WalletController interface by adding support for
SubscribeTransactions.
The implementation of the lnwallet.TransactionSubscription consists
simply of a proxy goroutine which forwards notifications from the
wallet’s internal NotificaitonServer.
This commit adds a new simple interface related to the WalletController
which allows for subscribing to new notifications as transactions
relevant to the wallet are seen on at the network and/or mined. The
TransactionSubscription interface will prove useful for building higher
level UI’s on-top of the daemon which update the presentation layer in
response to received notifications.
This commit implements the new ListTransactionDetails method within
btcwallet’s concrete implementation of the WalletController interface.
Both mined and unmined transactions are currently returned via the same
method. Unmined transactions are indicated by their lack of an
inclusion block hash and lack of confirmations.
This commit adds the ability for clients within the daemon to register
for notifications that are dispatched once invoices are settled, or new
invoices are added. Such notifications can prove useful when
synchronizing higher level primitives, or implementing workflow within
desktop/mobile UI’s.
This commit adds an additional clause to the update of the current
commitment state each time the commitTimer ticks. We now additional
check to see if we have any active HTLC’s to settle, triggering a state
update if so.
This case is needed due to the possibility of desynchronization across
commitment transactions. As an example if any HTLC adds are sent after
the remote node receives our ack-sig, then they may remain uncommitted
within our local commitment chain. The addition of this check solves
the issue by ensuring convergence towards a symmetric commitment state.
This commit properly removes any/all closed channels from the routing
table. In the current implementation individual links (channels)
between nodes are treated sparely from the PoV of the routing table. In
the future, this behavior should be modified such that, the routing
table views all the links between nodes as a single channel. Such a
change will simplify the task of path finding as the links can simply
be viewed as a channel with the sum of their capacities. The link layer
(htlcSwitch) will handle the details of fragmentation on a local basis.
