📅 Original date posted:2020-01-20 📝 Original message: Hi ...

2023-06-09T14:58:05+02:00

In reply to nevent1q…y52x
_________________________

📅 Original date posted:2020-01-20
📝 Original message:
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 <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/dd3a091b/attachment-0001.html>;

📅 Original date posted:2020-01-20 📝 Original message: Hi ...

2023-06-09T14:58:04+02:00

In reply to nevent1q…wvxa
_________________________

📅 Original date posted:2020-01-20
📝 Original message:
Hi ZmnSCPxj,

Sorry for late reply.
The no restriction version is very good.

Thanks,
Takaya Imai

2019年11月12日(火) 9:13 ZmnSCPxj <ZmnSCPxj at protonmail.com>:

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200120/b60362ff/attachment.html>;

Nostr notes by

📅 Original date posted:2020-01-20 📝 Original message: Hi ...

📅 Original date posted:2020-01-20 📝 Original message: Hi ...