[mdouglass]

I'm not seeing anything in the protocol that stops the first human from paying for the resource and then sharing their macaroon+preimage with everyone else. Normally, I'd account for that by associating the preimage with a specific human (account) but this seems to be intended for use without accounts?

[Animats]

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.

[derangedHorse]

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

[Animats]

Documentation needed.

[RustyRussell]

Presumably the macaroon itself contains a shortish timeout.

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?

[Bluestein]

Would appreciate it if you did, be so kind ...

[RustyRussell]

https://news.ycombinator.com/item?id=39210946

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).