[Lightning-dev] Approximate assignment of option names: please fix!

[Olaoluwa Osuntokun]

> 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>