This commit fixes a panic that would arise when the daemon attempts to
query for a channel that doesn’t currently exist. The bug was the
result of a typo which checked for the nil existence of the incorrect
variable.
This commit fixes a slight bug in the storage of the capacity of a
channel. Previously, we were subtracting a the hard coded fee amount
without first casting the integer to a btcutil.Amount which results in
a display/rounding error when the amount is converted to BTC.
This commit fixes a slight bug in the utxoNursery. Previously, if we
forced closed a channel that was solely funded by the other party
without pushing any satoshis, then the utxoNursery would attempt to
sweep a target output even though it didn’t actually exist. This would
result in the creation of a negative value’d output due to the hard
coded fees currently used in several areas.
To fix his, we now ignore any “output” with a value of zero, when
adding new outputs to the kindergarden bucket.
This commit implements the newly added RPC to decode payment requests
passed over the command line or directly via gRPC.
With this tool, users can now examine payment requests they see in the
wild for diagnostic or debugging purposes.
This commit is similar to the prior commit to channeldb: we no longer
assume that _both_ edges of a channel will always be advertised. Such
an assumption resulted in the inability for a node to sync graph state
since we were previously returning an error when _both_ edges weren’t
found within the graph database.
To remedy this bug, we now carefully ensure that if one edge doesn’t
exist, then we still sync the other.
This commit fixes a prior bug in the graph database due to an invalid
assumption that both channel edges would _always_ be advertised. This
assumption is invalid, as it’s up to a node’s policy if the advertise
their direction of the channel.
The fix for this assumption is straight forward: ErrEdgeNotFound is no
longer a critical error, instead a nil pointer will now be passed into
the passed callback function.
This commit adds a soft-limit for the minimum allowed channel size.
Without this limit a user may inadvertently create an invalid or
unspendable output due to the hard coded fees in a few areas of the
codebase.
This is a temporary measure, and will be removed once we add dynamic
fees into the mix.
This commit augments the server’s response to successful SendPayment
commands by also returning the full path taken in order to fulfill the
payment. With this information, the user now obtains more context about
their payment whcih can be useful when debugging, or just exploring the
capabilities of the daemon.
This commit fixes a prior bug in the wallet triggered by the creation
of a channel using the single funder workflow, but pushing exactly
*half* of the channel over to the other side. The prior logic to
determine who the initiator would result in a disagreement over who
created the channel initially. This wouldn’t manifest until the channel
was attempted to be closed cooperatively. As both side disagreed about
who created the channel they would apply the closing fee to different
outputs, thereby creating mismatched closing transaction. The signature
would fail to validate as the closer will create a different
transaction from that of the responder.
This commit fixes the issue by properly detecting who initially created
the channel.
This commit adds a new error type to the `lnwire` package:
`UnknownMessage`. With this error we can catch the particular case of a
an error during reading that encounters a new or unknown message. When
we encounter this message in the peer’s readHandler, we can now
gracefully handle it by just skipping to the next message rather than
closing out the section entirely.
This puts us a bit closer to the spec, but not exactly as it has an
additional constraint that we can only ignore a new message if it has
an odd type. In a future release, we’ll modify this code to match the
spec as written.
With this commit we now pin the version of lightning-onion we build
against at a particular build on the Sphinx package as the package will
be modified in order to accommodate for future changes in the spec.
This commit fixes a bug introduced by the past attempt to Make Logging
Great Again. Since we unset the curve parameters when reading/writing
the messages, if we have a lingering reference that’s active elsewhere
in the daemon, then we’ll modify that reference. To fix this, we now
explicitly set the Curve parameters in two areas.
A similar commit has been pushed to lightning-onion.
This commit fixes a slight bug in the interaction between the cli
program and the rpcsever itself. With this commit it’s now again
possible to create a channel with a peer that’s identified by its
peerID, instead of only the pubkey.
This commit moves the fetching of active channels from the
contractObserver goroutine up to the Start() method on the
breachArbiter. By doing this, we ensure that the user receives an error
(under the current set up) if the btcd node that lnd is connected to
doesn’t have their txindex enabled.
This commit modifies the closeObserver goroutine to ensure that a close
summary has been inserted into the database before signalling any
observers that a unilateral channel closure was detected. This fixes a
slight bug where a peer would force close a channel, but we wouldn’t
properly detect that and clean up the channel state if had a failed
cooperative channel closure.
This commit modifies the login of sent/recv’d wire messages in trace
mode in order utilize the more detailed, and automatically generated
logging statements using pure spew.Sdump.
In order to avoid the spammy messages due to spew printing the
btcec.S256() curve paramter within wire messages with public keys, we
introduce a new logging function to unset the curve paramter to it
isn’t printed in its entirety. To insure we don’t run into any panics
as a result of a nil pointer defense, we now copy the public keys
during the funding process so we don’t run into a panic due to
modifying a pointer to the same object.
This commit modifies the ListInvoice RPC to also return the encoded
payment request in the response. With this change it’ll be possible to
always obtain the encoded payment for any invoice, rather than only
being able to obtain it directly after the creation of an invoice.
This commit modifies the logic of the closeObserver slightly to not
incorrectly mark the broadcast of the commitment transaction triggered
by a cooperative channel closure as an unprompted broadcast.
