bolt 11 payment addr + single shot mpp for SendPayment #3679
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
3 times, most recently
from
b0ac5ac
to
52371dc
Compare
joostjager
reviewed
Nov 6, 2019
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
from
52371dc
to
21d477d
Compare
joostjager
reviewed
Nov 7, 2019
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
from
21d477d
to
d3228d1
Compare
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
2 times, most recently
from
eb2df71
to
92a488b
Compare
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
from
92a488b
to
b008eda
Compare
Roasbeef
approved these changes
Dec 7, 2019
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
from
b008eda
to
4d9377e
Compare
halseth
approved these changes
Dec 9, 2019
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
from
4d9377e
to
d5cf1c8
Compare
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
4 times, most recently
from
7d03bd3
to
111062b
Compare
halseth
reviewed
Dec 18, 2019
| @@ -292,6 +292,11 @@ type RestrictParams struct { | |||
| // DestCustomRecords contains the custom records to drop off at the | |||
| // final hop, if any. | |||
| DestCustomRecords record.CustomSet | |||
|
|
|||
| // DestFeatures is a feature vector describing what the final hop | |||
| // supports. If none are provided, pathfinding will try to inspect any | |||
There was a problem hiding this comment.
could an alternative be to take the concatenation of the provided features and those found in the graph? Or would there be a use for "disabling" features found in the graph.
There was a problem hiding this comment.
we could do that, for now we just override on the assumption that the invoice is more critical than the node announcement (since it may advertise a distinct combination from the graph). we could consider changing this in the future tho
| // PaymentAddr is a random 32-byte value generated by the receiver to | ||
| // mitigate probing vectors and payment sniping attacks on overpaid | ||
| // invoices. | ||
| PaymentAddr *[32]byte |
There was a problem hiding this comment.
since the value is not used, maybe better to just make this a bool, or another feature vector encoding the features we require the destination to have.
EDIT: I see it is used in later commits. Though it is a bit werid that pathfinding is responsible for setting the addr
| // transitive feature dependencies for this node, and skip the | ||
| // channel if they are invalid. | ||
| default: | ||
| err := feature.ValidateDeps(edge.Node.Features) |
There was a problem hiding this comment.
I'm not super familiar with the TLV blobs passed to intermediate nodes, but do we really need to care whether the features are valid?
There was a problem hiding this comment.
for now actually, we only care about TLV support which has no dependencies. in general tho i think it is better to be strict and ignore nodes that don't generate well formed announcemements
|
Great commit structure, makes even a massive PR like this manageable to review 👍 |
Previously we would return nil features when we didn't have a node announcement or a given node. With this change, we can always assume the feature vector is populated during pathfinding.
Later this will be used to populate distinct feature vectors for either end of the channel.
This commit allows custom node features to be populated in specific test instances. For consistency, we auto-populate an empty feature vector for nodes that have nil feature vectors before writing them to the database.
In this commit, we fix a bug that prevents us from sending custom records to nodes that aren't in the graph. Previously we would simply fail if we were unable to retrieve the node's features. To remedy, we add the option of supplying the destination's feature bits into path finding. If present, we will use them directly without consulting the graph, resolving the original issue. Instead, we will only consult the graph as a fallback, which will still fail if the node doesn't exist since the TLV features won't be populated in the empty feature vector. Furthermore, this also permits us to provide "virtual features" into the pathfinding logic, where we make assumptions about what the receiver supports even if the feature vector isn't actually taken from an invoice. This can useful in cases like keysend, where we don't have an invoice, but we can still attempt the payment if we assume the receiver supports TLV.
This commit adds an optional PaymentAddr field to the RestrictParams, so that we can verify the final hop can support it before doing an expensive round of pathfindig.
In this commit, we overwrite the final hop's features with either the destination features or those loaded from the graph fallback. This ensures that the same features used in pathfinding will be provided to route construction. In an earlier commit, we validated the final hop's transitive feature dependencies, so we also add validation to non-final nodes.
This commit creates a wrapper struct, grouping all parameters that influence the final hop during route construction. This is a preliminary step for passing in the receiver's invoice feature bits, which will be used to select an appropriate payment or payload type.
We move up the check for TLV support, since we will later use it to determine if we can use dependent features, e.g. TLV records and payment addresses.
This commit constructs a helper closure assertAmountSent that can be reused by other functions. The closure returns an error so that it can be used with wait.NoError or the new wait.InvariantNoError. The latter is added since the predicate could otherwise pass immediately for the sphinx_replay_persistence tests, but change shortly after. It also rounds out the wait package so that we offer all combinations of predicate and no-error style waits.
cfromknecht
force-pushed
the
bolt-11-payment-addr
branch
from
111062b
to
1dbeb34
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
In this PR, we make single-shot MPP payments the default payment type in lnd, and marks a major milestone in our long series of PRs preparing us for multi-path payments.
Notable changes
var_onion_optin) and payment address (option_payment_addr).Lightning.SendPaymentorRouterRPC.SendPaymentwill:MPPrecord in the final hop's payload if both the above options are supported, which includes the payment address from the invoice.By upgrading to this payment type, lnd senders and receivers are offered increased protection from payment sniping and against probing attacks on the receiver. In the future both features will be made mandatory, entirely disabling support for the legacy payment style.
Depends on: