Monero Research Lab (Unofficial)@MoneroResearchL
The MRL reviewed the Grease CCS proposal (516.9 XMR) for Monero’s first operational bidirectional payment-channel implementation and SDK (based on Monet), targeting one-to-one or small-scale channels rather than a full Lightning-style PCN. Discussion covered PCN routing privacy-utility trade-offs, NP-hardness of optimal multi-part payment routing, the mandatory Key Escrow Service (KES) as a trustlessness substitute for HTLC+watchtowers (with protocol-level security differences vs. Bitcoin), output-history accumulation risks even with FCMP in multi-hop use, and niche micropayment utility (e.g., instant xmrchat.com superchats avoiding the 10-block lock), noting Grease as the only Monero payment-channel proposal with substantial code.
Rucknium: Grease Payment Channels.
This is a CCS proposal for the first operational payment channel implementation for Monero.
Rucknium: Total requested budget is 516.9 XMR.
Rucknium: The Bitcoin Lightning Network is a network of many payment channels linked together. IIRC, the Grease team wants to focus on one-to-one or small networks instead of trying to implement a Monero Lightning Network.
rbrunner: Quite some stuff to read, that CCS text is very detailed
jberman: Seems like kayabanerve raised a good point. In line with that point, it doesn't seem like it should be marketed as a trustless solution when it relies on a solution not yet fleshed out / explained
Rucknium: After the meeting, irc_cjs77 can answer any quested posted during the meeting.
Rucknium: I'm a skeptic on Payment Channel Networks as a 2nd layer payment system, but not a skeptic on small-scale payment channels, FWIW.
jberman: and also the core innovation of payment channels was/is the trustless factor, so I think it's extremely critical that that is fleshed out
ArticMine: This is a very exciting proposal. I find the focus on one to one or small networks particularly appealing. My comment is that this is not a substitute for scaling.
rbrunner: It seems it's altogether easy to underestimate what is needed for "just connect two people" ...
Rucknium: IMHO, Payment Channel Networks (PCNs) have problems with user adoption, reliability, and privacy.
ArticMine: I agree for large scale network attempts
Rucknium: Lightning has improved its privacy characteristics in recent years AFAIK, but I don't think privacy issues in PCNs can be eliminated completely.
Rucknium: Tang, Wang, Fanti, & Oh (2020) "Privacy-Utility Tradeoffs in Routing Cryptocurrency over Payment Channel Networks" arxiv.org/abs/1909.02717
ArticMine: One to one or very small is a different matter .
Rucknium: "However, in deployed PCNs [payment channel networks], channel balances (i.e., edge weights are not revealed to users for privacy reasons; users know only the initial weights at time 0. Hence, when routing transactions, users first guess a path, then check if it supports the transaction. This guess-and-check process dramatically reduces the success rate of transactions. At the other extreme, knowing full channel balances can give substantial improvements in success rate at the expense of privacy. In this work, we study whether a network can reveal noisy channel balances to trade off privacy for utility. We show fundamental limits on such a tradeoff, and propose noise mechanisms that achieve the fundamental limit for a general class of graph topologies."
Rucknium: One of that paper's authors, Fanti, is the lead author of the Dandelion++ paper.
ArticMine: I am especially interested in one to one.
rbrunner: So this probably also shows nicely how complexity can explode if you from connecting two parties to networks?
Rucknium: I think payment channels could be useful for xmrchat.com , for example. Instant payments for the lie super chat messages and you would never have the 10 block lock problem if you wanted to send a lot of messages in a short time. Of course, having a service-side "wallet" that you deposit XMR credits to would have similar characteristics, but would not be trustless.
rbrunner: Using XMR like a micropayment system
Rucknium: IIRC, a paper showed that Lightning routing was NP-hard. But there are heuristics that can get you routing with acceptable reliability. I will try to find the paper.
rbrunner: Might not take long only people start to bet over such channels ...
ArticMine: Micro payments is a possible application; however I see XMR funded centralized ledgers as very viable for micro payments. The funding of such a ledger could in itself be a use case for payment channels
Rucknium: I think this is the paper: Pickhardt & Richter (2021) "Optimally Reliable & Cheap Payment Flows on the Lightning Network" arxiv.org/abs/2107.05322
Rucknium: "We observe that finding the cheapest multi-part payments is an NP-hard problem considering the current fee structure and propose dropping the base fee to make it a linear min-cost flow problem. Finally, we discuss possibilities for maximizing the probability while at the same time minimizing the fees of a flow. While this turns out to be a hard problem in general as well - even in the single path case - it appears to be surprisingly tractable in practice."
Rucknium: Pickhardt has done a lot of work on Lightning routing.
rbrunner: As far as I know it's quite some time since the last time LN really made waves. Maybe struggles to grow?
Rucknium: Back to the Key Escrow Service (KES). That does seem like a significant problem with Grease at the moment.
rbrunner: But I don't think that this really means something for our XMR based proposal now.
Rucknium: rbrunner: Merchant data suggests that Lightning adoption is low. And Lightning has an additional big incentive for users that Grease would not have. On-chain BTC fees are much higher than XMR fees are or will be.
jberman: As I understand it, the existence of the KES implies a reduction in security of the protocol compared to payment channels as implemented on Bitcoin
rbrunner: I see
jeffro256: True, though on the flip side, as was previously mentioned, the 10 block lock is a "push" force
Rucknium: KES serves a purpose similar to the Hash Time Locked Contract (HTLC) + watchtower system in Lightning, right? Except Lightning users can go without a third-party watchtower if their own Lightning node has reliable uptime. With Grease, the KES is mandatory for trustlessness, right?
jberman: That's how I understand it
Rucknium: jeffro256: That's how I understand it
Rucknium: It's how we understand it :P
Rucknium: FWIW, Grease isn't the only proposed Monero payment channel systems. I think there are at least 4 papers total. But Grease, based on Monet, is the only one that has much, if any, code written.
■ eprint.iacr.org/2022/117
■ eprint.iacr.org/2021/1445
■ eprint.iacr.org/2020/1441
■ eprint.iacr.org/2022/744
■ ieeexplore.ieee.org/abstract/docum…
Rucknium: ^ Each of the squares is a Monero Payment Channel paper. From github.com/monero-project…
Rucknium: More discussion on Grease for now? It will probably appear on next week's agenda too.
Rucknium: One more thing on PCNs for Monero: IMHO, you have a privacy issue with PCNs even with FCMP because a single Monero tx output start to accumulate "history" if you use it for PCNs. The info is transmitted through the network. But Grease, at present, would mostly avoid that since it's use case is one-to-one and/or small network.
