Subhra Mazumdar [ARCHIVE] on Nostr: ๐ Original date posted:2020-01-20 ๐ Original message: Thanks Takaya for ...
๐
Original date posted:2020-01-20
๐ Original message:
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 <takaya.imai at frontier-ptnrs.com>
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 <subhra.mazumdar1993 at gmail.com>:
>
>> 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.imai at 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 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 upload <-> lightning (DLAS-down)
>>>
>>> Payer sends data and lightning payment from Payee atomically.
>>> This is like OG AMP(Atomic Multi-path Payment)[7] system.
>>>
>>> Payer Mediators
>>> Payee
>>>
>>> =================================================================================
>>> data(512bit, padded)
>>>
>>> share1(256bit)
>>> share2(256bit)
>>>
>>> base_s = share1 XOR share2
>>> data1(256bit) || data2(256bit) = data(512bit)
>>> XOR_d1 = data1 XOR base_s
>>> XOR_d2 = data2 XOR base_s
>>> PreImg1 = sha256(base_s || data || 1)
>>> PreImg2 = sha256(base_s || data || 2)
>>>
>>> sha256(PreImg1), XOR_d1, share1 -> sha256(PreImg1), XOR_d1, share1 ->
>>> sha256(PreImg1), XOR_d1, share1
>>> sha256(PreImg2), XOR_d2, share2 -> sha256(PreImg2), XOR_d2, share2 ->
>>> sha256(PreImg2), XOR_d2, share1
>>>
>>>
>>> base s = share1 XOR share2
>>>
>>> data = (XOR_d1 XOR base_s) || (XOR_d2 XOR base_s)
>>>
>>> PreImg1 = sha256(base_s || data || 1)
>>>
>>> PreImg2 = sha256(base_s || data || 2)
>>>
>>> PreImg1 <------------------- PreImg1 <---------------------
>>> PreImg1
>>> PreImg2 <------------------- PreImg2 <---------------------
>>> PreImg2
>>>
>>>
>>> * This protocol example has 512 bits data and they are transferred in
>>> two paths. However, it can transfer larger data in several payment paths
>>> like [5].
>>> * || means string concatenation.
>>> * If data is less than 512 bits, then 0x00 is padded(I am not sure which
>>> of big endian and little endian is better).
>>>
>>>
>>> ---------
>>>
>>>
>>> [Use Cases]
>>>
>>> 1, Lightning Network ecosystem
>>>
>>> * Hosting Incentives like Acai Protocol
>>> ** Watchtower Hosting incentive, Backup Hosting incentive
>>> *** Commitment tx data sending to Data Host(DLAS-up)
>>> **** Commitment tx data is embedded in preimage so that Payer can not
>>> send the data without remittance
>>> *** Channel backup data receiving from Data Host(DLAS-down)
>>> **** Channel backup data is embedded in preimage so that Payer can not
>>> receive the data without remittance
>>>
>>> 2, Crypto currency Problems
>>>
>>> * Distributed secret key sharing (just come up with an idea though)
>>> ** As a key backup, one of secret key shares is distributed with
>>> encryption(DLAS-up) to some nodes, which nodes receive lightning payment as
>>> key managing fee. And the nodes send a proof for managing the key as
>>> response of bloom filter periodically, and exchange encrypted secret key
>>> share with lightning payment to asset holder(DLAS-down).
>>> ** For example 2 out of 3 multi signature key sharing, asset holder puts
>>> the first key, the custodial has the second key, and the third key at the
>>> lightning distribution nodes. Asset holders usually spend assets using
>>> their key and the key on Distributed Nodes.
>>>
>>>
>>> 3, Problems so far
>>>
>>> * Prevention email spam and DDoS attack with large data
>>> ** Payer can not send email or data without remittance(DLAS-up)
>>> ** Payer can not receive reply-email without remittance(DLAS-down)
>>>
>>> * Incentive of receiving advertisements on browser or desktop/mobile app
>>> ** Payer can not send advertisements without remittance(DLAS-up)
>>>
>>> * Bounty for code bug fixes based on cryptographic proofs or secret
>>> computations
>>> ** (DLAS-down)
>>>
>>>
>>>
>>> [References]
>>>
>>> [1] https://bitcointalk.org/index.php?topic=321228
>>> [2] https://twitter.com/roasbeef/status/964608261830750208
>>> [3] https://eprint.iacr.org/2016/575
>>> [4] https://github.com/storm-org/storm-spec
>>> [5] https://twitter.com/joostjgr/status/1190714028626251779
>>> [6] https://github.com/lightningnetwork/lightning-rfc/pull/619
>>> [7]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html
>>>
>>>
>>> document on github:
>>> https://github.com/takaya-imai/data_lightning_atomic_swap
>>>
>>> Best regards,
>>> Takaya Imai
>>> Email: takaya.imai at frontier-ptnrs.com, takaya.imai at unitedbitcoiners.com
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> 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/257e2885/attachment-0001.html>;
๐ Original message:
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 <takaya.imai at frontier-ptnrs.com>
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 <subhra.mazumdar1993 at gmail.com>:
>
>> 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.imai at 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 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 upload <-> lightning (DLAS-down)
>>>
>>> Payer sends data and lightning payment from Payee atomically.
>>> This is like OG AMP(Atomic Multi-path Payment)[7] system.
>>>
>>> Payer Mediators
>>> Payee
>>>
>>> =================================================================================
>>> data(512bit, padded)
>>>
>>> share1(256bit)
>>> share2(256bit)
>>>
>>> base_s = share1 XOR share2
>>> data1(256bit) || data2(256bit) = data(512bit)
>>> XOR_d1 = data1 XOR base_s
>>> XOR_d2 = data2 XOR base_s
>>> PreImg1 = sha256(base_s || data || 1)
>>> PreImg2 = sha256(base_s || data || 2)
>>>
>>> sha256(PreImg1), XOR_d1, share1 -> sha256(PreImg1), XOR_d1, share1 ->
>>> sha256(PreImg1), XOR_d1, share1
>>> sha256(PreImg2), XOR_d2, share2 -> sha256(PreImg2), XOR_d2, share2 ->
>>> sha256(PreImg2), XOR_d2, share1
>>>
>>>
>>> base s = share1 XOR share2
>>>
>>> data = (XOR_d1 XOR base_s) || (XOR_d2 XOR base_s)
>>>
>>> PreImg1 = sha256(base_s || data || 1)
>>>
>>> PreImg2 = sha256(base_s || data || 2)
>>>
>>> PreImg1 <------------------- PreImg1 <---------------------
>>> PreImg1
>>> PreImg2 <------------------- PreImg2 <---------------------
>>> PreImg2
>>>
>>>
>>> * This protocol example has 512 bits data and they are transferred in
>>> two paths. However, it can transfer larger data in several payment paths
>>> like [5].
>>> * || means string concatenation.
>>> * If data is less than 512 bits, then 0x00 is padded(I am not sure which
>>> of big endian and little endian is better).
>>>
>>>
>>> ---------
>>>
>>>
>>> [Use Cases]
>>>
>>> 1, Lightning Network ecosystem
>>>
>>> * Hosting Incentives like Acai Protocol
>>> ** Watchtower Hosting incentive, Backup Hosting incentive
>>> *** Commitment tx data sending to Data Host(DLAS-up)
>>> **** Commitment tx data is embedded in preimage so that Payer can not
>>> send the data without remittance
>>> *** Channel backup data receiving from Data Host(DLAS-down)
>>> **** Channel backup data is embedded in preimage so that Payer can not
>>> receive the data without remittance
>>>
>>> 2, Crypto currency Problems
>>>
>>> * Distributed secret key sharing (just come up with an idea though)
>>> ** As a key backup, one of secret key shares is distributed with
>>> encryption(DLAS-up) to some nodes, which nodes receive lightning payment as
>>> key managing fee. And the nodes send a proof for managing the key as
>>> response of bloom filter periodically, and exchange encrypted secret key
>>> share with lightning payment to asset holder(DLAS-down).
>>> ** For example 2 out of 3 multi signature key sharing, asset holder puts
>>> the first key, the custodial has the second key, and the third key at the
>>> lightning distribution nodes. Asset holders usually spend assets using
>>> their key and the key on Distributed Nodes.
>>>
>>>
>>> 3, Problems so far
>>>
>>> * Prevention email spam and DDoS attack with large data
>>> ** Payer can not send email or data without remittance(DLAS-up)
>>> ** Payer can not receive reply-email without remittance(DLAS-down)
>>>
>>> * Incentive of receiving advertisements on browser or desktop/mobile app
>>> ** Payer can not send advertisements without remittance(DLAS-up)
>>>
>>> * Bounty for code bug fixes based on cryptographic proofs or secret
>>> computations
>>> ** (DLAS-down)
>>>
>>>
>>>
>>> [References]
>>>
>>> [1] https://bitcointalk.org/index.php?topic=321228
>>> [2] https://twitter.com/roasbeef/status/964608261830750208
>>> [3] https://eprint.iacr.org/2016/575
>>> [4] https://github.com/storm-org/storm-spec
>>> [5] https://twitter.com/joostjgr/status/1190714028626251779
>>> [6] https://github.com/lightningnetwork/lightning-rfc/pull/619
>>> [7]
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html
>>>
>>>
>>> document on github:
>>> https://github.com/takaya-imai/data_lightning_atomic_swap
>>>
>>> Best regards,
>>> Takaya Imai
>>> Email: takaya.imai at frontier-ptnrs.com, takaya.imai at unitedbitcoiners.com
>>> _______________________________________________
>>> Lightning-dev mailing list
>>> 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/257e2885/attachment-0001.html>;