From ZmnSCPxj at protonmail.com Mon Nov 26 08:10:11 2018 From: ZmnSCPxj at protonmail.com (ZmnSCPxj) Date: Mon, 26 Nov 2018 08:10:11 +0000 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: Good morning Johan, I believe what Rusty refers to here is a probe by an intermediate node, rather than a probe by the source node (who, as we know, already knows whether the payee supports AMP or not, by the invoice). Regards, ZmnSCPxj Sent with [ProtonMail](https://protonmail.com) Secure Email. ??????? Original Message ??????? On Monday, November 26, 2018 3:58 PM, Johan Tor?s Halseth wrote: > This shouldn't be problem, as the invoice will already indicate that the node supports BaseAMP. If you have a reason to not reveal that you support BAMP for certain invoices, you'll just not specify it in the invoice, and act non-BAMPy when receiving payments to this payment hash. > > Of course, this will also be opt-in for both sides and won't affect existing nodes in any way. > > Cheers, > Johan > > On Wed, Nov 21, 2018 at 11:54 PM Rusty Russell wrote: > >> Johan Tor?s Halseth writes: >>> Seems like we can restrict the changes to BOLT11 by having the receiver >>> assume NAMP for incoming payments < invoice_amount. (with some timeout of >>> course, but that would need to be the case even when the sender is >>> signalling NAMP). >> >> This would effectively become a probe for Base AMP; if you get a partial >> payment error, it's because the recipient didn't support Base AMP. >> >> Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then >> it's explicitly opt-in for both sides and doesn't affect existing nodes >> in any way. >> >> Cheers, >> Rusty. -------------- next part -------------- An HTML attachment was scrubbed... URL: