{"type":"rich","version":"1.0","author_name":"npub1uqcrlv7gf6hwmmm2n2dr5kdqwjct7pyf8r9zpumwgk297r3el6ssdc9gv6","author_url":"https://nostr.ae/npub1uqcrlv7gf6hwmmm2n2dr5kdqwjct7pyf8r9zpumwgk297r3el6ssdc9gv6","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-01-20\n📝 Original message:\nHi Subhra,\n\nthanks for your question.\n\n\u003e So as of now if we consider transfer of a file (may of few KB) then you\nsplit it into several blocks and use atomic multi path payment whole using\nthe blocks for embedding with the preimage inorder to obtain payment.\n\u003e But it might be the case you may not have sufficient number of path to\ntransfer all the blocks at one go because of preimage size limitation of\n256 bit (I didn't get the point that there is no limitation on data size,\ncan anyone explain that ?).\n\nYes. It needs many blocks and paths if large file.\nBut it has no problem because it can use the same path several times.\n\nOf course it needs much money to transfer large file. But this is good\npoint in order to retain lightning network stable.\n\nFor DOS attack, OG AMP has the same problem. It might that recipient needs\na limit how many split blocks the recipient accept\n\n\u003e So may be you need several iteration and I presume thats what lightning\nnetwork will pitch in where we have several such microtransactions going on.\n\u003e What happens if it fails in an iteration ? So the recipient of the file\nremains happy with the partial content ? Or will the payment be revoked\n(not sure how) if recipient doesn't get the full content ?\n\nThis is about the DLAS-up protocol.\nThe protocol uses OG AMP so the payments and data transfers are revoked in\ncase that it fails.\n\nThanks,\nTakaya Imai\n\n2020年1月16日(木) 16:14 Subhra Mazumdar \u003csubhra.mazumdar1993 at gmail.com\u003e:\n\n\u003e Hello Takaya,\n\u003e         I really liked the idea of data atomic swap mentioned over here.\n\u003e So as of now if we consider transfer of a file (may of few KB) then you\n\u003e split it into several blocks and use atomic multi path payment whole using\n\u003e the blocks for embedding with the preimage inorder to obtain payment. But\n\u003e it might be the case you may not have sufficient number of path to transfer\n\u003e all the blocks at one go because of preimage size limitation of 256 bit (I\n\u003e didn't get the point that there is no limitation on data size, can anyone\n\u003e explain that ?). So may be you need several iteration and I presume thats\n\u003e what lightning network will pitch in where we have several such\n\u003e microtransactions going on. What happens if it fails in an iteration ? So\n\u003e the recipient of the file remains happy with the partial content ? Or will\n\u003e the payment be revoked (not sure how) if recipient doesn't get the full\n\u003e content ?\n\u003e\n\u003e On Mon, Nov 11, 2019 at 6:29 AM Takaya Imai \u003c\n\u003e takaya.imai at frontier-ptnrs.com\u003e wrote:\n\u003e\n\u003e\u003e Hi all,\n\u003e\u003e\n\u003e\u003e I propose Data Lightning Atomic Swap.\n\u003e\u003e Anyone already have the same idea?\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e [Abstract]\n\u003e\u003e This proposal is a way to swap data and lightning payment atomically.\n\u003e\u003e It has two patterns, one is for a payer to swap data-download with\n\u003e\u003e lightning payment to a payee (DLAS-down), the other is for a payer to swap\n\u003e\u003e data-upload with lightning payment to a payee (DLAS-up).\n\u003e\u003e\n\u003e\u003e The data is embedded to preimage so sending and receiving the data need\n\u003e\u003e lightning payment at the same time.\n\u003e\u003e\n\u003e\u003e ---------\n\u003e\u003e\n\u003e\u003e [Motivation]\n\u003e\u003e Atomic Swaps among crypto currencies has various ways to implement\n\u003e\u003e (on-chain to on-chain[1], on-chain to of-chain(Submarine Swap[2])). And\n\u003e\u003e Atomic Swaps between data and crypto currencies are also proposed as a part\n\u003e\u003e of TumbleBit mechanism[3], Storm mechanism[4] and so on.\n\u003e\u003e\n\u003e\u003e Recently Joost Jager proposed Instant messages with lightning onion\n\u003e\u003e routing, whatsat[5], which use recent sphinx payload change[6]. This is\n\u003e\u003e very awesome but not atomic with lightning payment.\n\u003e\u003e\n\u003e\u003e Atomic lightning mechanism for data is useful in use cases below.\n\u003e\u003e\n\u003e\u003e ---------\n\u003e\u003e\n\u003e\u003e [Pros \u0026 Cons]\n\u003e\u003e\n\u003e\u003e * DLAS-down\n\u003e\u003e ** Pros\n\u003e\u003e *** Atomic data download exchange with lightning payment\n\u003e\u003e ** Cons\n\u003e\u003e *** It needs better mechanism to expand data size\n\u003e\u003e\n\u003e\u003e * DLAS-up\n\u003e\u003e ** Pros\n\u003e\u003e *** Atomic data upload exchange with lightning payment\n\u003e\u003e ** Cons\n\u003e\u003e *** OG AMP[7] is needed to implement\n\u003e\u003e\n\u003e\u003e ---------\n\u003e\u003e\n\u003e\u003e [What I describe]\n\u003e\u003e * A way to swap data with lightning payment atomically.\n\u003e\u003e\n\u003e\u003e ---------\n\u003e\u003e\n\u003e\u003e [What I do not describe]\n\u003e\u003e * A way to detect that data is correct or not, namely zero knowledge\n\u003e\u003e proof process.\n\u003e\u003e\n\u003e\u003e For example, probabilistic checkable proof like TumbleBit[3] proposed.\n\u003e\u003e Just message as data is no problem because no need to check the message\n\u003e\u003e is correct or not.\n\u003e\u003e\n\u003e\u003e * A way in case that different preimages are used in a payment route like\n\u003e\u003e Multi-hop locks.\n\u003e\u003e\n\u003e\u003e ---------\n\u003e\u003e\n\u003e\u003e [Specification]\n\u003e\u003e\n\u003e\u003e Lightning Network(LN) has a mechanism about preimage like a brief image\n\u003e\u003e below.\n\u003e\u003e\n\u003e\u003e Payer                             Mediators\n\u003e\u003e  Payee\n\u003e\u003e\n\u003e\u003e =================================================================================\n\u003e\u003e\n\u003e\u003e Preimage\n\u003e\u003e Preimage Hash  \u003c--------------------- invoice ------------------------\n\u003e\u003e  Preimage Hash\n\u003e\u003e Preimage Hash  ----------------\u003e   Preimage Hash --------------------\u003e\n\u003e\u003e  Preimage Hash\n\u003e\u003e Preimage       \u003c—-------------—-   Preimage      \u003c--------------------\n\u003e\u003e  Preimage\n\u003e\u003e\n\u003e\u003e As you know, preimage Payer gets can be a proof of payment because Payer\n\u003e\u003e can not get it if the payment is executed correctly.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 1, Data download \u003c-\u003e  lightning (DLAS-down)\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Payer sends lightning payment and receives data from Payee atomically.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e Payer                             Mediators\n\u003e\u003e  Payee\n\u003e\u003e\n\u003e\u003e =================================================================================\n\u003e\u003e Payer Channel Pubkey \u003c-----------------------------------------------\u003e\n\u003e\u003e Payee Channel Pubkey\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e  data(256bit, padded)\n\u003e\u003e\n\u003e\u003e  enc_key = (Payee Channel Secret Key * Payer Channel Pubkey).x  (256bit)\n\u003e\u003e enc_key = (Payer Channel Secret Key * Payee Channel Pubkey).x  (256bit)\n\u003e\u003e\n\u003e\u003e  enc_data = data XOR enc_key\n\u003e\u003e sha256(enc_data) \u003c--------------------- invoice ----------------------\n\u003e\u003e sha256(enc_data)\n\u003e\u003e sha256(enc_data) ----------------\u003e sha256(enc_data) -----------------\u003e\n\u003e\u003e sha256(enc_data)\n\u003e\u003e enc_data         \u003c---------------- enc_data \u003c-------------------------\n\u003e\u003e enc_data\n\u003e\u003e data = enc_data XOR enc_key\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e * The size of data is restricted to 256 bits. Identically, it should be\n\u003e\u003e extended to larger data and the data should be transferred in several\n\u003e\u003e payment paths like DLAS-up.\n\u003e\u003e * Channel Pubkey is only one for one channel and the data can be\n\u003e\u003e decrypted if enc_key is leaked. So enc_key should be generated newly every\n\u003e\u003e time by a way like hash chain but the protocol image above is just example\n\u003e\u003e for simplicity.\n\u003e\u003e * .x means X axis value of points on Elliptic Curve.\n\u003e\u003e * If data is less than 256 bits, then 0x00 is padded (I am not sure which\n\u003e\u003e of big endian and little endian is better).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 2, Data upload \u003c-\u003e  lightning (DLAS-down)\n\u003e\u003e\n\u003e\u003e Payer sends data and lightning payment from Payee atomically.\n\u003e\u003e This is like OG AMP(Atomic Multi-path Payment)[7] system.\n\u003e\u003e\n\u003e\u003e Payer                             Mediators\n\u003e\u003e  Payee\n\u003e\u003e\n\u003e\u003e =================================================================================\n\u003e\u003e data(512bit, padded)\n\u003e\u003e\n\u003e\u003e share1(256bit)\n\u003e\u003e share2(256bit)\n\u003e\u003e\n\u003e\u003e base_s = share1 XOR share2\n\u003e\u003e data1(256bit) ||  data2(256bit) = data(512bit)\n\u003e\u003e XOR_d1 = data1 XOR base_s\n\u003e\u003e XOR_d2 = data2 XOR base_s\n\u003e\u003e PreImg1 = sha256(base_s || data || 1)\n\u003e\u003e PreImg2 = sha256(base_s || data || 2)\n\u003e\u003e\n\u003e\u003e sha256(PreImg1), XOR_d1, share1 -\u003e sha256(PreImg1), XOR_d1, share1  -\u003e\n\u003e\u003e sha256(PreImg1), XOR_d1, share1\n\u003e\u003e sha256(PreImg2), XOR_d2, share2 -\u003e sha256(PreImg2), XOR_d2, share2  -\u003e\n\u003e\u003e sha256(PreImg2), XOR_d2, share1\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e  base s = share1 XOR share2\n\u003e\u003e\n\u003e\u003e  data = (XOR_d1 XOR base_s) || (XOR_d2 XOR base_s)\n\u003e\u003e\n\u003e\u003e  PreImg1 = sha256(base_s || data || 1)\n\u003e\u003e\n\u003e\u003e  PreImg2 = sha256(base_s || data || 2)\n\u003e\u003e\n\u003e\u003e PreImg1    \u003c-------------------    PreImg1    \u003c---------------------\n\u003e\u003e PreImg1\n\u003e\u003e PreImg2    \u003c-------------------    PreImg2    \u003c---------------------\n\u003e\u003e PreImg2\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e * This protocol example has 512 bits data and they are transferred in two\n\u003e\u003e paths. However, it can transfer larger data in several payment paths like\n\u003e\u003e [5].\n\u003e\u003e * || means string concatenation.\n\u003e\u003e * If data is less than 512 bits, then 0x00 is padded(I am not sure which\n\u003e\u003e of big endian and little endian is better).\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e ---------\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e [Use Cases]\n\u003e\u003e\n\u003e\u003e 1, Lightning Network ecosystem\n\u003e\u003e\n\u003e\u003e * Hosting Incentives like Acai Protocol\n\u003e\u003e ** Watchtower Hosting incentive, Backup Hosting incentive\n\u003e\u003e *** Commitment tx data sending to Data Host(DLAS-up)\n\u003e\u003e **** Commitment tx data is embedded in preimage so that Payer can not\n\u003e\u003e send the data without remittance\n\u003e\u003e *** Channel backup data receiving from Data Host(DLAS-down)\n\u003e\u003e **** Channel backup data is embedded in preimage so that Payer can not\n\u003e\u003e receive the data without remittance\n\u003e\u003e\n\u003e\u003e 2, Crypto currency Problems\n\u003e\u003e\n\u003e\u003e * Distributed secret key sharing (just come up with an idea though)\n\u003e\u003e ** As a key backup, one of secret key shares is distributed with\n\u003e\u003e encryption(DLAS-up) to some nodes, which nodes receive lightning payment as\n\u003e\u003e key managing fee. And the nodes send a proof for managing the key as\n\u003e\u003e response of bloom filter periodically, and exchange encrypted secret key\n\u003e\u003e share with lightning payment to asset holder(DLAS-down).\n\u003e\u003e ** For example 2 out of 3 multi signature key sharing, asset holder puts\n\u003e\u003e the first key, the custodial has the second key, and the third key at the\n\u003e\u003e lightning distribution nodes. Asset holders usually spend assets using\n\u003e\u003e their key and the key on Distributed Nodes.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e 3, Problems so far\n\u003e\u003e\n\u003e\u003e * Prevention email spam and DDoS attack with large data\n\u003e\u003e ** Payer can not send email or data without remittance(DLAS-up)\n\u003e\u003e ** Payer can not receive reply-email without remittance(DLAS-down)\n\u003e\u003e\n\u003e\u003e * Incentive of receiving advertisements on browser or desktop/mobile app\n\u003e\u003e ** Payer can not send advertisements without remittance(DLAS-up)\n\u003e\u003e\n\u003e\u003e * Bounty for code bug fixes based on cryptographic proofs or secret\n\u003e\u003e computations\n\u003e\u003e ** (DLAS-down)\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e [References]\n\u003e\u003e\n\u003e\u003e [1] https://bitcointalk.org/index.php?topic=321228\n\u003e\u003e [2] https://twitter.com/roasbeef/status/964608261830750208\n\u003e\u003e [3] https://eprint.iacr.org/2016/575\n\u003e\u003e [4] https://github.com/storm-org/storm-spec\n\u003e\u003e [5] https://twitter.com/joostjgr/status/1190714028626251779\n\u003e\u003e [6] https://github.com/lightningnetwork/lightning-rfc/pull/619\n\u003e\u003e [7]\n\u003e\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/000993.html\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e document on github:\n\u003e\u003e https://github.com/takaya-imai/data_lightning_atomic_swap\n\u003e\u003e\n\u003e\u003e Best regards,\n\u003e\u003e Takaya Imai\n\u003e\u003e Email: takaya.imai at frontier-ptnrs.com, takaya.imai at unitedbitcoiners.com\n\u003e\u003e _______________________________________________\n\u003e\u003e Lightning-dev mailing list\n\u003e\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\u003e\n\u003e\n\u003e\n\u003e --\n\u003e Yours sincerely,\n\u003e Subhra Mazumdar.\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200120/dd3a091b/attachment-0001.html\u003e"}