Thank you for your thought. Another idea: would it be useful to split up large data (several megabytes long) and FEC-encode it in chunks (with each chunk having a separate MAC)?
That way even if some error occurs during transmission, it is possible to recover without re-downloading entire dataset. Especially, since we need to decrypt first, before we can confirm the MAC: if the MAC fails for the chunk, it's better if we can use data from nearby chunks to recover, rather than download and re-decrypt again. Or is this over-engineering? Regards, ZmnSCPxj Sent with ProtonMail Secure Email. ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Wednesday, June 26, 2019 1:41 PM, Stepan Snigirev <[email protected]> wrote: > Hi ZmnSCPxj, > > > Does this require Bob to attempt both positive and negative sign for the > > y-coordinate? > > Alternately we can force Sally to always use a scalar such that generated > > point has a fixed sign (or some other property to derive the sign of the > > missing coordinate). > > The best would be if Sally uses the point with a fixed sign, then Bob doesn't > need to try twice and can start decrypting data from stream (for example if > it's a DRM key for a movie). > Similar approach is used for R-encoding in Schnorr signatures, so we could > use the same convention here. > > On Tue, Jun 25, 2019 at 10:18 PM ZmnSCPxj <[email protected]> wrote: > > > Good morning Stepan, and Nadav, > > > > Both additions seem good idea to me. > > > > > - Sally generates the invoice with the preimage `S` (i.e. x-coordinate of > > > this point to make it 32-bytes long) > > > > Does this require Bob to attempt both positive and negative sign for the > > y-coordinate? > > Alternately we can force Sally to always use a scalar such that generated > > point has a fixed sign (or some other property to derive the sign of the > > missing coordinate). > > > > Regards, > > ZmnSCPxj _______________________________________________ Lightning-dev mailing list [email protected] https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
