LOL wait I just realized…. the MultiPTLC P branches are just (proof-of-payment + delta) * G. And nothing really requires that the onion data includes the actual incoming point or the outgoing point, it only requires the delta shard for that hop to be included. So the LSP can select the receiver-can-claim scalar after Ursula gets the MultiPTLC irrevocably committed — Ursula does not need to know either the receiver-can-claim scalar or its point. So the LSP adds the receiver-can-claim point to the point asked for by the incoming P branch and fire out an outgoing plain PTLC to the receiver with the point added, so that at the receiver, it needs the receiver-can-claim scalar from the LSP to be able to finally claim the money. This lets us remove the 1.0 roundtrips for Ursula to request for receiver-can-claim points, getting us down to 0.5 roundtrips at the Ursula→(Alice,Bob,Carol) hop if we use “fast forwards” in the MultiChannel. In fact, we do not even need to use TCP (which requires ACKing return packets) we can use UDP and forward error correction like the old mining protocol compact blocks encoding thing by TheBlueMatt to make it truly 0.5 roundtrips from Ursula→(Alice, Bob, Carol) and have Ursula just blast out the data to all of the LSPs. As long as any one of the LSPs can recover enough of the FEC data, they can then share with the others in the quorum via standard TCP and be able to facilitate the rest of the “stuckless but not actually lolololol” payment flow.
MultiPTLC is awesome man.
I mean think about it: what the sender Ursula wants is “any one of these proof-of-payment + delta is revealed to me, but at most only one.” MultiPTLC encodes that directly, because only one of the P branches can be fulfilled. HAving multiple parallel plain PTLCs at the Ursula→(Alice,Bob,Carol) hop does not encode that directly, we need to add the receiver-can-claim scalar to ensure that exactly only one PTLC can be claimed by the receiver. So multiple parallel plain PTLCs are. from a system design standpoint, more complicated than just a MultiPTLC because it requires adding in a receiver-can-claim scalar. Basically, the MultiPTLC simply directly encodes the intent of Ursula the user: “I only care that at most one of these paths succeeds, I do not care what happens to the others” and it is the LSPs who can make those paths be runnable in parallel by adding in their own receiver-can-claim secret at their hop.
SOOOO anyway the final piece is: how would the LSPs prove that they managed to get a payment out to the receiver? What we can do is that the final onion payload at the receiver gets a challenge nonce that the receiver hands back to the “sender” (or more specifically, whoever holds the receiver-can-claim secret); in terms of “stateless” LDK that nonce can be used to derive the receiver-can-claim secret, just like the payment secret in LDK is used to derive the payment preimage. In the case of MultiPTLC in MultiChannel, that nonce is the proof that the final onion payload reached the receiver — Ursula puts different receiver-end nonces in the onions it prepares, and provides the HASH of those nonce in the MultiPTLC package. The winning LSP can then show this preimage (which is unique to one of the paths that the LSP sent out) to convince the other LSPs to sign for the MultiPTLC branch that finalizes that path, so that the LSP can be assured that it can claim the Ursula-provided funds if it releases the corresponding receiver-can-claim secret to the receiver. Yes Ursula can provide that receiver-reached-nonce to the LSP directly, but that is no different than just handing over money to the LSP it is favoring, which it can do with a direct transfer to that LSP over the MultiChannel, so this is just doing the same thing that Ursula can already do anyway.