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
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
>
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
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
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
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
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
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
Good morning list,
I'd like to explore some enhancements for unannounced (sometimes called
private) channels.
Unannounced channels are really useful for mobile nodes that won't be
online often enough to route
payments. That does leak information to your channel peer, but that's a
topic for
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*
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
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
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
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
15 matches
Mail list logo