lnd doesn't allow overpaying

[cdecker]

c-lightning recently merged an improvement that slightly overpays the final node to obfuscate the true destination of the payment. However lnd doesn't accept payments that do not match the exact value expected:

c-lightning output:

DEBUG:proc:2018-04-02T15:26:51.962Z lightningd(21136): pay(0x17414c0): Failed, reporting to caller
DEBUG:proc:2018-04-02T15:26:51.963Z lightningd(21136):jcon fd 15: Failing: failed: WIRE_INCORRECT_PAYMENT_AMOUNT (reply from remote)
DEBUG:root:Received response for pay call: {'id': 0, 'error': {'data': {'failcode': 16400, 'failures': [], 'erring_channel': '0:0:0', 'erring_index': 1, 'erring_node': '009d73ca3947b25eb0fc063c5849523c2a7558d01332afd03ad0d496cf6bdee34e40aae14874681f2d34a6a3dfb90c6800cdad2a64114e4b5ef3286778bf4cdf'}, 'code': 203, 'message': 'failed: WIRE_INCORRECT_PAYMENT_AMOUNT (reply from remote)'}, 'jsonrpc': '2.0'}

lnd output:

DEBUG:lnd(16332):2018-04-02 17:26:51.828 [TRC] HSWC: ChannelLink(133:1:1) processing 1 remote adds for height 1
DEBUG:lnd(16332):2018-04-02 17:26:51.848 [ERR] HSWC: Onion payload of incoming htlc(017d0f3a77a2e474734a6349c3f203d7a8faa45a1ca7e942968b11681620252f) has incorrect value: expected 1000000 mSAT, got 1003358 mSAT
DEBUG:proc:2018-04-02T15:26:51.850Z lightningd(21136): lightning_channeld-02e3de6bcf96d4d03ad0af3213d058752a3c5249583c06fcb05eb24739ca739d00 chan #1: peer_in WIRE_UPDATE_FAIL_HTLC
DEBUG:proc:2018-04-02T15:26:51.850Z lightningd(21136): lightning_channeld-02e3de6bcf96d4d03ad0af3213d058752a3c5249583c06fcb05eb24739ca739d00 chan #1: FAIL:: HTLC LOCAL 0 = RCVD_REMOVE_HTLC/SENT_REMOVE_HTLC
DEBUG:lnd(16332):2018-04-02 17:26:51.848 [DBG] PEER: Sending UpdateFailHTLC(chan_id=5cc6cebff440d04e3deaf7f79fbc7b29dd34be4a113db3b12a14fd9f6da74f44, id=0, reason=c7a72d04c0d52d32e710f7e4ec2a319e05f2791113da9de165c9a9fd82cdf74488f1502e82d17678eec27586644f216eb7741ed2b784d
4d69bc1c3670b0e295539cb7fd268a167ccfe8ee18b016c93818c0127ea21416f65e618b9dfa4206e70142b5a9359ef15af572c9535faf1ae5d2e8204ba2bc5d6effd643b3669ded6fa3437023a9a345289b9ce134dd2e42ee87ed5c613831597620bc408a8d7f3396a8ec2563e2c1f3ac173e6a82b845a19f90aab11985266b3df41dd7b35ed6ba
337edd11bd54fa5ada8689a0351123863315556f5c57ee0ad2e20c19f8da07d31ba281d80b30ed5a59e3f9c09e546089b47772fdc16e5fd73537bcc11be611473c66bb7e56ced0fb724f5f8c5188f02a47cd72599be3442cdae0b24c2bfcb389d0b250bf726) to 127.0.0.1:60482
DEBUG:lnd(16332):2018-04-02 17:26:51.848 [TRC] PEER: writeMessage to 127.0.0.1:60482: (*lnwire.UpdateFailHTLC)(0xc420560700)({
DEBUG:lnd(16332): ChanID: (lnwire.ChannelID) (len=32 cap=32) 5cc6cebff440d04e3deaf7f79fbc7b29dd34be4a113db3b12a14fd9f6da74f44,
DEBUG:lnd(16332): ID: (uint64) 0,
DEBUG:lnd(16332): Reason: (lnwire.OpaqueReason) (len=292 cap=292) {
DEBUG:lnd(16332):  00000000  c7 a7 2d 04 c0 d5 2d 32  e7 10 f7 e4 ec 2a 31 9e  |..-...-2.....*1.|
DEBUG:lnd(16332):  00000010  05 f2 79 11 13 da 9d e1  65 c9 a9 fd 82 cd f7 44  |..y.....e......D|
DEBUG:lnd(16332):  00000020  88 f1 50 2e 82 d1 76 78  ee c2 75 86 64 4f 21 6e  |..P...vx..u.dO!n|
DEBUG:lnd(16332):  00000030  b7 74 1e d2 b7 84 d4 d6  9b c1 c3 67 0b 0e 29 55  |.t.........g..)U|
DEBUG:lnd(16332):  00000040  39 cb 7f d2 68 a1 67 cc  fe 8e e1 8b 01 6c 93 81  |9...h.g......l..|
DEBUG:lnd(16332):  00000050  8c 01 27 ea 21 41 6f 65  e6 18 b9 df a4 20 6e 70  |..'.!Aoe..... np|
DEBUG:lnd(16332):  00000060  14 2b 5a 93 59 ef 15 af  57 2c 95 35 fa f1 ae 5d  |.+Z.Y...W,.5...]|
DEBUG:lnd(16332):  00000070  2e 82 04 ba 2b c5 d6 ef  fd 64 3b 36 69 de d6 fa  |....+....d;6i...|
DEBUG:lnd(16332):  00000080  34 37 02 3a 9a 34 52 89  b9 ce 13 4d d2 e4 2e e8  |47.:.4R....M....|
DEBUG:lnd(16332):  00000090  7e d5 c6 13 83 15 97 62  0b c4 08 a8 d7 f3 39 6a  |~......b......9j|
DEBUG:lnd(16332):  000000a0  8e c2 56 3e 2c 1f 3a c1  73 e6 a8 2b 84 5a 19 f9  |..V>,.:.s..+.Z..|
DEBUG:lnd(16332):  000000b0  0a ab 11 98 52 66 b3 df  41 dd 7b 35 ed 6b a3 37  |....Rf..A.{5.k.7|
DEBUG:lnd(16332):  000000c0  ed d1 1b d5 4f a5 ad a8  68 9a 03 51 12 38 63 31  |....O...h..Q.8c1|
DEBUG:lnd(16332):  000000d0  55 56 f5 c5 7e e0 ad 2e  20 c1 9f 8d a0 7d 31 ba  |UV..~... ....}1.|
DEBUG:lnd(16332):  000000e0  28 1d 80 b3 0e d5 a5 9e  3f 9c 09 e5 46 08 9b 47  |(.......?...F..G|
DEBUG:lnd(16332):  000000f0  77 2f dc 16 e5 fd 73 53  7b cc 11 be 61 14 73 c6  |w/....sS{...a.s.|
DEBUG:lnd(16332):  00000100  6b b7 e5 6c ed 0f b7 24  f5 f8 c5 18 8f 02 a4 7c  |k..l...$.......||
DEBUG:lnd(16332):  00000110  d7 25 99 be 34 42 cd ae  0b 24 c2 bf cb 38 9d 0b  |.%..4B...$...8..|
DEBUG:lnd(16332):  00000120  25 0b f7 26                                       |%..&|
DEBUG:lnd(16332): }
DEBUG:lnd(16332):})

Notice that the spec explicitly allows this kind of overpayment:

f the amount paid is less than the amount expected, the final node MUST fail the HTLC. If the amount paid is more than twice the amount expected, the final node SHOULD fail the HTLC. This allows the sender to reduce information leakage by altering the amount, without allowing accidental gross overpayment:

[cdecker]

Ping @Roasbeef

[leishman]

Looks like there is a disagreement here: lightningnetwork/lnd#1002

[Roasbeef]

What's the disagreement? If it's w.r.t correctness, this has been fixed in lnd: lightningnetwork/lnd@5984cbd

If it's w.r.t whether overpaying is warranted (or will even really be effective at all, as intermediate nodes could still attempt to correlate based on max deviation), then that's another convo all together...

[leishman]

Ah ok. I didn't see the related commit when you closed the issue. Nevermind! All good

[cdecker]

Considering this as closed by commit lightningnetwork/lnd@5984cbd