06:00:33 Has Ciphertrace replied to the technical questions e-mail? It's been a week or so since they were sent... 11:19:00 Not that I know of 11:19:08 Would have to ask sgp_ 11:50:27 I'm adding a CLSAG moneropedia entry. Reviews would be appreciated: https://github.com/monero-project/monero-site/pull/1181 11:56:44 Will take a look :) 12:02:52 28 files changed to add an entry... :S 12:04:15 CLSAG (...) - the ... does not match the SAG, whereas the MLSAG version does. Maybe add "Spontaneous group signatures there too ? 12:04:48 same functionalities *as* (not of). 12:05:11 Replace "went live" with "will go live" since it's in the future still ? Unless it's meant to be pushed afterwards only. 12:05:40 The "which results in..." part is just restating the first part. 12:06:11 usually weights -> weighs 12:21:04 28 files changed to add an entry -> that drives me crazy every single time. Same for user guides. Waiting on Weblate to add support for markdown files, because the other solution is to rebuild the way the entire moneropedia works. Which would take a shitload of time 12:21:45 the ... does not match the SAG -> That's the definition i found in all the papers. Will wait for sarang's opinion on that 12:22:00 thanks moneromooo will fix later 12:46:38 holy pull request batman 12:48:37 CLSAG == Concise Linkable Spontaneous Anonymous Group (signatures) 12:48:49 It's such a nutso acryonym; we should have changed it from the start 12:49:22 Group signatures require some notion of a fixed group that may be modified by a group manager, e.g. 12:52:45 Ok. Making all these changes locally. Will push them all together later 13:15:48 sech1 sarang no reply yet 13:18:33 thanks sgp_ 13:20:59 something that has been bothering me since quite while is the question whether the wallet should be checking proof of work when getting blocks from a remote daemon. In any case it worries me how many services have embraced using remote nodes without a clear understanding of the risk. 13:24:03 The notion that some semblance of privacy can be retained even when using an actively malicious remote node also seems unreasonable to me. 13:28:09 If there's any concern that failure to check PoW could mean that a malicious node can do things like reorder transactions in blocks or censor them, it should be checked 13:28:33 It can't generate invalid transactions that show as valid, at least 13:28:41 It can. 13:29:41 It can what? 13:29:56 It can generate invalid transactions that show as valid 13:30:21 Not without keys 13:30:31 Unless you mean manipulating order and such 13:30:44 Just like miners can't arbitrarily toss other people's funds around 13:30:49 they can do ordering etc. 13:35:48 I think they can double spend though by including the same transactions multiple times. 13:39:32 Sure, but that's not altering the transactions 13:39:57 Verifying PoW at least asserts that the block and underlying transactions are (very likely) what some miner intended 13:40:12 and transaction validity asserts that the transactions are what the signers intended 13:46:49 sarang what did you mean specifically with "It can't generate invalid transactions that show as valid at least"? 13:49:12 I interpreted that as "a malicious node cannot generate invalid transactions that a wallet using it will use". 13:49:25 My statement was clear as mud =p 13:49:47 I should have said that a remote node cannot generate a transaction signing for outputs it does not control 13:50:00 It can certainly try to mess with blocks, key references, etc. 13:50:26 s/use/accept/ 13:50:26 moneromooo meant to say: I interpreted that as "a malicious node cannot generate invalid transactions that a wallet using it will accept". 14:06:14 It also cannot control the recipient of a transaction obviously. But other than that pretty much everything is fair game. 14:07:15 The error messages from the remote node are problematic in my eyes as well. AFAICT they are unsatinisized currently. 14:10:29 Right, and verifying PoW at least asserts some form of block integrity 14:11:05 If only we had some piece of software which job it was. 14:11:10 lol 14:12:56 Moving to a "large-ring" signing mechanism would probably require some substantial changes to how decoy requests happen 14:13:00 That said, probabilistic PoW check could be done and would do most of what you say while incurring only a small slowdown. 14:13:05 which is an avenue of risk 14:13:33 Hmm. THough with randomx, I guess it'd mean constant new data set recreation, which can't be amortized anymore. 14:13:53 And connecting to N nodes and some kind of voting structure. 14:14:01 That's still sybillable, but less so. 14:15:50 FWIW in the future, using fixed anon set groups (epochs/whatever), the client could cache hashes of them as it receives chain data, and verify what it receives from the remote node 19:57:38 I have a schedule conflict with tomorrow's meeting 19:57:54 Options: cancel until next week, or delay to another convenient time 19:58:05 Recommendations welcome 19:58:36 It was a holiday weekend in the U.S., so some people may not have much to share 20:14:48 cancel imo 20:27:58 That's one vote for cancel 20:28:18 I mean, someone else can lead a meeting whenever they like 20:28:21 or just show up and share research 20:41:37 OK, unless there's a strong vote otherwise, I'll assume tomorrow's meeting is either cancelled, or will be run by someone else 20:41:49 I'll make a note of this in channel tomorrow prior to that time 20:41:59 and update the agenda issue to reflect the next regularly-scheduled meeting 20:42:52 https://github.com/monero-project/meta/issues/505