From subhra.mazumdar1993 at gmail.com Tue Jan 21 01:47:49 2020 From: subhra.mazumdar1993 at gmail.com (Subhra Mazumdar) Date: Tue, 21 Jan 2020 07:17:49 +0530 Subject: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up) In-Reply-To: <92nMFP5_JAhcRRk18RFu5xugvpCxz5HtKlm6UdMiQzLDSboMp-e8GjBYOjbnpJLjUpdbucxu_79vbdYZCFWZqgZ8NErVqfZ8dxkXK5O8U_U=@protonmail.com> References: <56699413-2A38-4B09-9EAA-D95C84DF2CA4@mattcorallo.com> <92nMFP5_JAhcRRk18RFu5xugvpCxz5HtKlm6UdMiQzLDSboMp-e8GjBYOjbnpJLjUpdbucxu_79vbdYZCFWZqgZ8NErVqfZ8dxkXK5O8U_U=@protonmail.com> Message-ID: Thanks for the link. I will have a look. On Tue, Jan 21, 2020, 06:17 ZmnSCPxj wrote: > Good morning Subhra, > > Refer to this protocol instead of DLAS: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html > In this protocol, an *encrypted* form of the *entire file* is sent. > Consequently, a *single* payment is made, where the payment preimage is > the decryption key. > Knowing an additional zk proof is necessary to show that the file is > indeed encrypted using the decryption key that is the preimage of the given > hash (the linked thread has details I believe). > > Relevantly, there is no need to consider blocks of a file when using the > linked protocol instead of DLAS. > Of course, a Zk-proof of some property of the entire file, that can be > understood by an end-user, may not be possible. > Likely, you might want to prove of a video file that a thumbnail of the > video file is extracted from a frame of the video, and show that thumbnail > to the end-user. > Looking at the *rest* of the frames of the video (after you have paid for > its decryption) may very reveal them to be frames of a video of Rick Astley > singing "Never Gonna Give You Up". > ! > > Regards, > ZmnSCPxj > > > So is it sufficient to give a zk proof of the entire file and not of the > individual blocks which are transferred at each iteration? Also does it > make sense that you make partial payment per block instead of waiting for > the total file to arrive. It might be the case that the zk proof of the > total file is correct but then sender might cheat while sending individual > block. > > > > On Tue, Jan 21, 2020, 00:26 Matt Corallo > wrote: > > > > > Don?t and data in lighting payments unless you have to. It?s super > DoS-y and rude to your peers. If you?re just transferring a file, you can > use ZKCP to send an encrypted copy of the file with the encryption key > being the payment_preimage, making the whole thing one big atomic action. > > > > > > > On Jan 20, 2020, at 13:33, Subhra Mazumdar < > subhra.mazumdar1993 at gmail.com> wrote: > > > > > > > ? > > > > Sounds good. But how do I provide a correctness for the entire asset > to be transferred when I am already partitioning into several units (say > chunks of file ? ) So as an when the block of file is received then we have > to give a ZK proof "block x is part of File F". Is it how this should work ? > > > > > > > > On Mon, Jan 20, 2020 at 11:59 PM Matt Corallo < > lf-lists at mattcorallo.com> wrote: > > > > > > > > > Zk proofs are incredibly fast these days for small-ish programs. > They?re much too slow for a consensus system where every party needs to > download and validate them, but for relatively simple programs a two-party > system using them is very doable. > > > > > > > > > > > On Jan 20, 2020, at 13:23, Subhra Mazumdar < > subhra.mazumdar1993 at gmail.com> wrote: > > > > > > > > > > > ? > > > > > > But isn't it that the use of ZK proof will render the system > slow and hence defy the very purpose of lightning network which intends to > make things scalable as well as faster transaction ? > > > > > > > > > > > > On Mon, Jan 20, 2020 at 11:48 PM Matt Corallo < > lf-lists at mattcorallo.com> wrote: > > > > > > > > > > > > > That paper discusses it, but I don't think there was ever a > paper proper > > > > > > > on ZKCP. There are various discussions of it, though, if you > google. > > > > > > > Sadly this is common in this space - lots of great ideas where > no one > > > > > > > ever bothered to write academic-style papers about them (hence > why > > > > > > > academic papers around Bitcoin tend to miss nearly all > relevant context, > > > > > > > sadly). > > > > > > > > > > > > > > Matt > > > > > > > > > > > > > > On 1/20/20 6:10 PM, Subhra Mazumdar wrote: > > > > > > > > Are you referring to the paper Zero knowledge contingent > payment > > > > > > > > revisited ? I will look into the construction. Thanks for the > > > > > > > > information! :) > > > > > > > > > > > > > > > > On Mon, Jan 20, 2020, 23:31 Matt Corallo < > lf-lists at mattcorallo.com > > > > > > > > > wrote: > > > > > > > > > > > > > > > > On 11/9/19 4:31 AM, Takaya Imai wrote: > > > > > > > > > [What I do not describe] > > > > > > > > > * A way to detect that data is correct or not, namely > zero knowledge > > > > > > > > > proof process. > > > > > > > > > > > > > > > > Have you come across Zero Knowledge Contingent Payments? > Originally it > > > > > > > > was designed for on-chain applications but it slots > neatly into > > > > > > > > lightning as it only requires a method to lock funds to > a hash preimage. > > > > > > > > > > > > > > > > Matt > > > > > > > > _______________________________________________ > > > > > > > > Lightning-dev mailing list > > > > > > > > Lightning-dev at lists.linuxfoundation.org > > > > > > > > > > > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > > > > > > > > > > > > > > > > > > > -- > > > > > > Yours sincerely, > > > > > > Subhra Mazumdar. > > > > > > > > -- > > > > Yours sincerely, > > > > Subhra Mazumdar. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: