> 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 < [email protected]> 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 < > [email protected]> 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 > > [email protected] > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > _______________________________________________ > Lightning-dev mailing list > [email protected] > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >
_______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
