Hey all,
The following is a link to the documentation for what we've been calling a
*PAID* (Payment-Atomic Information Decryption) *API*:
https://test.suredbits.com/api/#historical-prices-data-api-2
despite what the docs say it is currently only working on testnet, but
should be on mainnet within
> You could purchase an auth token upfront that allows you access for some
amount of time of some number of requests (seems to be the most efficient
for APIs that would be called more than once)
This does have privacy implications. It is yet to be seen how these things
develop, but this obviously
On Fri, Jul 05, 2019 at 03:36:37AM +, ZmnSCPxj via Lightning-dev wrote:
> A client can easily DoS the server by requesting and requesting (thus
> convincing the server to encrypt and send data immediately) and never
> paying.
Is this an actual concern? Assuming this protocol is used with web
Chris,
Thanks for that explanation. I could see how this makes sense for
lightweight data payloads because it reduces the round trip count, but I
agree with ZmnSCPxj that this could pose a DoS risk for larger data
payloads. This DoS risk is even more magnified for ZKCPs.
I would guess that APIs s
Good morning Alexander,
> > > Putting MAC inside the encryption would help ensure that we can detect
> > > data replacement over insecure channel, and use of shared secret ensures
> > > only intended recipient can decrypt.
> >
> > Generally you want to MAC the ciphertext + IV, otherwise you lose
Hey Alex,
I think the benefit here is in reducing the client-server interaction for
REST apis while still ensuring payment to the merchant.
Let's assume that we don't have this scheme, and want to provide a
monetized REST API. The workflow looks like this, which is similar to what
our behavior is
Nadav,
This is an interesting proposal, but because this still requires the
customer to trust the merchant, I am concerned that it adds complexity
without any meaningful guarantee to the customer. Perhaps it makes sense to
at least include some extension field here that allows the merchant to
incl
Good morning Nadav et al.,
> > Any node on the route of the payment knows the preimage and can decrypt the
> > data. It would be nice to tune the protocol in a way that only the buyer
> > can decrypt the data. For example we could use something like this:
>
> Is this not covered by sending over
Hi ZmnSCPxj and Stepan,
Thanks for all the feedback!
I think doing encrypt-then-mac on chunks of the data would be a great
addition for users to be able to authenticate that they received the
intended data.
> Any node on the route of the payment knows the preimage and can decrypt
the data. It wo
Good morning Stepan,
> But it depends on the application and communication channel, so I would leave
> these details to the app developers.
I would mildly disagree, as I worry about proliferation of incompatible
applications, or applications that can only work with specific wallets.
Still, it
> 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)?
I think it's a great idea. Ideally we want to do error correction and check
MAC before decryption, so for large data it makes a lot of sense to sp
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 datas
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 Sall
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 forc
Hi Nadav,
Nice proposal. There are two suggestions that came to my mind:
1. In your proposal the encrypted data doesn't have any authentication. I
would suggest to use authenticated encryption and add HMAC-SHA256 at the
end of the encrypted data (encrypt-then-mac). Then even if insecure
connectio
Good morning Nadav,
I have had a similar idea (although without any details as to algorithm).
However, it seems to me that the data seller is trusted to actually encrypt the
data honestly (rather than, say, encrypting bytes from `/dev/random`).
On the other hand, this is a good way to obsolete m
Hi all,
There are many applications that sell some form of data to users (e.g. a
blog post, a game, live data, etc.) monetizing with Lightning. This data
transfer can (and often should) be made atomic with the payment for that
data using the payment pre-image. This basically entails responding to
17 matches
Mail list logo
