single-shot, sender-side mpp via sendtoroute#3442
Conversation
cfromknecht
force-pushed
the
router-registry
branch
from
e077cc4 to
6c7f713
Compare
joostjager
left a comment
joostjager
left a comment
There was a problem hiding this comment.
I also experienced that the onion blob decryption code needs to be moved out of htlcswitch so that it can be used in cnct without a circular reference. Will we move that into htlcswitch/payload too?
cfromknecht
force-pushed
the
router-registry
branch
7 times, most recently
from
d08300d to
0b70f6d
Compare
Discussed offline. Plan is to move decryption ( |
cfromknecht
force-pushed
the
router-registry
branch
from
0b70f6d to
2c14250
Compare
Roasbeef
added
enhancement
There was a problem hiding this comment.
This comment is a bit confusing, should say something like "the total amount in satoshis of the payment if this is a sub payment of smaller amount"? I don't know what the best way to put this..
cfromknecht
force-pushed
the
router-registry
branch
2 times, most recently
from
a8001c5 to
28e9d02
Compare
cfromknecht
force-pushed
the
router-registry
branch
3 times, most recently
from
2dcb941 to
b94383e
Compare
cfromknecht
changed the title
cfromknecht
changed the title
@joostjager added |
joostjager
left a comment
joostjager
left a comment
There was a problem hiding this comment.
Ack on restructuring db to single tlv blob (also containing legacy payload fields) in a follow-up.
|
ACK on using single blob in follow-up. I still have opinions about not having the optional MPP record be its own field on the struct, but that we can discuss in the follow-up. |
There was a problem hiding this comment.
Hm, when is the time to get rid of one of these RPCs?
There was a problem hiding this comment.
i wouldn't be opposed to deprecating the streaming version and telling people to switch to SendToRouteSync, or RouterRPC.SendToRoute if they don't mind dealing with breaking changes.
cfromknecht
force-pushed
the
router-registry
branch
from
8da65db to
44e6e80
Compare
|
Needs a rebase! Then I think this is ready to land. |
cfromknecht
force-pushed
the
router-registry
branch
from
44e6e80 to
4a9d077
Compare
|
@Roasbeef rebased! |
cfromknecht
force-pushed
the
router-registry
branch
2 times, most recently
from
3be2935 to
3b5185d
Compare
These encoders can be composed to create composite types without incurring additional allocations that would be required to pass the truncated types through the generic interface.
Used to encode/decode MPP tlv records
This commit also modifies the Router serialization to persist the MPP struct when present, and properly restore it when loading from disk.
cfromknecht
force-pushed
the
router-registry
branch
from
3b5185d to
e2baeb3
Compare
This commit add mpp_total_amt_msat and mpp_payment_addr to the Hop message. Doing so enables users submitting mpp payments via rpc to set these parameters for the destination. In addition, it will allow us to display these fields in rpc responses.
This commit parses mpp_total_amt_msat and mpp_payment_addr from the SendToRoute rpc and populates an MPP record on the internal hop reprsentation. When the router goes to encode the onion packet, these fields will be serialized for the destination. We also populate the mpp fields when marshalling routes in rpc responses.
We already wait for all channels to open before creating the payment requests.
In this commit, we refactor the testSingleHopSendToRoute test to support table driven tests for various endpoints and payment types. Currently only the main rpcserver's SendToRoute is tested, so we also add support the SendToRouteSync and the routerrpc's SendToRoute. The tests are also modified to have each endpoint perform a single-hop, single-shot MPP payment. This asserts that the Hop messages are being properly unmarshalled and that setting correctly yields a successful payment. At the momemnt the receiver does not actually verify or use the MPP fields presented in the onion, though this test will be expanded later as those pieces are assembled.
cfromknecht
force-pushed
the
router-registry
branch
from
e2baeb3 to
540e44e
Compare
4 participants
This PR lays some more groundwork for our road to MPP payments in lnd. Here we add the ability to send MPP shards from the sender-side via
SendToRoute, whose additional fields are properly encoded in the onion blob and delivered to the receiver.Apart from verifying that mpp records are not received at intermediate hops, the receiver does not perform any additional validation of the actual fields contained within. The receiver side has been modified to deliver these values all the way down to the invoice registry, but they are not inspected. Thus, the receiver will process the payment as they would a traditional payment. The additional behavior to enforce the MPP fields will be added in #3415, at which point the behaviors will diverge.
For now, the integration tests have been expanded to cover the three send to route endpoints
Lightning.SendToRoute,Lightning.SendToRouteSync, andRouterRPC.SendToRoute, as well as testing that each can properly pay with single MPP shards. Future changes will continue to expand the assertions as more pieces come into place.