Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Matt Corallo]

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 via Lightning-dev 
>>  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  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 
>> > > >  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 
>> > > >  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 
>> > > > > >  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 
>> > > > > >  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 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Andrés G . Aragoneses]

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 *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 
> 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.mazumdar1...@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-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
> > > > > > > > > wrote:
> > > > > > > >
> > > > > > > > On 11/9/19 4:31 AM, Takaya Imai 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Subhra Mazumdar]

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* 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".
> !
>
> 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 
> 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.mazumdar1...@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-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
> > > > > > > > > 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
> > > > > > > > 
> > > > > > > >
> 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[ZmnSCPxj via Lightning-dev]

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".
!

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  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 
> > >  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  
> > > 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 
> > > > >  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 
> > > > >  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  > > > > > > > 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
> > > > > > >     
> > > > > > >     
> > > > > > >https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> > > > > > >
> > > > >
> > > > > --
> > > > > Yours sincerely,
> > > > > Subhra Mazumdar.
> > >
> > > --
> > > Yours sincerely,
> > > Subhra 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Subhra Mazumdar]

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  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 
> 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 
> 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 
>> 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 
>> 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 >> > > 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
>>> > 
>>> > 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

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Matt Corallo]

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  
> 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  
>> 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  
 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  
 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 >>> > > 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
 > 
 > 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

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Subhra Mazumdar]

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 
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 
> 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 
> 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 > > > 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
>> > 
>> > 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

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Matt Corallo]

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  
> 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  
>> 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 > > > 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
>> > 
>> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>> > 
> 
> 
> -- 
> Yours sincerely,
> Subhra Mazumdar.
> 
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[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 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  > > 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
> > 
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> >
>


-- 
Yours sincerely,
Subhra Mazumdar.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Matt Corallo]

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  > 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
> 
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
> 
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Subhra Mazumdar]

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 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
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Matt Corallo]

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
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Takaya Imai]

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 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 decorrelation, the summed blinding factor (i.e. the
> data sent in response to ACK in Stuckless) can be used to send data to the
> payee, by using an encryption key as well.
>
>
> Regards,
> ZmnSCPxj
>
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Subhra Mazumdar]

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 the DLAS-up protocol.
The protocol uses OG AMP so the payments and data transfers are revoked in
case that it fails"

I am talking about different iterations. If it's the case that you have a
5GB file then you are sending 256bit via each path. May be in one iteration
you are able to send some 200 byte (assuming we get 8 paths at a time). So
it's the case that you need 5GB/200B iterations. But og amp guarantees
atomic delivery for blocks per iteration right and not for all the
iterations taken together ? Also how do you ensure correctness of the file
shared (using Zk proof ?) ?








On Mon, Jan 20, 2020, 12:03 Takaya Imai 
wrote:

> 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 have sufficient number of path to
> transfer all the blocks at one go because of preimage size limitation of
> 256 bit (I didn't get the point that there is no limitation on data size,
> can anyone explain that ?).
>
> Yes. It needs many blocks and paths if large file.
> But it has no problem because it can use the same path several times.
>
> Of course it needs much money to transfer large file. But this is good
> point in order to retain lightning network stable.
>
> For DOS attack, OG AMP has the same problem. It might that recipient needs
> a limit how many split blocks the recipient accept
>
> > So may be you need several iteration and I presume thats what lightning
> network will pitch in where we have several such microtransactions going on.
> >.
>
> Thanks,
> Takaya Imai
>
> 2020年1月16日(木) 16:14 Subhra Mazumdar :
>
>> 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 payment. But
>> it might be the case you may not have sufficient number of path to transfer
>> all the blocks at one go because of preimage size limitation of 256 bit (I
>> didn't get the point that there is no limitation on data size, can anyone
>> explain that ?). So may be you need several iteration and I presume thats
>> what lightning network will pitch in where we have several such
>> microtransactions going on. 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 ?
>>
>> On Mon, Nov 11, 2019 at 6:29 AM Takaya Imai <
>> takaya.i...@frontier-ptnrs.com> wrote:
>>
>>> Hi all,
>>>
>>> I propose Data Lightning Atomic Swap.
>>> Anyone already have the same idea?
>>>
>>>
>>> [Abstract]
>>> This proposal is a way to swap data and lightning payment atomically.
>>> It has two patterns, one is for a payer to swap data-download with
>>> lightning payment to a payee (DLAS-down), the other is for a payer to swap
>>> data-upload with lightning payment to a payee (DLAS-up).
>>>
>>> The data is embedded to preimage so sending and receiving the data need
>>> lightning payment at the same time.
>>>
>>> -
>>>
>>> [Motivation]
>>> Atomic Swaps among crypto currencies has various ways to implement
>>> (on-chain to on-chain[1], on-chain to of-chain(Submarine Swap[2])). And
>>> Atomic Swaps between data and crypto currencies are also proposed as a part
>>> of TumbleBit mechanism[3], Storm mechanism[4] and so on.
>>>
>>> Recently Joost Jager proposed Instant messages with lightning onion
>>> routing, whatsat[5], which use recent sphinx payload change[6]. This is
>>> very awesome but not atomic with lightning payment.
>>>
>>> Atomic lightning mechanism for data is useful in use cases below.
>>>
>>> -
>>>
>>> [Pros & Cons]
>>>
>>> * DLAS-down
>>> ** Pros
>>> *** Atomic data download exchange with lightning payment
>>> ** Cons
>>> *** It needs better mechanism to expand data size
>>>
>>> * DLAS-up
>>> ** Pros
>>> *** Atomic data upload exchange with lightning payment
>>> ** Cons
>>> *** OG AMP[7] is needed to implement
>>>
>>> -
>>>
>>> [What I describe]
>>> * A way to swap data with lightning payment atomically.
>>>
>>> -
>>>
>>> [What I do not describe]
>>> * A way to detect that data is correct or not, namely zero knowledge
>>> proof process.
>>>
>>> For example, probabilistic checkable proof like TumbleBit[3] proposed.
>>> Just message as data is no problem because no need to check the 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Takaya Imai]

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 have sufficient number of path to
transfer all the blocks at one go because of preimage size limitation of
256 bit (I didn't get the point that there is no limitation on data size,
can anyone explain that ?).

Yes. It needs many blocks and paths if large file.
But it has no problem because it can use the same path several times.

Of course it needs much money to transfer large file. But this is good
point in order to retain lightning network stable.

For DOS attack, OG AMP has the same problem. It might that recipient needs
a limit how many split blocks the recipient accept

> So may be you need several iteration and I presume thats what lightning
network will pitch in where we have several such microtransactions going on.
> 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 the DLAS-up protocol.
The protocol uses OG AMP so the payments and data transfers are revoked in
case that it fails.

Thanks,
Takaya Imai

2020年1月16日(木) 16:14 Subhra Mazumdar :

> 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 payment. But
> it might be the case you may not have sufficient number of path to transfer
> all the blocks at one go because of preimage size limitation of 256 bit (I
> didn't get the point that there is no limitation on data size, can anyone
> explain that ?). So may be you need several iteration and I presume thats
> what lightning network will pitch in where we have several such
> microtransactions going on. 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 ?
>
> On Mon, Nov 11, 2019 at 6:29 AM Takaya Imai <
> takaya.i...@frontier-ptnrs.com> wrote:
>
>> Hi all,
>>
>> I propose Data Lightning Atomic Swap.
>> Anyone already have the same idea?
>>
>>
>> [Abstract]
>> This proposal is a way to swap data and lightning payment atomically.
>> It has two patterns, one is for a payer to swap data-download with
>> lightning payment to a payee (DLAS-down), the other is for a payer to swap
>> data-upload with lightning payment to a payee (DLAS-up).
>>
>> The data is embedded to preimage so sending and receiving the data need
>> lightning payment at the same time.
>>
>> -
>>
>> [Motivation]
>> Atomic Swaps among crypto currencies has various ways to implement
>> (on-chain to on-chain[1], on-chain to of-chain(Submarine Swap[2])). And
>> Atomic Swaps between data and crypto currencies are also proposed as a part
>> of TumbleBit mechanism[3], Storm mechanism[4] and so on.
>>
>> Recently Joost Jager proposed Instant messages with lightning onion
>> routing, whatsat[5], which use recent sphinx payload change[6]. This is
>> very awesome but not atomic with lightning payment.
>>
>> Atomic lightning mechanism for data is useful in use cases below.
>>
>> -
>>
>> [Pros & Cons]
>>
>> * DLAS-down
>> ** Pros
>> *** Atomic data download exchange with lightning payment
>> ** Cons
>> *** It needs better mechanism to expand data size
>>
>> * DLAS-up
>> ** Pros
>> *** Atomic data upload exchange with lightning payment
>> ** Cons
>> *** OG AMP[7] is needed to implement
>>
>> -
>>
>> [What I describe]
>> * A way to swap data with lightning payment atomically.
>>
>> -
>>
>> [What I do not describe]
>> * A way to detect that data is correct or not, namely zero knowledge
>> proof process.
>>
>> For example, probabilistic checkable proof like TumbleBit[3] proposed.
>> Just message as data is no problem because no need to check the message
>> is correct or not.
>>
>> * A way in case that different preimages are used in a payment route like
>> Multi-hop locks.
>>
>> -
>>
>> [Specification]
>>
>> Lightning Network(LN) has a mechanism about preimage like a brief image
>> below.
>>
>> Payer Mediators
>>  Payee
>>
>> =
>>
>> Preimage
>> Preimage Hash  <- invoice 
>>  Preimage Hash
>> Preimage Hash  >   Preimage Hash >
>>  Preimage Hash
>> Preimage   <—-—-   Preimage  <
>>  Preimage
>>
>> As you know, preimage Payer gets can be 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[Subhra Mazumdar]

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 payment. But it
might be the case you may not have sufficient number of path to transfer
all the blocks at one go because of preimage size limitation of 256 bit (I
didn't get the point that there is no limitation on data size, can anyone
explain that ?). So may be you need several iteration and I presume thats
what lightning network will pitch in where we have several such
microtransactions going on. 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 ?

On Mon, Nov 11, 2019 at 6:29 AM Takaya Imai 
wrote:

> Hi all,
>
> I propose Data Lightning Atomic Swap.
> Anyone already have the same idea?
>
>
> [Abstract]
> This proposal is a way to swap data and lightning payment atomically.
> It has two patterns, one is for a payer to swap data-download with
> lightning payment to a payee (DLAS-down), the other is for a payer to swap
> data-upload with lightning payment to a payee (DLAS-up).
>
> The data is embedded to preimage so sending and receiving the data need
> lightning payment at the same time.
>
> -
>
> [Motivation]
> Atomic Swaps among crypto currencies has various ways to implement
> (on-chain to on-chain[1], on-chain to of-chain(Submarine Swap[2])). And
> Atomic Swaps between data and crypto currencies are also proposed as a part
> of TumbleBit mechanism[3], Storm mechanism[4] and so on.
>
> Recently Joost Jager proposed Instant messages with lightning onion
> routing, whatsat[5], which use recent sphinx payload change[6]. This is
> very awesome but not atomic with lightning payment.
>
> Atomic lightning mechanism for data is useful in use cases below.
>
> -
>
> [Pros & Cons]
>
> * DLAS-down
> ** Pros
> *** Atomic data download exchange with lightning payment
> ** Cons
> *** It needs better mechanism to expand data size
>
> * DLAS-up
> ** Pros
> *** Atomic data upload exchange with lightning payment
> ** Cons
> *** OG AMP[7] is needed to implement
>
> -
>
> [What I describe]
> * A way to swap data with lightning payment atomically.
>
> -
>
> [What I do not describe]
> * A way to detect that data is correct or not, namely zero knowledge proof
> process.
>
> For example, probabilistic checkable proof like TumbleBit[3] proposed.
> Just message as data is no problem because no need to check the message is
> correct or not.
>
> * A way in case that different preimages are used in a payment route like
> Multi-hop locks.
>
> -
>
> [Specification]
>
> Lightning Network(LN) has a mechanism about preimage like a brief image
> below.
>
> Payer Mediators
>  Payee
>
> =
>
> Preimage
> Preimage Hash  <- invoice 
>  Preimage Hash
> Preimage Hash  >   Preimage Hash >
>  Preimage Hash
> Preimage   <—-—-   Preimage  <
>  Preimage
>
> As you know, preimage Payer gets can be a proof of payment because Payer
> can not get it if the payment is executed correctly.
>
>
>
> 1, Data download <->  lightning (DLAS-down)
>
>
> Payer sends lightning payment and receives data from Payee atomically.
>
>
> Payer Mediators
>  Payee
>
> =
> Payer Channel Pubkey <--->
> Payee Channel Pubkey
>
>
>  data(256bit, padded)
>
>  enc_key = (Payee Channel Secret Key * Payer Channel Pubkey).x  (256bit)
> enc_key = (Payer Channel Secret Key * Payee Channel Pubkey).x  (256bit)
>
>  enc_data = data XOR enc_key
> sha256(enc_data) <- invoice --
> sha256(enc_data)
> sha256(enc_data) > sha256(enc_data) ->
> sha256(enc_data)
> enc_data < enc_data <-
> enc_data
> data = enc_data XOR enc_key
>
>
> * The size of data is restricted to 256 bits. Identically, it should be
> extended to larger data and the data should be transferred in several
> payment paths like DLAS-up.
> * Channel Pubkey is only one for one channel and the data can be decrypted
> if enc_key is leaked. So enc_key should be generated newly every time by a
> way like hash chain but the protocol image above is just example for
> simplicity.
> * .x means X axis value of points on Elliptic Curve.
> * If data is less than 256 bits, then 0x00 is padded (I am not sure which
> of big endian and little endian is better).
>
>
>
> 2, Data 

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

[ZmnSCPxj via Lightning-dev]

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 decorrelation, the summed blinding factor (i.e. the data 
sent in response to ACK in Stuckless) can be used to send data to the payee, by 
using an encryption key as well.


Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev