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