<div dir="ltr"><div>&gt; OG AMP is inherently spontaneous in nature, therefore invoice might not exist</div><div>&gt; to put the feature on.</div><div><br></div><div>That is incorrect. One can use an invoice along with AMP as is, in order to tag</div><div>a payment. As an example, I want to deposit to an exhcange, so I get an invoice</div><div>from them. I note that the invoice has a special (new) field that indicates</div><div>they accept AMP payments, and include an 8-byte identifier. Each of the payment</div><div>shards I send over to the exchange will carry this 8-byte identifier. Inclusion</div><div>of this identifier signals to them to credit my account with the deposit once</div><div>all the payments arrive. This generalizes to any case where a service or good</div><div>is to be dispersed once a payment is received.</div><div><br></div><div>-- Laolu</div><div><br></div><br><div class="gmail_quote"><div dir="ltr">On Mon, Nov 12, 2018 at 6:56 PM ZmnSCPxj via Lightning-dev &lt;<a href="mailto:lightning-dev@lists.linuxfoundation.org">lightning-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Good Morning Rusty,<br>
<br>
OG AMP is inherently spontaneous in nature, therefore invoice might not exist to put the feature on.<br>
Thus it should be global feature.<br>
<br>
Do we tie spontaneous payment to OG AMP or do we support one which is payable by base AMP or normal singlepath?<br>
<br>
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`?<br>
<br>
<br>
<br>
Sent with ProtonMail Secure Email.<br>
<br>
‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐<br>
On Tuesday, November 13, 2018 7:49 AM, Rusty Russell &lt;<a href="mailto:rusty@blockstream.com" target="_blank">rusty@blockstream.com</a>&gt; wrote:<br>
<br>
&gt; Hi all,<br>
&gt;<br>
&gt; I went through the wiki and made up option names (not yet<br>
&gt; numbers, that comes next). I re-read our description of global vs local<br>
&gt; bits:<br>
&gt;<br>
&gt; The feature masks are split into local features (which only<br>
&gt; affect the protocol between these two nodes) and global features<br>
&gt; (which can affect HTLCs and are thus also advertised to other<br>
&gt; nodes).<br>
&gt;<br>
&gt; You might want to promote your local bit to a global bit so you can<br>
&gt; advertize them (wumbo?)? But if it&#39;s expected that every node will<br>
&gt; eventually support a bit, then it should probably stay local.<br>
&gt;<br>
&gt; Please edit your bits as appropriate, so I can assign bit numbers soon:<br>
&gt;<br>
&gt; <a href="https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States" rel="noreferrer" target="_blank">https://github.com/lightningnetwork/lightning-rfc/wiki/Lightning-Specification-1.1-Proposal-States</a><br>
&gt;<br>
&gt; Thanks!<br>
&gt; Rusty.<br>
&gt;<br>
&gt; Lightning-dev mailing list<br>
&gt; <a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
<br>
<br>
_______________________________________________<br>
Lightning-dev mailing list<br>
<a href="mailto:Lightning-dev@lists.linuxfoundation.org" target="_blank">Lightning-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev</a><br>
</blockquote></div></div>