The docker image have been updated so we are using another protobuf
version to generate the files. The generate files include the version of
the compiler used to creating them, so we need this commit to pass the
`rpc-check` step in our CI.
In this commit, we update the Sig type to support ECDSA and schnorr
signatures. We need to do this as the HTLC signatures will become
schnorr sigs for taproot channels. The current spec draft opts to
overload this field since both the sigs are actually 64 bytes in length.
The only consideration with this move is that callers need to "coerce" a
sig to the proper type if they need schnorr signatures.
We make the capacity factor configurable via an lnd.conf routerrpc
apriori parameter. The capacity factor trades off increased success
probability with a reduced set of channel candidates, which may lead to
increased fees. To let users choose whether the factor is active or not,
we add a config setting where a capacity fraction of 1.0 disables the
factor. We limit the capacity fraction to values between 0.75 and 1.0.
Lower values may discard too many channels.
The active probability estimator can be switched dynamically using the
`Set/GetMissionControl` API, maintaining backward compatibility. The
lncli commands `setmccfg` and `getmccfg` are updated around this
functionality. Note that deprecated configuration parameters were
removed from the commands.
We use a more general `Estimator` interface for probability estimation
in missioncontrol.
The estimator is created outside of `NewMissionControl`, passed in as a
`MissionControlConfig` field, to facilitate usage of externally supplied
estimators.
The grpc stream.Recv() will decode an ForwardHtlcInterceptResponse
without an IncomingCircuit, which will leave that pointer nil,
causing a nil pointer dereferece when components of in.IncomingCircuitKey
are used in the resolveFromClient() function.
This commit checks for the nil pointer and returns an error before
the rest of the parsing.
* we rename the current probability estimator to be the "apriori"
probability estimator to distinguish from a different implementation
later
* the AprioriEstimator is exported to later be able to type switch
* getLocalPairProbability -> LocalPairProbabiltiy (later part of an
exported interface)
* getPairProbability -> getPairProbabiltiy (later part of an exported
interface)
Use kvdb package v1.4.1. This update also forced the protobuf version to
be bumped which required `make rpc` to be run to update the generated
files. This also required a bump in the github pinned dependencies
config for the grpc and protobuf libs.
Add a new subpackage to `lnd/channeldb` to hold some of the types that
are used in the package itself and in other packages that should not
depend on `channeldb`.
We deprecate `QueryProbability`, as it displays the same information as
`QueryMissionControl` less the probability. `QueryRoutes` still contains
the total probability of a route.
Extends the pathfinder with a capacity argument for later usage.
In tests, the inserted testCapacity has no effect, but will be used
later to estimate reduced probabilities from it.
Test stream cancellation of the TrackPayments rpc call. In order to achieve
this, ControlTowerSubscriber is converted to an interface, to avoid trying to
close a null channel when closing the subscription. By returning a mock
implementation of the ControlTowerSubscriber in the test that problem is
avoided.
In this commit, we start to ignore the option to allow the caller to use
the legacy onion payload. The new payload is much more flexible and
efficient, so there's really no reason to still use it, other than for
backwards compatibility tests. Our existing tests that exercise the
legacy feature uses a build tag, which forces nodes to not advertise the
new payload format, which then forces path finding to include the legacy
payload, so we can be confident that route is still being tested.
The existence of this option (which actually makes the TLV payload
opt-in for `SendToRoute` users) makes it harder to remove it from the
protocol all together. With this PR, we take a step forward to allowing
such a change which is being tracked on the spec level at:
https://github.com/lightning/bolts/pull/962.
In a future release, we'll move to remove the field all together.
Ignoring the field today doesn't seem to have any clear downsides, as
most payments always include the MPP payload (due to payment secrets),
so this shouldn't impact users in a significant way.
The `log.go` file of each subserver is a copy and paste of the others.
All of them have the same typo, an extra space in a comment, and the
the definition of a function not used anywhere.
In this commit we move the tracking of the outstanding intercepted htlcs
to InterceptableSwitch. This is a preparation for making the htlc
interceptor required.
Required interception involves tracking outstanding htlcs across
multiple grpc client sessions. The per-session routerrpc
forwardInterceptor object is therefore no longer the best place for
that.
This commit was previously split into the following parts to ease
review:
- 2d746f68: replace imports
- 4008f0fd: use ecdsa.Signature
- 849e33d1: remove btcec.S256()
- b8f6ebbd: use v2 library correctly
- fa80bca9: bump go modules
This commit adds the `force` flag to the `XImportMissionControl` RPC
which allows skipping rules around the pair import except for what is
mandatory to make values meaningful. This can be useful for when clients
would like to forcibly override MC state in order to manipulate routing
results.
when payment_hash or final_cltv_delta and payment_request was set, the error message showed that the parameters shouldn't be set with dest instead of payment_request
[skip ci]
This commit ensures htlcs currently held by the interceptor
Are not sent again. This prevents potential races in the user code that
may lead to loosing funds.
