Hi ZmnSCPxj and Stepan, Thanks for all the feedback!
I think doing encrypt-then-mac on chunks of the data would be a great addition for users to be able to authenticate that they received the intended data. > Any node on the route of the payment knows the preimage and can decrypt the data. It would be nice to tune the protocol in a way that only the buyer can decrypt the data. For example we could use something like this: Is this not covered by sending over the pre-image encrypted data over a secure channel such as HTTPS? If anyone along the route who learns the pre-image does intercept the message with the encrypted data, that data will already be encrypted for the intended recipient right? > Perhaps we can add Lightning Application Protocol Proposals (LAPP) repository somewhere. I agree that it would be awesome if there was a good place to put these kinds of proposals on a git repository someplace! And finally in reply to all things about trusting the data provider, this proposal is intended for use cases in which a data provider is trusted (for example, DLC oracle signatures). Of course it would be super interesting if there was any way to do this with any kind of validation on the encrypted data before payment. Best, Nadav On Wed, Jun 26, 2019 at 4:36 AM ZmnSCPxj <zmnsc...@protonmail.com> wrote: > Good morning Stepan, > > > But it depends on the application and communication channel, so I would > leave these details to the app developers. > > I would mildly disagree, as I worry about proliferation of incompatible > applications, or applications that can only work with specific wallets. > > Still, it can be argued that this is early times for such applications, > and the extra creativity may be more important for exploring the space than > a premature optimization of working on a single standard. > > > > > P.S. It would be nice to have this proposal and other interesting ideas > from the mailing list in some kind of guidelines for different lightning > use-cases, but I feel like BOLTs repo is the wrong place to put it. Could > we organize some kind of lightning-guidelines repo for lapp developers? I > think it would be very useful. > > This seems a good idea. > > Perhaps we can add Lightning Application Protocol Proposals (LAPP) > repository somewhere. > This would be dependent on BOLT, but BOLT would not depend on LAPP. > > Probably the existing protocols like WebLN and Thor would be in scope for > this. > > --- > > On the original topic: > > A concern I raised is the issue that data providers must be trusted to > actually provide the data. > Unfortunately, I cannot derive a good way for a data consumer to prove > that the data given by a data provider is bogus. > It becomes an assertion and counter-assertion (the problem with reputation > systems). > > An escrow system might be useful, but requires us to have some way of > integrating escrow with proof-of-payment. > (and it seems we need to *really* switch to payment points / scalars to > combine proof-of-payment with a lot of features... this is delayed by > Bitcoin getting Schnorr, unless we want to step up now and use 2p-ECDSA > today, then reimplement under Schnorr when Bitcoin gets it (my > understanding is that Schnorr Scriptless Script has more security than > 2p-ECDSA Scriptless Script, though I am not a mathist and cannot show this)) > > Regards, > ZmnSCPxj >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
