In this commit, we fix an existing bug that would result in some
payments getting “stuck”. This would happen if one side restarted
before the channel was fully locked in. In this case, since upon
re-connection, the link will get added to the switch with a *short
channel ID of zero*. If A then tries to make a multi-hop payment
through B, B will fail to forward the payment, as it’ll mistakenly
think that the payment originated from a local-subsystem as the channel
ID is zero. A short channel ID of zero is used to map local payments
back to their caller.
With fix this by allowing the funding manager to dynamically update the
short channel ID of a link after it discovers the short channel ID.
In this commit, we fix a second instance of reported “stuck” payments
by users.
In this commit, we fix an existing bug within the funding manager. A
channel barrier only needs to be create if upon startup the channel is
still pending. Otherwise, we’ll re-create the funding barrier
unnecessarily. This can lead to bugs when initiating payments between a
channels’ lock in and when it’s announced to the together network. If
during this period, a user attempts a payment, then the response won’t
be archived, as the grouting will be blocked waiting on the channel
barrier to close.
To fix this, we only re-create the barrier if the channel hasn’t been
confirmed.
This eliminates one source of reported “stuck payments”.
In this commit, we remove a server shutdown statement that was executed
after we obtained the wallet’s password from the user over RPC. This
was unnecessary as we already close the listener below. Before this
commit, users would see a weird benign error message. With these code
deletion, the message disappears.
This commit updates the tests for checking a links Bandwidth()
calculation, after the change that made us use the remoteACKedIndex
instead of the logIndex when calculating it. The main result of this
change is that we never consider incoming updates before they are
acked, when calculating the bandwidth. This is because this was
inconsistent with the state we actually end up signing later on.
This commit adds a test that trigger a case where the balance
could end up being negative when we used the logIndex when
calculating the channel's available balance. This could
happen when the logs got out of sync, and we would use
the balance from a settled HTLC even though we wouldn't
include it when signing the next state.
This commit introduces a new Ticker interface, that can be used
to control when the batch timer should tick. This is done to be
able to more easily control the ticker during tests. The batch
timer is wrapped in the new BatchTicker struct, and made part
of the config together with BatchSize.
In this commit, we fix an issue that was recently introduced to the way
we handle historical dispatches for the neutrino notifier. In a recent
change, we no return an error if we’re unable to actually find the
transaction that spends an outpoint. If this is the case, then the
outpoint is actually unspent, and we should proceed as normal.
This commit reworks the macaroon authentication framework to use the
v2 macaroon format and bakery API. It also replaces the code in each
RPC method which calls the macaroon verifier with interceptors which
call the macaroon verifier instead. In addition, the operation
permissions are reworked to fit the new format of "allow" commands
(specifically, entity/operation permissions instead of method
permissions).
Appendix C of BOLT 03 contains a series of test vectors asserting that
commitment, HTLC success, and HTLC timeout transactions are created
correctly. Here the test cases are transcribed to Go structs and
verified.
We also break out some logic need to tests that bypass the constructor
and remove some redundant fields.
Before this commit, if the remaining change was small enough, then it
was possible for us to generate a non-std funding transaction. This is
an issue as the txn would fail to propagate, meaning funds could
potentially be stuck in limbo if users didn't manually drop their
transaction history.
To avoid this scenario, we won't create a change output that is dusty.
Instead, we'll add these as miner fees.
Fixes#690.
In this commit, we modify the logic executed when we decide that we
need to fail a funding flow. Before this commit, if the remote party
disconnected while we were attempting to fail the funding flow with an
error. Then we'd never actually cancel the reservation. This meant that
any inputs selected for that transaction would be locked until a
restart.
We fix this issue by always cancelling the reservation first, and
ensuring that failure to cancel the reservation doesn't prevent us from
sending the error.
Partially addresses #710.
It seems that at some point the installation docs of the
https://github.com/lightninglabs/lightning-dev-site/ was identical to
this file (without page navigation + next steps).
Seems that this commit did not get ported to this repo:
1ad7d3189d
In this PR the info for macaroons and noencryptwallet is copied over
from the above mentioned commit.
In this commit, we add an additional constraint to the RPC
configuration parsing. Before this commit, it was possible to start lnd
with either RPC server listening on an external interface *without*
authentication disabled. After this commit, if a user tries to start
the RPC server listening on an external interface without any sort of
RPC authentication, then the daemon will fail to start up.
In order to reduce high CPU utilization during the initial network view
sync, we slash down the total number of active in-flight jobs that can
be launched.
A recent commit modified the mutex in the server to the read/write. In
order to further reduce contention, we’ll grab the read lock when we’re
examining get set of peers to ignore.
Before this commit, we’d unnecessarily use a write transaction within
the FetchChannelEdgesByOutpoint. This is wasteful as the function only
actually reads items from the database, and doesn’t attempt any
mutations at all.
In this commit, we fix a race condition related to the way we attempt
to query to see if an outpoint has already been spent by the time it’s
registered within the ChainNotifier. If the transaction creating the
outpoint hasn’t made it into the mempool by the time we execute the
GetTxOut call, then we’ll attempt to query for the transaction itself.
In this case, if we query for the transaction, then the block hash
field will be empty as it hasn’t yet made it into a block. Under the
previous logic, we’d then attempt to force a rescan. This is an issue
as the forced rescan will fail since it’ll try to fetch the block hash
of all zeroes.
In this commit, we fix this issue by only entering this “fallback to
rescan” logic iff, the transaction has actually been mined.
This adds a test of encryption/decryption of 1002 copies
of a message "hello" so as to test the test vectors in the
final section of BOLT 8 ("transport-message test").
It also corrects some typos in the preceding section of the
same function (TestBolt0008TestVectors).
Since a ChannelPoint's funding txid can now be get/set as raw bytes or
a string, we first need to check what type it's currently set to before
accessing it.
Fixes#481.
Prior to this commit, payments stored in the channel DB only kept a
record of the payment hash. This is a problem as the preimage is what
serves as proof of payment and a user should be able to look up this
value in the future (not just immediately after payment).
Instead of storing both the payment hash and the preimage, we store the
preimage only since the hash can be derrived from this using a SHA256.
In the RPC listpayments command, we now give the preimage in addition to
the payment hash.
