Indeed. To go further, anything where the file can be proven correct under a zkSNARK (ie you can write a relatively simple program to do so) does not bear such an issue.
> On Jan 21, 2020, at 02:38, Andrés G. Aragoneses <kno...@gmail.com> wrote: > > > Hey ZmnSCPxj, > >> On Tue, 21 Jan 2020 at 08:47, ZmnSCPxj via Lightning-dev >> <lightning-dev@lists.linuxfoundation.org> 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". > > I wanted to ask a simple question with regards to the NeverGonnaGiveYouUp > problem. > Let's say you use this technology for a specific use case subset of what has > been proposed: the payer wants to exchange bitcoin (via LN) in exchange for > some data. The data, in this case, was known by the payer at some point in > the past, so the payer encrypted it with his own private key, and gave it to > someone for backup purposes (after that, he gets a hash of the data, which > she keeps, and deletes the data from her end). At some point in the future, > when she wants to retrieve the data, the payee can only supply a bunch of > bytes whose hash match with the hash that the payer has, therefore the > NeverGonnaGiveYouUp problem can't happen here, am I right? > > Thanks > > >> ! >> >> 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 <lf-li...@mattcorallo.com> 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.mazumdar1...@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-li...@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.mazumdar1...@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-li...@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-li...@mattcorallo.com >> > > > > > > > <mailto:lf-li...@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@lists.linuxfoundation.org >> > > > > > > > <mailto:Lightning-dev@lists.linuxfoundation.org> >> > > > > > > > >> > > > > > > > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev >> > > > > > > > >> > > > > > >> > > > > > -- >> > > > > > Yours sincerely, >> > > > > > Subhra Mazumdar. >> > > > >> > > > -- >> > > > Yours sincerely, >> > > > Subhra Mazumdar. >> >> >> _______________________________________________ >> Lightning-dev mailing list >> Lightning-dev@lists.linuxfoundation.org >> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > _______________________________________________ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
