ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2018-11-16 📝 Original message: Good morning, I believe ...
📅 Original date posted:2018-11-16
📝 Original message:
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 <laolu32 at 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 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/20181116/115c2abd/attachment.html>;
📝 Original message:
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 <laolu32 at 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 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/20181116/115c2abd/attachment.html>;