If it's just for one request, the capability ("macaroon" is just their word for a capability) could be tied to a source IP address, so that only one client can use the service.
That's the least of the problems.
The concept is that each user has a pre-purchased local store of some cryptocurrency.
For some reason, they don't actually say that.
Servers send an "invoice", with just enough info to get paid but not enough to identify what they're selling or who the seller is.
An unconditional "pay invoice" function in the example charges however much the service wants to take. Bad idea.
Automated irrevocable transactions with anonymous parties. What could possibly go wrong?
There's a lot that's not mentioned.
- The server must have a connection to the payment network, and it has to get a success reply back before the transaction can proceed. This is happening within an HTTP transaction, so there's a time limit.
- This lacks atomic transactions. If the connection is broken after the payment is sent but before it is acknowledged, the money has been transferred but nothing was returned. The client doesn't know if the payment was made. This problem is common to all payment systems, and unwinding failed transactions is a part of payment systems that get used.
It doesn't need to happen within an http transaction nor does it have to be atomic. There is a way to present proof of payment to a recipient by showing them a preimage of a hash that's received by a lightning node on payment completion
That's the least of the problems.
The concept is that each user has a pre-purchased local store of some cryptocurrency. For some reason, they don't actually say that. Servers send an "invoice", with just enough info to get paid but not enough to identify what they're selling or who the seller is. An unconditional "pay invoice" function in the example charges however much the service wants to take. Bad idea.
Automated irrevocable transactions with anonymous parties. What could possibly go wrong?
There's a lot that's not mentioned.
- The server must have a connection to the payment network, and it has to get a success reply back before the transaction can proceed. This is happening within an HTTP transaction, so there's a time limit.
- This lacks atomic transactions. If the connection is broken after the payment is sent but before it is acknowledged, the money has been transferred but nothing was returned. The client doesn't know if the payment was made. This problem is common to all payment systems, and unwinding failed transactions is a part of payment systems that get used.