Subhra Mazumdar [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-20 📝 Original message: Thanks for the link. I ...
📅 Original date posted:2020-01-20
📝 Original message:
Thanks for the link. I will have a look.
On Tue, Jan 21, 2020, 06:17 ZmnSCPxj <ZmnSCPxj at protonmail.com> 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 <lf-lists at 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.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
> > > > > > > > <mailto: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
> > > > > > > > <mailto: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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200121/b167ddfe/attachment-0001.html>;
📝 Original message:
Thanks for the link. I will have a look.
On Tue, Jan 21, 2020, 06:17 ZmnSCPxj <ZmnSCPxj at protonmail.com> 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 <lf-lists at 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.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
> > > > > > > > <mailto: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
> > > > > > > > <mailto: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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200121/b167ddfe/attachment-0001.html>;