00:25:12 there's plenty of work to do on the "core" happy-path (cooperative) route before dispute resolution 00:25:12 but the current and proposed limitations should be clear: it shouldn't be advertised as trustless until it really is trustless and decentralized 00:25:12 at the same time, I still think there's a lot of value in iterating grease-xmr from a proof of concept (its current state) to an alpha, with beta being defined as including a properly decentralized and trustless KES[... more lines follow, see https://mrelay.p2pool.observer/e/i8LMkvoKaFlIZU1j ] 00:25:47 independent of* / independently from** 00:34:44 i'm not sure that all of the work necessary for a full decentralized KES needs to be defined right now... an interim threat model detailing who (all?) runs the KES, what collusion/censorship alpha users would accept, etc seems reasonable to me. if lacking a KES makes the proposal equivalent to ecash, I'd still be interesting in a monero sort of cashu 00:34:44 am i understanding correctly that the main hesitation is that community funds should be prioritized for trustless & really decentralized tools? 00:53:25 oh, i should be clear that i'm equivocating/redefining terms: i would NOT consider a centralized/trust-based KES as beta, I'd basically swap terms and call the entire CCS proposal as-is "just alpha", with a future really-trustless-KES defined as beta. sorry to be loose w terms. 01:41:55 Speaking for myself, I aim to use -- and strongly prefer to see -- solutions that maintain "first principles" from day 1, and I'm not a big fan of the "decentralize later" mantra that most of the Ethereum L2 ecosystem took, the "trustless later" approach that Zcash took, the "privacy later" approach that Bitcoin took, etc. I think such an approach ultimately leads to an inferior product 01:42:16 If there are reasonable primitives that Monero could implement at consensus that would enable a trustless payment channel solution, then I would be open to advocating for that 01:42:28 I think Grease is cool and I don't want to see all the work done already go to waste. Just sharing my honest opinions 03:13:37 that's reasonable! and I should've said "if lacking a decentralized* KES makes the proposal equivalent to ecash, I'd still be interested** in a monero sort of cashu" 03:19:25 and to be fair: arming scammers with a monero cashu is probably unwise if the extra effort to achieve trustless KES is feasible 03:21:01 the last potential benefit i'd see in supporting the imperfect iteration would be that improving what i see as the underlying grease protocol helps define the requirements for the overlaying (and interchangeable) kes 05:44:41 I have to confess that I didn't look closely into Grease, and neither into any of that KES stuff, but I do worry about the fact that nobody seems to be able to put a plausible solution of a KES that really "cuts it" on the table, if even completely hypothetical and purely "in theory". 05:45:56 I mean, where would you get the optimism from that "somehow things will work out eventually" with that KES? The universe does not owe us any favors, so to say, and maybe the whole things will turn out to be a dead-end street. 09:59:52 @rbrunner7: I mean, Serai's a validator-backed and economically secured KES 10:04:44 secured by a $SRI while a $GREASE is considered unacceptable/not a legitimate conversation 10:04:44 and to be clear, I don't like that either token may be required (and not suggesting such for grease), but at least SRI basically is--or anyways, it's permissionless and no better system will emerge before serai's ready as a whole 10:05:08 (secured by the funds staked into SRI, I am handwaving) 10:09:28 that's all just to say we have a Substrate-based KES example :) 10:09:28 these sorts of musings are probably better suited for the lounge 10:09:28 I'm against a payment channel solution for Monero which would have its own coin (inherently ridiculous IMO) but especially if then community funded. 10:10:51 Serai isn't a Monero PCN, or a "Monero project" in general (despite the obvious overlap and integrating the Monero ecosystem), where the only 'CCS funding for Serai' was the funding for the audits of what's now monero-oxide (which I wouldn't call "CCS funding for Serai"). 10:27:30 and anyways, I made a gaffe: Serai's KES Key Evolving Signatures =/= the sort of Key Escrow Service Grease would require. acronym collision ._. and thus no, Serai's not a relevant KES example 11:24:36 "Key Evolving Signatures" aren't a thing in Serai (in general?) and I wouldn't call it a Key Escrow Service, even if much of its software could overlap. 13:04:34 Thanks for feedback jberman: jbabb: kayabanerve: rbrunner et al; it's all really good and constructive and much appreciated. 13:04:36 If you'll indulge me, I want to give brief historical context for how Grease has been developed, because it fills in nicely with the conversation thus far. 13:04:38 I wanted run Grease as an experiment with natural failure points so that we could stop the project by spending as few funds as possible. 13:04:40 For example, the Monerokon 5 talk and PoC was really to get a feeling from the community if something like Grease was even desirable. I have my opinions of course, 13:04:42 but they might not be shared by the community as a whole. We came away from MK thinking, "yeah, we should probably continue with this". 13:04:44 The KES was not an afterthought, but admittedly, we didn't put quite as much thought into what its final form would be as we might have. 13:04:46 So we're having the conversation now, rather than 6 or 12 months ago, but that's ok. 13:04:48 From a theoretical point of view, I agree that if a purely trustless KES is impossible _in principle_, then yes, that's a huge problem-- not necessarily complete failure, because only a subset of Grease's ambition could not be realised. I would understand why the community would not want to fund it in this case. 13:04:50 However from a purely theoretical point of view, as kayabanerve mentioned, recreating the Serai ecosystem for Grease is a thought experiment that satisfies the requirement. In principle. 13:04:52 Would I want to build out Serai? Even if it was a "cheap" in the sense that we could fork the code and stand up a KES with few or no changes, I'm also loathe to create a custom token just for Grease. But! if the escrow service wasn't just a KES, but provided additional escrow services (e.g. documents, insurance contracts, bets etc), then maybe there's value in the enormous lift that's 13:04:54 needed to build this out. Even better would to be able to piggy back on existing structure to achieve these goals, so we hardly have to build anything at all. This is one reason why I'm pitching the ideas behind L2s, Secret network etc. 13:04:56 So kayabanerve: I have a perhaps a stupid question: Is there any way that Serai itself could be leveraged into offering escrow services? 13:04:58 On a more pragmatic axis, the value that the KES protects is very diffuse. i.e., a huge number of channels with a large many-to-many relationship between channel participants. So unlike a DEX, or a monetary ledger, the honeypot for a large majority of use-cases for Grease never gets very big. It's lots of small honey capsules, I guess. So I can actually see a world where Grease users 13:05:00 have a selection of KES providers, with more trusted KESs being cheaper vs a much more expensive completely decentralised escrow service (yes, I'm implying that the KES's would necessarily charge a fee). 13:05:02 That's another reason I'm throwing lots of ideas at the wall to see what sticks. I take jberman's point about anything but a trustless KES being roughly equivalant of e-cash, but I'm not sure there isn't actually a whole middle ground of use cases where you don't trust your counterparty, but you do actually trust the KES, but it's the same great UX that you know and love for those 13:05:04 channels where you absolutely need a trustless KES. Maybe the present analogy is that you don't need GPT-5.4 when you know that Llama-3 can do the job. But you just toggle the model in your interface rather than moving to a different application. 13:05:06 This also speaks to the development approach. jbabb hit the nail on the head with the approach. Given that the final-form KES is way more complicated than I had previously imagined, I'm hesitant to commit to building it if we don't even know whether consumers and merchants will adopt Grease. 13:05:08 Hence the staged approach. I'm more than happy to call the next stage Alpha and define a Beta with final-form KES, btw. It's also why things seem a bit hand-wavy. 13:05:10 I also agree that the KES could be developed in parallel by other parties if they're up for it. We'd have to collaborate closely, but I'd be thrilled if anyone was willing to pitch in. 13:05:12 Where forward from here? I'd love to continue iterating this conversation. It's evident that we're all trying to reach the same outcome here-- putting Monero into the hands of millions of more people, and I'm here for it. 13:05:14 Other minutae: 13:05:16 jbabb: I wasn't trying to be dishonest by calling Grease trustless in the whitepaper. I was thinking only in terms of trust between the parties themselves. I'll need to change that to make the distinction clear. 13:05:19 If there are reasonable primitives that Monero could implement at consensus that would enable a trustless payment channel solution, then I would be open to advocating for that. 13:05:20 Hell yeah, me too. But my base case is that this is incredibly hard -- if not impossible-- because any state on chain must be indistinguishable from noise, otherwise we kill fungibility. 13:05:25 yikes. Sorry for the spam. 13:47:35 The above seems to acknowledge this is a huge problem, and the claim a large-scale threshold multisig as a "thought experiment satisfies the requirement", with no actual consideration towards the need for a competent economic game which had been noted as the issue with such an idea, is too handwavy for me. 13:48:03 To say a token could make sense if the network also offered notarization and gambling is further absurd/obscene to me. 13:49:13 I did consider if Serai could be "upgraded" in this regard, and not really. Assuming everyone was onboard, the channels would only be usable for a few days, and it'd have incredibly expensive disputes. 13:49:24 It'd also require notable cryptography. 13:50:15 Saying that KESs are better by saying we can shotgun random fly-by-night offerings doesn't sound great to me. 13:50:20 > need a trustless KES 13:50:20 No one has proposed one nor suggested one is feasible 13:53:42 I thought KES in that context was related to the BABE part of Serai but now I’m technobabbling 😭 > <@kayabanerve:matrix.org> "Key Evolving Signatures" aren't a thing in Serai (in general?) and I wouldn't call it a Key Escrow Service, even if much of its software could overlap. 14:13:24 The actual necessary work here seems to be on a trustless KES, which doesn't seem possible, and therefore a trust-minimized solution, when no one has actually mapped out a feasible trust-minimized solution (as required to understand the limits of this idea), makes me feel Monero shouldn't sponsor this effort. I don't see any n [... too long, see https://mrelay.p2pool.observer/e/tqOlqvoKbUwyWEpX ] 15:13:32 Following up on this: I have added a comment to the CSS merge request: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667#note_36005 > <@rucknium> 6. CCS proposal: ProbeLab P2P Network Metrics Proposal (https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/667). 15:13:32 We'll make sure that one of us is around for next week's meeting to discuss this in detail. In the meantime feel free to chime in in that comment. 16:34:45 @dennis_tra:matrix.org there was a comment in the #monero-research-lounge:monero.social (less formal channel) 16:34:45 https://matrix.to/#/!zxoYuvZdPYtIuWSQnn:monero.social/$-ebsOekfKnWZunbw3iL4YZr-P794LR-GU-O8PuyR9dg?via=matrix.org&via=monero.social&via=unredacted.org