📅 Original date posted:2018-11-26 📝 Original message: This shouldn't be ...

Johan Torås Halseth [ARCHIVE] /

npub1ppn…s2fw

2023-06-09 12:52:46

in reply to nevent1q…d9xg

📅 Original date posted:2018-11-26
📝 Original message:
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 <rusty at rustcorp.com.au>
wrote:

> Johan Torås Halseth <johanth at gmail.com> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181126/67166a9b/attachment.html>;

Author Public Key

npub1ppn2nhlfdzkw9gw0ytljpef5dpyzsxzw8ffcyykamt32hw6pge0smhs2fw

Show more details

Published at

2023-06-09 12:52:46

Kind type

1 Short Text Note

Event JSON

{ "id": "c15ca1b14b6d3d26b70819f252c55a4d5241bbeba21940d11f698345c4b1d060", "pubkey": "0866a9dfe968ace2a1cf22ff20e534684828184e3a538212dddae2abbb41465f", "created_at": 1686315166, "kind": 1, "tags": [ [ "e", "809f1a75998ec1e3eebcb7a31f0cc9fe5473d678fb16cc9dfe25f3232ec33478", "", "root" ], [ "e", "fc4f4cb58c9c21d3455922513a88324ea221b7812ee23a7a2c943ebd4cba3ff5", "", "reply" ], [ "p", "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425" ] ], "content": "📅 Original date posted:2018-11-26\n📝 Original message:\nThis shouldn't be problem, as the invoice will already indicate that the\nnode supports BaseAMP. If you have a reason to not reveal that you support\nBAMP for certain invoices, you'll just not specify it in the invoice, and\nact non-BAMPy when receiving payments to this payment hash.\n\nOf course, this will also be opt-in for both sides and won't affect\nexisting nodes in any way.\n\nCheers,\nJohan\n\nOn Wed, Nov 21, 2018 at 11:54 PM Rusty Russell \u003crusty at rustcorp.com.au\u003e\nwrote:\n\n\u003e Johan Torås Halseth \u003cjohanth at gmail.com\u003e writes:\n\u003e \u003e Seems like we can restrict the changes to BOLT11 by having the receiver\n\u003e \u003e assume NAMP for incoming payments \u003c invoice_amount. (with some timeout of\n\u003e \u003e course, but that would need to be the case even when the sender is\n\u003e \u003e signalling NAMP).\n\u003e\n\u003e This would effectively become a probe for Base AMP; if you get a partial\n\u003e payment error, it's because the recipient didn't support Base AMP.\n\u003e\n\u003e Seems cleaner to have a flag, both on BOLT11 and inside the onion. Then\n\u003e it's explicitly opt-in for both sides and doesn't affect existing nodes\n\u003e in any way.\n\u003e\n\u003e Cheers,\n\u003e Rusty.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181126/67166a9b/attachment.html\u003e", "sig": "687b83f12750c027fb878520ae612b0553271cb5990c98503e6057062dfc2222cfe380e1d73e6cf1810cb1d71ba904868c849d86ebd63f4a1b814499f34d56b0" }