In order to prevent information leaks by nodes probing with a payment
hash, this commit changes exit hop processing so that it always returns
incorrect_or_unknown_payment_details and leaves the prober in the dark
about whether an invoice actually exists.
Align naming better with the lightning spec. Not the full name of the
failure (FailIncorrectOrUnknownPaymentDetails) is used, because this
would cause too many long lines in the code.
This commit fixes a bug in DTUint16 and DTUint32, which would cause them
to read too many bytes from the reader. This is due to the fact that
ReadFull was being called on a slice that could be greater than the
underlying type. This is not an issue for DTUint64, since the 8-byte
buffer corresponds to the maximum possible size of a uint64. The
solution is to clamp the buffer to 2 and 4 bytes respectively.
A series of tests are also added to exercise these cases.
This commit adds the truncated integer encodings used in the
variable-size onion payloads. The amount and cltv delta both use the
truncated encoding to shave bytes in the overall size, and will likely
be used in the future for additional extensions where size is a
constraint.
This commit adds concrete encoding methods for primitive integral types.
When external libs need to create custom encoders, this allows them to
do so without incurring an extra allocation on the heap. Previously, the
need to pass a pointer to the integer using an interface{} would cause
the argument to escape, which we avoid by having them copied directly.
This varint has the same serialization as the varint in btcd and
bitcoind, but has different behavior wrt returned errors. In order to
ensure the inner loop properly detects cleanly written records,
ReadVarInt will not only return EOF if it can't read the first byte, as
that means the reader has zero bytes left.
It also modifies the API to allow the caller to provided a static byte
array, which can be reused across all encoding and decoding and
increases performance.
Not all errors that occur when serving client requests in the gRPC
server are logged. As a result, at times, we can be lacking critic
information that can be used to debug issues that pop up. With this PR,
we create a basic streaming+unary interceptor that will log all errors
that occur when servicing calls.
The current format looks something like this in the logs when an error
occurs:
```
[ERR] RPCS: [/lnrpc.Lightning/SendCoins]: decoded address is of unknown format
```
This ensures that the graph synced status is marked true at some point
once a historical sync has completed. Before this commit, a stalled
historical sync could cause us to never mark the graph as synced.
Some time ago, we modified `lncli` to accept larger responses from the
server, up to 50MB. However, we failed to update the REST proxy, which
is in a sense, a client to the regular RPC server. As a result, users
can't currently hit the `/v1/graph` endpoint, as it'll fail with an
error.
In this PR, we update the proxy's dial options to allow it to receive
larger responses from the actual gRPC server. This is only a temporary
measure however, as we'll eventually want to expose some sort of
pagination for the end client.
In this commit, we update the link to the security PGP key to a gist. We
do this as recent DoS attacks against popular keservers have rendered
many of them unresponsive or only partially operating. As a temporary
measure, we link to a gist until an alternative solution is found.
This commit adds the ignore-historical-filters CLI option, initially
defaulting to false. Users may use this option to prevent lnd from doing
historical gossip dumps to peers that set their `gossip_timestamp_range`
in the past. Enabling this option will result in lower bandwidth and
memory consumption. Down the road the plan is to make this default to
true.
With the introduction of the WatchtowerClient RPC subserver, the lnd
configuration flag to specify private watchtowers for the client is no
longer needed and can lead to confusion upon users. Therefore, we remove
the flag completely, and only rely on the watchtower client being active
through a new --wtclient.active flag.
We do this as a convenience for WatchtowerClient users so that they do
not need to re-add towers upon restarts. We ensure not to re-add towers
that have been previously removed by determining whether it has any
lingering active sessions.
