Storm: escrowed storage and messaging at L2/L3 [combined summary]



Individual post summaries: Click here to read the original discussion on the bitcoin-dev mailing list

Published on: 2019-08-21T17:04:35+00:00


Summary:

Maxim Orlovsky has proposed a solution to address the Deaf Bob Attack, which involves the addition of two intermediary HTLC transactions called confirmation and fallbacks. This solution allows Alice to sign the HTLC fallback transaction and receive compensation if she doesn't receive the data from Bob. Bob, on the other hand, can prove that he still has the data by providing a "preimage" to the secret hashed by Alice. To ensure this, Bob selects the decryption key during setup and encrypts the data using EC multiplication with a factor provided by Alice. The only possibility for cheating now is if Alice no longer needs the data and avoids paying the full amount for storage, which Bob must consider during setup.The conversation between Maxim and ZmnSCPxj focuses on implementing Storm, a new off-chain payment channel network. They discuss the validation of probabilistically checkable proofs by Alice and the need for her to take a "shot" from the data in the form of a Merkle tree and keep its root. Asymmetric encryption using EC for atomic payments and threshold ECDSA signatures are also discussed. Additionally, they mention dual-funding channels, but note that it may not be necessary in a world where atomic cross-system swaps are possible. Fulgurite, a project to split a channel into Lightning part and DLC part, is mentioned as a potential solution.In their email conversation, ZmnSCPxj and Maxim Orlovsky discuss the proposed solution called Storm, which utilizes the Lightning Network for decentralized data storage. They address potential issues raised, including the insufficient description of probabilistic proof, asymmetrical encryption, and transportability over LN channels. ZmnSCPxj suggests elegant solutions to these problems, such as using EC for encryption/decryption and threshold ECDSA signatures. They acknowledge that the solution may be limited to a single LN channel, which must be dually-funded. To overcome potential attack risks for intermediate nodes, ZmnSCPxj proposes using EC magic homomorphisms. Maxim Orlovsky plans to analyze this solution further and open an issue on GitHub for discussion.ZmnSCPxj raises concerns about the Deaf Bob Attack on the bitcoin-dev mailing list. The attack scenario involves Bob claiming to have lost the data needed for a transaction, allowing him to receive the stake and reward without providing the data to Alice. If Alice publishes the HTLC settlement transaction, Bob can reveal the decryption key, but without the encrypted data, it is useless. This raises questions about the workability of the scenario, as the decryption key is embedded in the HTLC and cannot be obtained without being selected by Bob during setup.ZmnSCPxj writes a letter to Maxim pointing out issues with the probabilistic checkable proof for data storage on the Lightning network. The main concern is that the proof can only confirm that the encrypted data corresponds to the given plaintext, not if the source data matches what Alice originally stored. To address this, Alice needs to compute a Merkle Tree of the data chunks and store its root before sending the data to Bob for storage. The proof should include the Merkle Tree Path proofs of the selected source data chunks. The use of asymmetrical encryption, where Bob shares the decryption key only after acquiring funds, is also discussed. However, it is unclear how to assure Alice that the hash of the decryption key is indeed the correct one. ZmnSCPxj suggests using asymmetric encryption using EC to atomically pay for knowledge of the scalar/decryption key while revealing only the hash and encryption key to Alice. They also note that any mechanism requiring multiple participants to put up money into a contract can only live inside a single LN channel due to potential attacks on intermediate nodes.Dr. Maxim Orlovsky proposes a design for distributed storage and messaging with escrow/economic incentivization, leveraging the LNP/BP ecosystem at Layer 2 and 3. This design allows for the construction of payment channels that guarantee remote data storage and retrieval while mitigating counterparty risks through economic stimulus. It can be combined with Lightning Network for off-chain operation. The proposal originated from joint work on RGB and single-use seals technologies but has potential applications for other L2/L3 technologies requiring client-stored data. Feedback and discussions on driving Storm development forward are welcome.


Updated on: 2023-08-02T01:17:03.927119+00:00