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 wrote:
>
>
> Hey ZmnSCPxj,
>
>> On Tue, 21 Jan 2020 at 08:47, ZmnSCPxj
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
Thanks for the link. I will have a look.
On Tue, Jan 21, 2020, 06:17 ZmnSCPxj 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*
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
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
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
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
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
>
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
wrote:
> That paper discusses it, but I don't think there
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
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 wrote:
> On 11/9/19 4:31 AM, Takaya Imai wrote:
> > [What I do not describe]
> > * A way to detect that data is
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
Hi ZmnSCPxj,
Sorry for late reply.
The no restriction version is very good.
Thanks,
Takaya Imai
2019年11月12日(火) 9:13 ZmnSCPxj :
> Good morning Imai-san,
>
> I believe for the download case this is superior:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html
> This
Thanks Takaya for clearing my doubts. Regarding the answer to the question
"What happens if it fails in an iteration ? So the recipient of the file
remains happy with the partial content ? Or will the payment be revoked
(not sure how) if recipient doesn't get the full content ?
This is about
Hi Subhra,
thanks for your question.
> So as of now if we consider transfer of a file (may of few KB) then you
split it into several blocks and use atomic multi path payment whole using
the blocks for embedding with the preimage inorder to obtain payment.
> But it might be the case you may not
Hello Takaya,
I really liked the idea of data atomic swap mentioned over here. So
as of now if we consider transfer of a file (may of few KB) then you split
it into several blocks and use atomic multi path payment whole using the
blocks for embedding with the preimage inorder to obtain
Good morning Imai-san,
I believe for the download case this is superior:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-June/002035.html
This has no restriction on the size of the data.
For the upload case, it seems for either OG AMP or with payment points +
scalars and payment
17 matches
Mail list logo
