This commit turns off route blinding for the daemon while we're waiting
on full handling for blinded errors. The feature remains on for itests
so that tests covering blinding can run as usual.
We don't support receiving blinded in this PR - just intercept and
settle instead. The HTLC's arrival on the interceptor indicates that
it was successfully forwarded on a blinded hop.
Reject any HTLCs that use us as an introduction point in a blinded
route if we have disabled route blinding. We have to do this after
we've processed the payload, because we only know we're an introduction
point once we've processed the payload itself.
If we received a payload with a encrypted data point set, our forwarding
information should be set from the information in our encrypted blob.
This behavior is the same for introduction and relying nodes in a
blinded route.
To separate blinded route parsing from payload parsing, we need to
return the parsed types map so that we can properly validate blinded
data payloads against what we saw in the onion.
When we have a HTLC that is part of a blinded route, we need to include
the next ephemeral blinding point in UpdateAddHtlc for the next hop. The
way that we handle the addition of this key is the same for introduction
nodes and relaying nodes within the route.
This commit introduces a blinding kits which abstracts over the
operations required to decrypt, deserialize and reconstruct forwarding
data from an encrypted blob of data included for nodes in blinded
routes.
Add an option to disable route blinding, failing back any HTLC with
a blinding point set when we haven't got the feature enabled.
Note that this commit only handles the case where we're chosen as the
relaying node (where the blinding point is in update_add_htlc), we'll
add handling for the introduction node case once we get to handling of
blinded payloads).
This reverts commit 717facc202.
It turns out that we can't do this since it would result in
incompatibility with LDK. The spec has been updated to reallow
optional gossip queries so we revert this commit.
In this commit, we add the coin selection strategy option to the following
on-chain RPCs `fundpsbt`, `batchopenchannel`, `estimatefee`, `sendcoins`,
`sendmany`, and `sendoutputs`.
In this commit we add coin selection strategy option to the
following on-chain rpc commands `fundpsbt`, `fundtemplatepsbt`,
`batchopenchannel`, `estimatefee`, `sendcoins`, and `sendmany`.
In this commit, we add the coin selection strategy option
to all on-chain RPCs `FundPsbt`, `BatchOpenChannel`, `EstimateFee`,
`SendMany`, `SendCoins`, `SendOutputs`.
In this commit, the tlv extension of a channel update message is parsed.
If an inbound fee schedule is encountered, it is reported in the
graph rpc calls.
As SQL serializaton errors can lead to transaction retries we need to
ensure that we reset any out of scope containers where we accumulate
results. Otherwise partial data from a previously executed transacton
retry may be returned along with the latest result.
This field is incorrectly suffixed as "msat", when it is actually
interpreted as the proportional fee rate. This is the value that we
should be using because the sender will calculate proportional fees
accordingly. This is a breaking change to the RPC, but on an
experimental and unreleased API.
