Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2020-01-20 📝 Original message: Zk proofs are incredibly ...
📅 Original date posted:2020-01-20
📝 Original message:
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200120/e6281052/attachment.html>;
📝 Original message:
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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200120/e6281052/attachment.html>;