Andrés G. Aragoneses [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-21 📝 Original message: Hey ZmnSCPxj, On Tue, 21 ...
đź“… Original date posted:2020-01-21
đź“ť Original message:
Hey ZmnSCPxj,
On Tue, 21 Jan 2020 at 08:47, ZmnSCPxj via Lightning-dev <
lightning-dev at 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-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.
>
>
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200121/b6c831d6/attachment.html>;
đź“ť Original message:
Hey ZmnSCPxj,
On Tue, 21 Jan 2020 at 08:47, ZmnSCPxj via Lightning-dev <
lightning-dev at 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-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.
>
>
> _______________________________________________
> 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: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200121/b6c831d6/attachment.html>;