📅 Original date posted:2018-11-16
📝 Original message:
> OG AMP is inherently spontaneous in nature, therefore invoice might not
exist
> to put the feature on.
That is incorrect. One can use an invoice along with AMP as is, in order to
tag
a payment. As an example, I want to deposit to an exhcange, so I get an
invoice
from them. I note that the invoice has a special (new) field that indicates
they accept AMP payments, and include an 8-byte identifier. Each of the
payment
shards I send over to the exchange will carry this 8-byte identifier.
Inclusion
of this identifier signals to them to credit my account with the deposit
once
all the payments arrive. This generalizes to any case where a service or
good
is to be dispersed once a payment is received.
-- Laolu
On Mon, Nov 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> wrote:
> Good Morning Rusty,
>
> OG AMP is inherently spontaneous in nature, therefore invoice might not
> exist to put the feature on.
> Thus it should be global feature.
>
> Do we tie spontaneous payment to OG AMP or do we support one which is
> payable by base AMP or normal singlepath?
>
> Given that both `option_switch_ephkey` and `option_og_amp` require
> understanding extended onion packet types, would it not be better to merge
> them into `option_extra_onion_packet_types`?
>
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> On Tuesday, November 13, 2018 7:49 AM, Rusty Russell <
> rusty at blockstream.com> wrote:
>
> > Hi all,
> >
> > I went through the wiki and made up option names (not yet
> > numbers, that comes next). I re-read our description of global vs local
> > bits:
> >
> > The feature masks are split into local features (which only
> > affect the protocol between these two nodes) and global features
> > (which can affect HTLCs and are thus also advertised to other
> > nodes).
> >
> > You might want to promote your local bit to a global bit so you can
> > advertize them (wumbo?)? But if it's expected that every node will
> > eventually support a bit, then it should probably stay local.
> >
> > Please edit your bits as appropriate, so I can assign bit numbers soon:
> >
> >
> https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States
> >
> > Thanks!
> > Rusty.
> >
> > Lightning-dev mailing list
> > Lightning-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/5940c292/attachment.html>;
Olaoluwa Osuntokun [ARCHIVE] /
npub19h…zkvn4
2023-06-09 12:52:37
in reply to nevent1q…el5q
Author Public Key
npub19helcfnqgk2jrwzjex2aflq6jwfc8zd9uzzkwlgwhve7lykv23mq5zkvn4Published at
2023-06-09 12:52:37Event JSON
{
"id": "89d730a684aafdae7c0905d5720430498e47ff3c9ef83a19bf1cbd2e782a0552",
"pubkey": "2df3fc2660459521b852c995d4fc1a93938389a5e085677d0ebb33ef92cc5476",
"created_at": 1686315157,
"kind": 1,
"tags": [
[
"e",
"7e19675ce2d9059ad28b8c6d674e5062c9c3e08808be8a20aebc7b4c921800e3",
"",
"root"
],
[
"e",
"d4cf275e537160c64badfe29e2b1979b77ceb034630d5c660e405f7319a34e88",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2018-11-16\n📝 Original message:\n\u003e OG AMP is inherently spontaneous in nature, therefore invoice might not\nexist\n\u003e to put the feature on.\n\nThat is incorrect. One can use an invoice along with AMP as is, in order to\ntag\na payment. As an example, I want to deposit to an exhcange, so I get an\ninvoice\nfrom them. I note that the invoice has a special (new) field that indicates\nthey accept AMP payments, and include an 8-byte identifier. Each of the\npayment\nshards I send over to the exchange will carry this 8-byte identifier.\nInclusion\nof this identifier signals to them to credit my account with the deposit\nonce\nall the payments arrive. This generalizes to any case where a service or\ngood\nis to be dispersed once a payment is received.\n\n-- Laolu\n\n\nOn Mon, Nov 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev \u003c\nlightning-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Good Morning Rusty,\n\u003e\n\u003e OG AMP is inherently spontaneous in nature, therefore invoice might not\n\u003e exist to put the feature on.\n\u003e Thus it should be global feature.\n\u003e\n\u003e Do we tie spontaneous payment to OG AMP or do we support one which is\n\u003e payable by base AMP or normal singlepath?\n\u003e\n\u003e Given that both `option_switch_ephkey` and `option_og_amp` require\n\u003e understanding extended onion packet types, would it not be better to merge\n\u003e them into `option_extra_onion_packet_types`?\n\u003e\n\u003e\n\u003e\n\u003e Sent with ProtonMail Secure Email.\n\u003e\n\u003e ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐\n\u003e On Tuesday, November 13, 2018 7:49 AM, Rusty Russell \u003c\n\u003e rusty at blockstream.com\u003e wrote:\n\u003e\n\u003e \u003e Hi all,\n\u003e \u003e\n\u003e \u003e I went through the wiki and made up option names (not yet\n\u003e \u003e numbers, that comes next). I re-read our description of global vs local\n\u003e \u003e bits:\n\u003e \u003e\n\u003e \u003e The feature masks are split into local features (which only\n\u003e \u003e affect the protocol between these two nodes) and global features\n\u003e \u003e (which can affect HTLCs and are thus also advertised to other\n\u003e \u003e nodes).\n\u003e \u003e\n\u003e \u003e You might want to promote your local bit to a global bit so you can\n\u003e \u003e advertize them (wumbo?)? But if it's expected that every node will\n\u003e \u003e eventually support a bit, then it should probably stay local.\n\u003e \u003e\n\u003e \u003e Please edit your bits as appropriate, so I can assign bit numbers soon:\n\u003e \u003e\n\u003e \u003e\n\u003e https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States\n\u003e \u003e\n\u003e \u003e Thanks!\n\u003e \u003e Rusty.\n\u003e \u003e\n\u003e \u003e Lightning-dev mailing list\n\u003e \u003e Lightning-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181115/5940c292/attachment.html\u003e",
"sig": "085cd4a69263c09526c33a4ea855fd73d4e80f1613335b36ea98a4da34bd3f5bd70026ad13af37040d1d716fdc51bda24f4cd2a400f5f4aa68674716335dd808"
}