From laolu32 at gmail.com Fri Nov 16 03:32:40 2018 From: laolu32 at gmail.com (Olaoluwa Osuntokun) Date: Thu, 15 Nov 2018 19:32:40 -0800 Subject: [Lightning-dev] Approximate assignment of option names: please fix! In-Reply-To: References: <87o9atrh59.fsf@rustcorp.com.au> Message-ID: > 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: