Published on: 2019-07-26T15:43:27+00:00
A Payment-Atomic Information Decryption (PAID) API has been documented and is currently functional on testnet, with plans to be implemented on mainnet within a week. The API implements the original proposal and will be iterated on to include amendments. An example client for querying the API and decrypting returned data using pre-image recovery has been provided in the form of a GitHub repository.The discussion on the Lightning-dev mailing list revolves around the security implications of APIs that require payment. One suggestion is to purchase an upfront auth token to allow access for a set time and number of requests. Another suggestion is to pay per request for larger data payloads. The benefits of the PAID API include reducing client-server interaction for REST APIs while ensuring payment to the merchant, with atomicity to transactions. However, concerns have been raised about the potential for clients to perform denial-of-service attacks by repeatedly requesting data without paying.ZmnSCPxj raised concerns about the possibility of a client carrying out a denial-of-service attack on a server by repeatedly requesting data without paying. Chris suggested two payment models: purchasing an auth token upfront or paying per request. They also discussed accounting questions and privacy implications. Chris agreed with David Harding's analysis on DoS issues and suggested that it is a solvable engineering problem from the server's perspective.Alex proposed two different payment approaches for lightning payments: purchasing an auth token upfront or paying per request. ZmnSCPxj raised concerns about the risk of a DoS attack when larger data payloads are involved. He also suggested encrypting data after proof-of-payment is shown to prevent clients from requesting and receiving data immediately without paying. The group discusses various strategies to mitigate potential risks associated with using lightning payments for REST APIs.The idea of adding MAC inside the encryption to detect data replacement over an insecure channel and ensure only the intended recipient can decrypt it is discussed. It is suggested that this scheme may be useful for pre-downloading data before payment while still trusting the merchant. The group agrees that a higher-level abstraction and standardized guidelines for different lightning use-cases would be beneficial.In an email exchange, concerns were raised about a proposal that requires customers to trust merchants. There is a need for a higher-level abstraction to handle more mainstream use-cases. It was suggested that including a Zero-Knowledge Proof (ZKP) for ZKCP-compatible data transfers might be helpful. The discussion also focused on why to MAC, then encrypt and the possibility of sending data over a non-secure channel. Additional protection to ensure only the buyer can decrypt the data is proposed.The conversation between Nadav and ZmnSCPxj is about adding extra protection to a payment protocol. The idea of putting MAC inside the encryption to detect data replacement over an insecure channel is discussed. The use of shared secret ensures only the intended recipient can decrypt the data.Nadav proposes adding encrypt-then-mac on chunks of data for users to authenticate that they received the intended data. Stepan suggests leaving the details to app developers, but ZmnSCPxj worries about incompatible applications and suggests creating a Lightning Application Protocol Proposals (LAPP) repository for LAPP developers. They also discuss the issue of trusting data providers and the need for an escrow system. They all agree it would be great to have a good place to put proposals on a git repository.Stepan and ZmnSCPxj discuss the issue of incompatibility in lightning applications. While Stepan suggests that it is up to app developers to decide on compatibility, ZmnSCPxj expresses concerns over the proliferation of incompatible applications or apps that only work with specific wallets. They propose creating a Lightning Application Protocol Proposals (LAPP) repository for LAPP developers. They also discuss the difficulty of proving that data provided by a data provider is bogus and the integration of proof-of-payment with an escrow system.The idea of splitting large data and FEC-encoding it in chunks with each chunk having a separate MAC is considered great. The receiver will use error correction to deal with errors and check MAC of the chunk before decrypting it. The author suggests having proposals and interesting ideas from the mailing list in some kind of guidelines for different lightning use-cases. They propose organizing a lightning-guidelines repo for LAPP developers.ZmnSCPxj suggests splitting up large data into chunks and applying FEC-encoding to each chunk with a separate MAC to recover data in case of transmission errors. Stepan and Nadav discuss simplifying the decryption process by having Sally use a scalar to generate a point with a fixed sign. ZmnSCPxj agrees with both ideas presented in the conversation.A proposal is made to add a fixed sign to a generated point to simplify the decryption process.
Updated on: 2023-07-31T21:46:31.122397+00:00