lnd refuses overpayment?

[ZmnSCPxj]

Background

lnd/htlcswitch/link.go

Lines 1964 to 1979 in 9b72965

	if !l.cfg.DebugHTLC && invoice.Terms.Value > 0 &&
	fwdInfo.AmountToForward != invoice.Terms.Value {
	log.Errorf("Onion payload of incoming htlc(%x) "+
	"has incorrect value: expected %v, "+
	"got %v", pd.RHash, invoice.Terms.Value,
	fwdInfo.AmountToForward)
	failure := lnwire.FailIncorrectPaymentAmount{}
	l.sendHTLCError(
	pd.HtlcIndex, failure, obfuscator, pd.SourceRef,
	)
	needUpdate = true
	continue
	}

Suggests that lnd refuses overpayment of invoices.

Xref: https://github.com/lightningnetwork/lightning-rfc/blob/master/04-onion-routing.md

An intermediate hop MUST NOT, but the final node:

• if the amount paid is less than the amount expected:
  • MUST fail the HTLC.
• if the amount paid is more than twice the amount expected:
  • SHOULD fail the HTLC.
  • SHOULD return an incorrect_payment_amount error.
    • Note: this allows the origin node to reduce information leakage by
      altering the amount while not allowing for accidental gross overpayment.

Recently c-lightning added ability to automatically overpay: ElementsProject/lightning#1257

This caused somebody to open an issue on c-lightning: ElementsProject/lightning#1309

However specs seem to suggest that c-lightning behavior is within spec.

Your environment

• version of lnd 9b72965
• which operating system (uname -a on *Nix) N/A
• version of btcd, bitcoind, or other backend N/A
• any other relevant environment details Sheer code review

Steps to reproduce

Sheer code review

Expected behaviour

lnd should accept invoice <= payment <= invoice * 2.

Actual behaviour

lnd accepts only invoice == payment

[Roasbeef]

Automatically overpaying sounds like a really bad idea. We've already seen users get touchy about the on-chain commitment fees they pay. Randomly forcing the user to pay twice the invoice amount will result in further confusion and unnecessary leakage of user funds.

I see the argument for adding shadow routes (pad out the CLTV value to add plausible deniability w.r.t route details), but why would one want to automatically overpay?

[ZmnSCPxj]

Fees will happen on-Lightning anyway (fee_base, fee_per_millionth). C-lightning pay command accepts a maximum fee rate as a percent of the payment amount. The total amount that it will give out on the first hop will never exceed the maximum fee rate --- if it would, it recomputes the route and overpayment without even trying the route.

The overpayment is randomized between 0 to up to the maximum fee rate.

The effect is that overpayment tends to be lower the further you are from the payee, but this is not reliable --- C-lightning could overpay by a small amount with some probability even on a direct channel to the payee.

Note that C-lightning even does route randomization --- it will sometimes take non-optimal routes (even if it does not know the optimal route would fail). The only requirement is that, the first hop, will not be given more than the maximum fee rate deemed acceptable by the user. This means that the maximum fee rate is a privacy parameter in C-lightning, and overpayment simply hides within the fees we are obliged to pay on-Lightning anyway.