Chris Stewart [ARCHIVE] on Nostr: 📅 Original date posted:2019-07-08 📝 Original message: > You could purchase an ...
📅 Original date posted:2019-07-08
📝 Original message:
> 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 allows the server to correlate what sort of
data some one is interested in. However on a practical level it may super
easy to correlate what sort of data people are querying for with normal
heuristics.
The other thing is the accounting question, where if a person does not use
all of their allocated requests within the given time frame. Perhaps you
can allow a refund invoice to be provided up front, so the server can
refund the user of the API after a set amount of time, but that comes with
it's own issues.
We are already making the assumption that someone has a Lightning node
setup, I don't see why a user wouldn't leverage that fact to not overpay
for services. There could be an argument made for latency sensitive
applications, but you probably want to go with a dedicated provider with
colocation and a more traditional payment system if that is the case.
I agree with David Harding's analysis on DoS issues. This seems like a
pretty solvable engineering problem from the server's perspective in my
opinion.
-Chris
On Fri, Jul 5, 2019 at 12:34 PM Alexander Leishman <leishman3 at gmail.com>
wrote:
> 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 selling data for lightning payments might take
> different approaches:
>
> 1. 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)
> 2. You could pay per request (good for when you would want 1 big blob of
> data)
>
> So for the case where a customer is calling the API multiple times per
> day, wouldn't it make more sense to pay upfront for future requests?
>
> Best,
> Alex
>
> Best,
> Alex
>
>
>
> On Thu, Jul 4, 2019 at 8:36 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> 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
>> ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
>>
>> It is possible I simply misunderstand the proper use of MAC, so I shall
>> research it in more depth.
>>
>>
>> > 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 now at Suredbits with websockets.
>> >
>> > 1. Client sends request to server for invoice
>> > 2. Server returns invoice
>> > 3. Client pays invoice
>> > 4. Server sends data back, or client makes request _again_ to a server
>> and then server returns data
>> >
>> > With Nadav's scheme this is simplified to
>> >
>> > 1. Client sends request to server
>> > 2. Serves returns invoice, and encrypted payload
>> > 3. Client pays invoice
>> > 4. Client decrypts data according to Nadav's scheme
>> >
>> > This saves a round trip between the server and client. It also gives
>> atomicity to the transaction, although as you stated before there is no
>> guarantees about integrity of the encrypted data. This is generally a hard
>> problem to solve in the technical sense, but I think the reputational harm
>> of the server sending bad data will be enough to prevent this, who wants to
>> do business with some one that isn't providing the advertised service? This
>> is a interaction that is could be repeated thousands of times on a daily
>> basis.
>>
>> A client can easily DoS the server by requesting and requesting (thus
>> convincing the server to encrypt and send data immediately) and never
>> paying.
>> Whereas the first would require more resources on the client side, as the
>> server does not encrypt (or never encrypts at all) until the client has
>> shown proof-of-payment.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190708/0f45dc7b/attachment.html>;
📝 Original message:
> 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 allows the server to correlate what sort of
data some one is interested in. However on a practical level it may super
easy to correlate what sort of data people are querying for with normal
heuristics.
The other thing is the accounting question, where if a person does not use
all of their allocated requests within the given time frame. Perhaps you
can allow a refund invoice to be provided up front, so the server can
refund the user of the API after a set amount of time, but that comes with
it's own issues.
We are already making the assumption that someone has a Lightning node
setup, I don't see why a user wouldn't leverage that fact to not overpay
for services. There could be an argument made for latency sensitive
applications, but you probably want to go with a dedicated provider with
colocation and a more traditional payment system if that is the case.
I agree with David Harding's analysis on DoS issues. This seems like a
pretty solvable engineering problem from the server's perspective in my
opinion.
-Chris
On Fri, Jul 5, 2019 at 12:34 PM Alexander Leishman <leishman3 at gmail.com>
wrote:
> 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 selling data for lightning payments might take
> different approaches:
>
> 1. 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)
> 2. You could pay per request (good for when you would want 1 big blob of
> data)
>
> So for the case where a customer is calling the API multiple times per
> day, wouldn't it make more sense to pay upfront for future requests?
>
> Best,
> Alex
>
> Best,
> Alex
>
>
>
> On Thu, Jul 4, 2019 at 8:36 PM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
>> 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
>> ciphertext integrity guarantees. Why do you want to MAC, then encrypt?
>>
>> It is possible I simply misunderstand the proper use of MAC, so I shall
>> research it in more depth.
>>
>>
>> > 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 now at Suredbits with websockets.
>> >
>> > 1. Client sends request to server for invoice
>> > 2. Server returns invoice
>> > 3. Client pays invoice
>> > 4. Server sends data back, or client makes request _again_ to a server
>> and then server returns data
>> >
>> > With Nadav's scheme this is simplified to
>> >
>> > 1. Client sends request to server
>> > 2. Serves returns invoice, and encrypted payload
>> > 3. Client pays invoice
>> > 4. Client decrypts data according to Nadav's scheme
>> >
>> > This saves a round trip between the server and client. It also gives
>> atomicity to the transaction, although as you stated before there is no
>> guarantees about integrity of the encrypted data. This is generally a hard
>> problem to solve in the technical sense, but I think the reputational harm
>> of the server sending bad data will be enough to prevent this, who wants to
>> do business with some one that isn't providing the advertised service? This
>> is a interaction that is could be repeated thousands of times on a daily
>> basis.
>>
>> A client can easily DoS the server by requesting and requesting (thus
>> convincing the server to encrypt and send data immediately) and never
>> paying.
>> Whereas the first would require more resources on the client side, as the
>> server does not encrypt (or never encrypts at all) until the client has
>> shown proof-of-payment.
>>
>> Regards,
>> ZmnSCPxj
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190708/0f45dc7b/attachment.html>;