This commit fixes a possible dead lock when dispatching notifications
caused by the circular communication between the notificationDisptcher
thread and the main notification thread within the btcrpcclient.
Rather than potentially blocking for eternity on a blocking send,
notifications are now instantly handled by appending the notification
on an unbounded queue then launching a goroutine to signal the
dispatcher thread that a new item is available within the queue.
This commit removes the previous HTLC timeout in message in favor of a
HTLC cancel message. Within the protocol, a timeout message would never
be sent backwards along the route as in the case of an HTLC timeout
before/after the grace period, the course of action taken would be to
broadcast the current commitment transaction unilaterally on-chain.
This commit adds full support for multi-hop onion routed payments
within the daemon.
The switch has been greatly extended in order to gain the functionality
required to manage Sphinx payment circuits amongst active links. A
payment circuit is initiated when a link sends an HTLC add to the
downstream htlcSwitch it received from the upstream peer. The switch
then examines the parsed sphinx packet to set up the clear/settle ends
of the circuit. Created circuits can be re-used amongst HTLC payments
which share the same RHash.
All bandwidth updates within a link’s internal state are now managed
with atomic increments/decrements in order to avoid race conditions
amongst the two goroutines the switch currently uses.
Each channel’s htlcManager has also been extended to parse out the
next-hop contained within Sphinx packets, and construct a proper
htlcPkt such that the htlcSwitch can initiate then manage the payment
circuit.
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 modifies the sendpayment message slightly to indicate that
the —dest value should be a hex-encoded compressed public key. This
change is required to stream line the integration of onion routing into
the daemon.
This commit adds a new option to the send payment command. The new
option toggles usage of the debug HTLC R-Hash when sending the
described payment. This flag should be used in conjunction with lnd
nodes that have been started with the `—debughtlc` flag in order to
allow sending payments without first registering invoices.
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 extends the existing invoiceRegistry functionality to wrap
the on-disk invoices available via the channeldb with an in-memory
cache on invoices. Currently the in-memory cache is only reserved for
the storage of special “debug” invoices which all nodes are able to
settle immediately.
This commit adds a new invoice related method: FetchAllInvoices. This
method allows callers to query the state of all invoices currently
stored within the database. The method takes a toggle bit which
determines if only pending (unsettled) invoices should be returned, or
if they al should be.
This commit moves the location of the invoice counter key which is an
auto-incrementing primary key for all invoices. Rather than storing the counter
in the same top-level invoice bucket, the counter is now stored within the
invoiceIndex bucket. With this change, the top-level bucket can now cleanly be
scanned in a sequential manner to retrieve all invoices.
This commit uses the context package’s WithTimeout to ensure tests
which rely on asynchrony behaviors cannot block the execution of the
integration tests for ever. All tests which rely on async gRPC
notifications now perform a 3 way select: on the timeout channel
closure, an error, and the response itself.
Additionally some slight refactoring has taken place within the current
set of integration tests, eliminating some unneeded factory functions.
This commit adds the necessary database functionality required for a
high-level payment invoice workflow. Invoices can be added dealing the
requirements for fulfillment, looked by payment hash, and the finally
also settled by payment hash. For record keeping and the possibility of
reconciling future disputes, invoices are currently never deleted from
disk. Instead when an invoice is settled a bit is toggled indicating as
much.
The current invoiceManger within the daemon will be modified to use
this persistent invoice store, only storing certain “debug” invoices in
memory as dictated by a command line flag.
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 adds a basic test to exercise the scenario of forced
channel closure between to nodes with an existing channel open. The
test ensures that the latest commitment transaction it broadcast to the
chain and additionally that all time-locked outputs are sweeped with a
single transaction as soon as the inputs are mature enough.
This commit modifies the OpenChannel helper method within the
networkHarness to open the channel according to the destination node’s
global lighting ID rather than using a hard coded peer ID as before.
With this change the method is now much more general as the prior
temporary hack has been removed.
This commit modifies the prior funding workflow to account for fees
when creating the funding output. As a stop gap, the current fee for
the commitment transaction is now hard-coded at 5k satoshis. Once the
fee models are in place this should instead be some high multiple of
the current “average” fee rate within the network, continuing, the
proper fee should be adjusted from the commitment transaction has
outputs are added/removed.
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.
This commit introduces the utxoNursery. The duty of the utxoNursery is
to watch over CSV-locked immature outputs until they’ve fully matured.
An output is mature once both its sequence lock indicated by the CSV op
code within its output has become active. Once an output is mature the
nursery sweeps the outputs in batches into the source wallet.
The utxoNursery executes its duties once a commitment transaction has
been broadcast on-chain.
This commit introduces the concept of a manually initiated “force”
closer within the channel state machine. A force closure is a closure
initiated by a local subsystem which broadcasts the current commitment
state directly on-chain rather than attempting to cooperatively
negotiate a closure with the remote party.
A force closure returns a ForceCloseSummary which includes all the
details required for claiming all rightfully owned outputs within the
broadcast commitment transaction.
Additionally two new publicly exported channels are introduced, one
which is closed due a locally initiated force closure, and the other
which is closed once we detect that the remote party has executed a
unilateral closure by broadcasting their version of the commitment
transaction.
This commit slightly modifies btcwallet’s SignOutputRaw method to work
properly in the case that the pkScript of the output being spent isn’t
one of the template pkScripts (p2pkh, multi-sig, etc). Rather than
examining the address, we now attempt to find the private key which
matches the public key passed within the sign descriptor.
This commit adds multi-client support for confirmation notification of
the same transaction. Within the daemon there might be scenarios where
multiple goroutines are waiting for the same transaction to be
confirmed in order to properly fulfill their tasks. Previously if
multiple clients were registered for the same txid confirmation
notification, then only the client who registered last would receive
the notification.
This commit adds full persistence logic of the current lowest
un-revoked height within each commitment chain. The newly added
channeldb methods for record state transitions within both commitment
chains are now utilized. This un-settled HTLC state is now read upon
initialization, with the proper log entries inserted into the state
update log which reflect the garbage collected log right before the
restart.
A new set of tests have been added to exercise a few edge cases around
HTLC persistence to ensure the in-memory log is properly restored based
on the on-disk snapshot.
This commit splits the previously added RecordChannelDelta method into
two distinct methods: UpdateCommitment and AppendToRevocationLog. The
former method is to be used once the local party revokes their current
commitment, and the latter method to be used once the remote party
revokes their current commitment.
With the addition of the UpdateCommitment method, the active HTLC’s
from the local node’s point of view are now persisted to disk.
Snapshots returned by the channel now also includes the current set of
active HTLC’s. In order to maintain thread safety the channels mutex is
now grabbed within methods which modify/read state but don’t do so
solely via a boltDB transaction.
The tests have been updated to account for the storage of HTLC’s needed
in order to assert proper behavior.
This commit removes the revocation hash/keys from the channel deltas.
In the case of an uncooperative closure, we can efficiently re-generate
the proper elkrem pre-image so this storage was completely unnecessary
