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.
This commit changes the listinvoices and lookupinvoice endpoints to
avoid collisions when making requests.
We can still retrieve a list of pending invoices with `listinvoices` by
appending the parameter `pending_only=true` to the request URL.
This commit causes the configuration parser to accept the values of
RPCUser, RPCPass, and (for the bitcoind back-end) ZMQPath configured
in lnd.conf or on the command line ONLY when all are specified. It
causes the configuration parser to look in btcd.conf or bitcoin.conf
ONLY when none are specified, and causes an error to be returned when
only some are specified, as users have done so erroneously and the
lack of clear feedback has caused difficulties.
This commit alters the restart logic in the nursery
to load channel close summaries from disk when
restarting the process of sweeping commit txns.
The channel close summary contains a closing height,
which is used to set the lower bound of the height hint
when resubscribing to spend notifications.
This commit adds a FetchClosedChannel method to the
channeldb, which allows querying based on a known
channel point. This will be used in the nursery to
load channel close summaries, which can be used to
provide more accurate height hints when recovering
from failures.
In this commit, we update all the references to
btcwallet+neutrino+gozmq included in the current build. We do this as a
number of bugs related to the bitcoind backend have been fixed.
This commit uses the multimutex.Mutex to esure database
state stays consistent when handling an announcement, by
restricting access to one goroutine per channel ID.
This fixes a bug where the goroutine would read the
database, make some decisions based on what was read,
then write its data to the database, but the read data
would be outdated at this point. For instance, an
AuthProof could have been added between reading the
database and when the decision whether to announce
the channel is made, making it not announce it.
Similarly, when receiving the AuthProof, the edge
policy could be added between reading the edge state
and adding the proof to the database, also resulting
in the edge not being announced.
This commit fixes a bug that could cause annoucements
to get lost, and resultet in flaky integration tests.
After a set of announcements was broadcastet, we would
reset (clear) the announcement batch, making any
annoucement that was added between the call to Emit()
and Reset() to be deleted, without ever being broadcast.
We can just remove the Reset() call, as the batch will
actually be reset within the call to Emit(), making
the previous call only delete those messages we hadn't
sent yet.
This commit aims to reduce the contention on the server's primary
mutex by (1) replacing it with a RWMutex, and (2) not holding an
exclusive lock throughout the duration of the SendToPeer method.
For the latter, we now only have to hold a shared lock until all
messages have been queued, where as before an exclusive lock
was held until all messages had been acknowledged by the target
peer's write handler. Since the initial syncing of announcements
with peer now comprises a couple thousand messages on testnet,
these changes should help keep the server from deadlocking while
completing and long-lived syncing operations.
In this commit, we fix an existing flake on Travis related to the new
set of on-chain HTLC tests. In this timing flake, Bob would broadcast
his sweeping transaction, but *mid block mining*. As a result, the
output would never be properly swept, needing an additional block to be
mined. We’ll now wait for both Bob’s sweeping transaction, and Carol’s
sweep transaction to be confirmed before we attempt our assertions.
In this commit, we fix an existing bug in the implementation of the
resolution of the htlcOutgoingContestResolver. Before this commit, we
would _always_ watch the claim outpoint. However, if this is on the
remote party’s commitment transaction, then we would end up watching
the wrong output. We’ll now properly detect this by modifying which
output we watch, based on if we have a second level transaction or not.
