What would be the point of using the even bit?

For odd bits, it seems to me to mean, "payer may use basic_mpp".

For even bits, what is it mean? "Payer must use basic_mpp"?

We always assign in pairs. In future, it's theoretically possible you could set this if no single channel had sufficient capacity, I guess, but it's a bit weird!

We may also want to add an additional section here w.r.t path finding advisory using routing hints. If the amount of the invoice is greater than available inbound bandwidth of any of their channels, then they can "guide" the sender with regular or "special" routing hints to increase the likelihood of success.

This is already covered for regular AMP, but for regular MPP, I think we should also include a random identifier here and require that the sender include this for end-to-end security (in the onion). Otherwise, if it's a 0-value invoice, then intermediate nodes can probe, and then use that information to possibly take most/all of the HTLC as "fees".

Great point, there is indeed an attack vector here for the next-to-last node!
Your suggested fix assumes that the payment request will stay hidden from the intermediate nodes though (otherwise it doesn't fix anything if the intermediate nodes also know this random identifier).
It could be important to highlight this point to applications that want to leverage MPP: using MPP for donations should be a two-steps process, where a user who wants to donate needs to go to your website to get an invoice generated for him (and only him). That invoice must not be shared publicly.

We may also want to add an additional section here w.r.t path finding advisory using routing hints. If the amount of the invoice is greater than available inbound bandwidth of any of their channels, then they can "guide" the sender with regular or "special" routing hints to increase the likelihood of success.

I suggest a minimal two-tuple of (amt, randID) as mentioned in my earlier comment.

Shouldn't randID be defined as a separate type, so that it can be used to pay non-amp to zero-valued invoices?

This conflicts w/ two bullets below (try to re-derive if they fail).

We should also have a section below here detailing failure modes due to partial settles, as it's possible that some portion of the funds just never get to the receiver, and become windfall for intermediate nodes.

We should also have a section below here detailing failure modes due to partial settles, as it's possible that some portion of the funds just never get to the receiver, and become windfall for intermediate nodes.

Can you explain what you mean? I didn't get that.

A static value here isn't very encompassing. It may be the case that a higher level application has the sender purposefully delay the remaining shards.

True but I think the receiver should enforce a maximum duration for a receive session, otherwise a malicious sender can lock funds from a lot of people almost indefinitely (if what you were thinking of was some kind of sliding window on the receiver end where you reset the timeout each time you receive a valid share).

Could it be useful to specify the hold timeout in the onion payload, so that the sender picks this value themselves?

Yeah, we need to pick something, and it can't really be up to the sender or recipient since it effects the entire network. Implementations will pick something, so might as well specify it.

In addition to the seconds timeout, does something need to be specified in terms of block height? It could be that the first htlc comes in, meets the invoice cltv delta requirement, but its value isn't high enough to settle the invoice. The htlc is held. Then a block comes in. At that point, the cltv delta requirement isn't met anymore. Should the htlc be canceled?

Agree better to specify in terms of block height. If CLTV height is shared between all HTLCs, you should be able to wait until it minus some block height delta to land an unilateral closing.

Also with current wording it's not clear what receiving node should do after delay expiration, back to step upper ("SHOULD fulfill ...") or go to the one below ("MUST fail ...")

If we don't add a mandatory random identifier along the way, then we should discourage sending more than the invoice amount.

Does this mean that an adversary can prevent an amp payment from completion by periodically sending a very small shard with a random total_msat, thereby cancelling any shards that have been acquired?

I guess those htlcs are cancelled early in the process because their total_msat doesn't match what is in the invoice database. How would it work in that case for zero-valued invoices? First htlc that arrives sets the amount?

You're right, will change to ignore & fail if total_msat is different to avoid griefing.

We must make sure that an attacker can't cancel other shards, but also that they can't block the genuine shards from being accepted. If the attacker is the first to set the tracked total_msat to a random value, they could possibly block the payment for the timeout duration (and repeat this thereafter).

In that light, the proposed randID may actually be required not only to prevent fee stealing with 0-valued invoices, but also to keep an attacker from interfering with the multi path settle process.

The attacker can generate a new sender-generated randID for this. But if the receiver would match on a receiver-generated randID, the attack wouldn't work.

This only applies to regular, non-mpp payments I think.

Indeed the receiver-generated randID limits payment to the anyone who has seen the invoice, versus anyone willing to probe with the payment hash. With sender-generated randID, I think the attack works for mpp as well?

the penultimate node can find out whether they are the penultimate node by crafting a new single hop route instead of forwarding as they should. If the newly crafted route succeeds, they know that the next node is the final destination.

IIUC the attack isn't limited to the penultimate node, just easier because they have less guess on the amount, right?

This is contradictory to being able to pay to settled invoices (to prevent leaking whether an invoice is paid or not). We could cancel all other sets, mark the invoice as settled, but if a new set comes in after that, we'd accept it again. Then we could just as well settle all sets that meet the requirements always.

Interesting, so using mpp you could silently learn the intended receiver without ever paying at all, and still successfully forward the payment by:

• send partial mpp to receiver (not full amount)
• if it gets held, you've found the receiver
• wait 60s for htlc to be canceled
• forward original htlc as normal

Having the receiver-generated randID will ensure that the receiver can cancel probers' htlcs immediately so they don't see the htlc being held (both before or after) the real payer completes their payment.

In the penultimate node attack-scenario above, I think they can also still do fee sniping on zero valued mmp invoices without a receiver-generated randID. The attacker crafts a new route with a new, lower totalAmt (single shard), and buys the preimage cheaply.

Indeed I think the attack works in general if we allow overpayment (without the receiver-generated randID), though zero-value invoices are the worst offenders since they permit the greatest amount of overpayment.

Okay, I'm convinced of the need for a receiver-generated randID :)

IIUC the attack isn't limited to the penultimate node, just easier because they have less guess on the amount, right?

Yes, sounds like it. @t-bast was there anything specific in the second-to-last case?

Correct, anyone in the route could probe like that, but it's a lot easier for the penultimate node: it only has to test the next node in the route (which it knows because it is in the onion).

If you are the second-to-last node, you need to have the intuition of which node to probe, which is a lot harder in practice (unless you already suspect who the recipient is).

Ok, thanks for that clarification! What about calling it "invoice secret"? (is this a better term than 'receiver-generated randid`?)

Actually, we started calling this payment_address which is more descriptive in the context of #658.

Will there also be a global feature bit that advertises mpp in the graph, so that spontaneous AMP payments can be made too?

I think that in that case the invoice flag is still required, because the payer may not have the (up to date) node features of the payee? Does this mean that basic_mpp implies var_onion_optin?

Yes, and yes. I'll add that specifically.

What is the rationale for allowing the total htlc set amount_msat to be greater than total_msat? And should this be capped too, to be consistent with single path payments? Otherwise the following would be possible (if I understood this correctly): invoice amt: 1000 sat, total_msat: 1000 sat, first htlc: 500 sat, second htlc: 1 btc?

I agree here that total_msat should be equal to total amount_msat of the intended htlc set. Even if the sender wishes to overpay, they should know exactly the amount by which they want to overpay. The relation then would be

invoice_amount <= total_msat == sum amount_msat

This fails in the case of independent payers (eg. bill splitting), and it also restricts fuzzing on re-attempts. You now have to decide the total fuzz up-front, and thus leak more information if you have to split a payment since it will always add to the previous amount exactly.

And note that overpaying is consistent with existing payments, requiring exact payment would not be.

What does this mean exactly? If the sender has enough htlcs in flight to pay the invoice but the htlcs are not settled, they shouldn't add another htlc?

Exactly that's it. If you've sent an HTLC set that pays the total amount, you should wait for (some of) them to fail or settle. If you send another HTLC you will end up paying more than what you intended to pay.

As written I think this conflicts with the prior bullet. This says the sum can't be greater or equal, the prior says it must be greater or equal

No strict subset. This has been a source of confusion, though, so we need to reword it.

nit: Not introduced here but I found the writer/reader wording a bit weird outside bolt-11 shouldn't we stick with sending node/receiving node?

These are routed through multiple nodes though, so it's best to be clear. Maybe we should change to be "origin node" instead of writer, but reader can't always be replaced with "final node"....?

IIRC, we used "processing node" in other parts of the spec to name intermediary nodes

Maybe we should detail all set HTLCs have same final_ctlv ? I mean the expiry field from invoice should scope all HTLC buddies but they will have different first_cltv due to different cltv_delta on their mutual paths.

There's no reason I can think of to specify this though?

Having same final_ctlv encumbering every HTLC of the set should avoid one being expired and timeout while others being fulfilled due to misbehavior and so a partial payment.. But would require doing the same on whole multiple paths which is not realistic..

Agree better to specify in terms of block height. If CLTV height is shared between all HTLCs, you should be able to wait until it minus some block height delta to land an unilateral closing.

Also with current wording it's not clear what receiving node should do after delay expiration, back to step upper ("SHOULD fulfill ...") or go to the one below ("MUST fail ...")

In the same way, if you try to pull some HTLCs of the set before all of them are locked on final_hop channels it may be a risk? Let's say if you pick up different paths and some nodes share the same operator, if you provide preimage for HTLC#1 but HTLC#3 isn't locked yet, preimage could be replay on HTLC#3 first links without payment being forwarded until payee. This point should be better underscored.

Agree better to specify in terms of block height. If CLTV height is shared between all HTLCs, you should be able to wait until it minus some block height delta to land an unilateral closing.

No, you're tying up channels across the network. We're not going to hold things for many minutes before this becomes a spam attack. Certainly not waiting for blocks!

Also with current wording it's not clear what receiving node should do after delay expiration, back to step upper ("SHOULD fulfill ...") or go to the one below ("MUST fail ...")

Both apply. You SHOULD wait 60 seconds, you MUST have a some timeout.

In the same way, if you try to pull some HTLCs of the set before all of them are locked on final_hop channels it may be a risk? Let's say if you pick up different paths and some nodes share the same operator, if you provide preimage for HTLC#1 but HTLC#3 isn't locked yet, preimage could be replay on HTLC#3 first links without payment being forwarded until payee. This point should be better underscored.

Yes, we need to add "MUST NOT fulfill a set if the total is not sufficient".

This should be even, as we agreed to it in advance.

shouldn't this be: Unless node_announcement or BOLT 11 invoice contains var_onion_option? A node could support TLV w/o supporting this proposal.

Sure, but you can't add payment_data unless you have the payment_atgnwt!

i've been looking at this and wondering, what does it meant to require a multi-path payment. if the sender can get there in one shard, why would the receiver require them to use multiple paths? even then, the granularity would be 1 htlc or >1 htlc, which doesn't seem very useful.

i'm starting to think we don't really need a bit to indicate whether we can or cannot assemble multiple htlcs, and that this could just indicate optional/required for sending the payment_data record. most of complexity in mpp is on the sender side anyway, so idk how much we would be saving people by allowing them to choose between 1 and >1 on the receiver-side.

12/13 is already option_static_remotekey

I have some additional thoughts too. The reason we initially split the payment_secret and multi_part feature bits was to allow light payment receivers to require a payment_secret while not supporting multi-part. I still think this is a valid scenario and I think we can't achieve it now that there's no feature bit for payment_secret (unless we use var_onion_optin to implicitly do that as suggested, but I'm not a huge fan).

Receiving multi-part payments means you have to keep some state (partial HTLC set received) until either the payment succeeds or times out. It's hard to guess what other people will want to do in the future, but I can imagine a tiny payment processor in a vending machine that wouldn't want this overhead and would only support single-part payment, while enforcing the payment_secret.

I think our feature bit set should allow that kind of tuning, so I think it would be better to have a pair of feature bits for multi-part (14/15, even though the even one wouldn't make much sense) and a pair of feature bits for payment secret (16/17). This way a very constrained payment processor chip can set 16 without setting 14 nor 15.

Do you think this is overkill?

I think if you look at the total processing power that is required for a Lightning node, the tracking of a multi-path set is not significant. I'd rather add such specialized feature bit only when that "light receiver" actually presents itself.

If you don't have incoming capacity in a single channel, you might indicate you NEED MPP, maybe?

I think keeping the features separate is cleaner.

would be in favor of not overloading var_onion_optin with the s field. there's a huge gap between adding TLV onion and actually being able to implement this proposal, perhaps they should be separate?

There's a huge gap between implementing var_onion_optin and implementing MPP. But implementing support for payment secrets is really simple, right?
So making var_onion_optin compulsory to imply that you need to send the payment secret (potentially for existing single-part payments) seems acceptable, even though I'd prefer a dedicated feature bit to make it more explicit (but at the cost of more feature bits in the system...).

still unresolved?

Ah, this was fixed in #712 which reworks this paragraph anyway. Let me roll it in here, then I can rebase #712