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.
You can rate-limit (runes do this, which are simplified macaroons) but then the server is no longer stateless. Pretty sure I've ranted about this in HN comments before, could dig it out if you're interested?
Heres the inline:
See https://github.com/rustyrussell/runes for a simpler alternative and implementation (this has C and Python, but there's also a Rust implementation because why not?)
However, the "no db access" property has proven to be untenable in practice. Users end up wanting to see what runes are issued, blacklist them, know when they were last used, and have rate limits. The last two are a killer, requiring some state to be kept (unless your system allows you to return a modified rune to the user, which is a different workflow from normal bearer creds).