Good morning,
I believe this is simply an argument about meanings of words; to me spontaneous
means that the payee does not generate a new secret to be sold as a valuable
good in exchange for money, using the mechanisms for routing on Lightning.
In any case, it would still be possible to perform an OG AMP payment without an
invoice of any sort at all, which is the entire point of the sentence; there
might not exist an invoice to put the "I support OG AMP" bit in.
Regards,
ZmnSCPxj
Sent with [ProtonMail](https://protonmail.com) Secure Email.
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Friday, November 16, 2018 11:32 AM, Olaoluwa Osuntokun <laol...@gmail.com>
wrote:
>> 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@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 <ru...@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@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>> _______________________________________________
>> Lightning-dev mailing list
>> Lightning-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
