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|1 year ago
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|1 year ago
RustyRussell|1 year ago
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|1 year ago