This commit expands the data returned by the current GetCurrentHeight
to also return the current best block hash, expanding the method into
GetBestBlock. Additionally, the current best BlockHash is also now
displayed within the GetInfo RPC call.
Go-fmt files. Refactored code according to the guidelines.
Enhanced payment test: add error checking
and individual context for each API call.
Add Timestamp field to payment struct.
This commit introduces a new sub-system into the daemon whose job it is
to vigilantly watch for any potential channel breaches throughout the
up-time of the daemon. The logic which was moved from the utxoNursery
in a prior commit now resides within the breachArbiter.
Upon start-up the breachArbiter will query the database for all active
channels, launching a goroutine for each channel in order to be able to
take action if a channel breach is detected. The breachArbiter is also
responsible for notifying the htlcSwitch about channel breaches in
order to black-list the breached linked during any multi-hop forwarding
decisions.
Use [33]byte for graph vertex representation.
Delete unneeded stuff:
1. DeepEqual for graph comparison
2. EdgePath
3. 2-thread BFS
4. Table transfer messages and neighborhood radius
5. Beacons
Refactor:
1. Change ID to Vertex
2. Test use table driven approach
3. Add comments
4. Make graph internal representation private
5. Use wire.OutPoint as EdgeId
6. Decouple routing messages from routing implementation
7. Delete Async methods
8. Delete unneeded channels and priority buffer from manager
9. Delete unneeded interfaces in internal graph realisation
10. Renamed ID to Vertex
This commit modifies the ChannelBalance RPC to fetch the balance from
disk since channels are now able to efficiently retrieved from disk due
to recent index that have been added. Previously this RPC would only
return accurate information if we had an active connection to the
counter party for each channel.
This RPC implements the two new RPC methods added in a prior commit.
This involved a slight refactoring to make use of duplicated code
amongst the sync and async variants of the methods.
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 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 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 modifies the on-disk storage of invoices to stop the
optional fields (memo+receipt) on-disk as variable length byte arrays.
This change saves space as the optional fields now only take up as much
space as is strictly needed, rather than always being padded out to max
size (1KB).
This commit modifies the sendpayment command slightly to use the pub
key of the *first* hop within the route as the destination within the
htlcPacket sent to the htlcSwitch.
Previously, since only single hop was implemented, the final
destination would be set within the htlcPkt, causing the route to fail
as the switch doesn’t have a direct link to the dest in the multi-hop
case.
This commit alters the send/receive HTLC pipe line a bit in order to
fully integrate onion routing into the daemon.
The server now stores the global Sphinx router which all active
htlcManagers will used when processing upstream HTLC add messages.
Currently the onion routing private key is static, and identical to the
node’s current identity public key. In the future this key will be
rotated daily the node based on the current block hash.
When sending a payment via the SendPayment RPC, the routing manager is
now queried for the existence of a route before the payment request is
sent to the HTLC switch. If a path is found, then a Sphinx onion packet
encoding the route is created, then populated within the HTLC add
message.
Finally, when processing an upstream HTLC add request, the sphinx
packet is decoded, then processed by the target peer. If the peer is
indicated as the exit node, then the HTLC is queue’d to be settled
within the next state update.
This commit adds a new configuration parameter to the deamon:
‘DebugHTLC’. When true, all outgoing HTLC’s sent via the RPC interface
will be sent paying to a special rHash value which all lnd nodes also
with the flag activated know the preimage to. Therefore all payments
sent to a 1-hop node will immediately be settled by that node.
By default, this flag is false, it it only intended to be used to
exercise local changes to 1-hop behavior manually.
This commit adds a new RPC command: `channelbalance` which returns the
sum of all available channel capacity across all open channels. The
total balance is currently returned in units of `satoshis`. Additionally
the `networkHarness` has been modified slightly to allow specifying the
additional "extra" command line parameters when creating the initial
seed nodes. Minor refactoring within the integration tests has been
undertaken in order to increase code re-use across tests.
Closes#29.
This commit includes some slight refactoring to properly execute force
closures which are initiated by RPC clients.
The CloseLink method within the htlcSwitch has been extended to take an
additional parameter which indicates if the link should be closed
forcefully. If so, then the channelManager which dispatches the request
executes a force closure using the target channel state machine. Once
the closing transaction has been broadcast, the summary is sent to the
utxoNursery so the outputs can be swept once they’re mature.
LIGHT-131, LIGHT-140, LIGHT-138
`lncli showroutingtable` may output routing table as image.
Use graphviz for graph rendering.
Add explicit version dependency for tools. Add error checking.
LIGHT-133, LIGHT-138 Make output of `lncli showrouting table` in
two different formats: table and json.
Instead of sending serialized routing table send list of channels.
This commit adds a new feature to the network harness enabling callers
to receive async notifications once a particular transaction is seen on
the network. Such a feature is useful when due to the asynchronous
behavior of node communications.
With this new feature, tests can now wait for a particular transaction
to be seen within the network before proceeding.
This commit modifies the internal workflow for opening or closing a
channel in order to create a path in which RPC clients can receive
updates. Updates are now communicated via channels from the goroutines
spawned by the RPC server to process the request, and the sub-system
within the daemon that actually executes the request.
With this change clients can now receive updates that the request is
pending (final message has been sent to the target client), or that the
request has been completed. Confirmation related updates have not yet
been implemented as that will require some changes to the ChainNotifier
interface.
This commit integrates BitFury's current routing functionality into lnd. The
primary ochestration point for the routing sub-system in the routingMgr. The
routingMgr manages all persistent and volatile state related to routing within
the network.
Newly opened channels, either when the initiator or responder are inserted into
the routing table once the channel is fully open. Once new links are inserted
the routingMgr can then perform path selection in order to locate an "optimal"
path to a target destination.
With this commit, support for changing the target network (testnet,
simnet, etc) has been finalized. Previously a command line option was
present to swap networks, but the RPC port wouldn’t automatically be
updated to reflect the network.
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.
