From rusty at rustcorp.com.au Thu Nov 22 04:50:22 2018 From: rusty at rustcorp.com.au (Rusty Russell) Date: Thu, 22 Nov 2018 15:20:22 +1030 Subject: [Lightning-dev] Base AMP In-Reply-To: References: <87a7maf7jh.fsf@gmail.com> <2GH68_8IDCnzwQUhLoqLVrLZSXXP5jZYM5GLwEsV0CMVL_qvZQpliKI1ng0dmCPA-dlWnFRUuWJV7OQMsoFd-kwDzCGmk27H4dqYV1RPJhc=@protonmail.com> <20181116154527.25adgchhfsz7aa43@erisian.com.au> <87va4rp91k.fsf@rustcorp.com.au> <87k1l6nivn.fsf@rustcorp.com.au> Message-ID: <87h8g9n2b5.fsf@rustcorp.com.au> Conner Fromknecht writes: > Hi all, > >> But it's unnecessary for the recipient to know the total amount I meant >> to pay; they just need to return the receipt once it exceeds the amount >> they want. > > I think it?s true that the recipient doesn?t need to know necessarily, but > sending the intended amount is more robust IMO, since it provides an order > invariant hint for when the receiver can safely settle. > > If the sender does amount fuzzing (as CL does) or adds a tip, it?s possible > for the final partial payment to be less than `amount_to_pay` - > `invoice_amount`, causing the sender to settle prematurely. Otherwise, we > might want to specify that no split should be less than the amount > overpaid. > > Of course, if that amount never comes through yet the invoice is satisfied, > the receiver can always choose to settle even if the remaining amount never > arrives. It's more code, and takes 8 more bytes out of the onion. I've started coding up option_simplfied_commitment and it's making me terrified of adding any additional complexity :( The more compelling argument is that partial-payment donations might want this, but it's marginal, IMHO. We should be aiming for static invoices for the donate case. Cheers, Rusty.