Has Ciphertrace replied to the technical questions e-mail? It's been a week or so since they were sent...

Not that I know of

Would have to ask sgp_

I'm adding a CLSAG moneropedia entry. Reviews would be appreciated: monero-project/monero-site #1181

Will take a look :)

28 files changed to add an entry... :S

CLSAG (...) - the ... does not match the SAG, whereas the MLSAG version does. Maybe add "Spontaneous group signatures there too ?

same functionalities *as* (not of).

Replace "went live" with "will go live" since it's in the future still ? Unless it's meant to be pushed afterwards only.

The "which results in..." part is just restating the first part.

usually weights -> weighs

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

the ... does not match the SAG -> That's the definition i found in all the papers. Will wait for sarang's opinion on that

thanks moneromooo will fix later

holy pull request batman

CLSAG == Concise Linkable Spontaneous Anonymous Group (signatures)

It's such a nutso acryonym; we should have changed it from the start

Group signatures require some notion of a fixed group that may be modified by a group manager, e.g.

Ok. Making all these changes locally. Will push them all together later

sech1 sarang no reply yet

thanks sgp_

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.

The notion that some semblance of privacy can be retained even when using an actively malicious remote node also seems unreasonable to me.

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

It can't generate invalid transactions that show as valid, at least

It can.

It can what?

It can generate invalid transactions that show as valid

Not without keys

Unless you mean manipulating order and such

Just like miners can't arbitrarily toss other people's funds around

they can do ordering etc.

I think they can double spend though by including the same transactions multiple times.

Sure, but that's not altering the transactions

Verifying PoW at least asserts that the block and underlying transactions are (very likely) what some miner intended

and transaction validity asserts that the transactions are what the signers intended

sarang what did you mean specifically with "It can't generate invalid transactions that show as valid at least"?

I interpreted that as "a malicious node cannot generate invalid transactions that a wallet using it will use".

My statement was clear as mud =p

I should have said that a remote node cannot generate a transaction signing for outputs it does not control

It can certainly try to mess with blocks, key references, etc.

s/use/accept/

It also cannot control the recipient of a transaction obviously. But other than that pretty much everything is fair game.

The error messages from the remote node are problematic in my eyes as well. AFAICT they are unsatinisized currently.

Right, and verifying PoW at least asserts some form of block integrity

If only we had some piece of software which job it was.

lol

Moving to a "large-ring" signing mechanism would probably require some substantial changes to how decoy requests happen

That said, probabilistic PoW check could be done and would do most of what you say while incurring only a small slowdown.

which is an avenue of risk

Hmm. THough with randomx, I guess it'd mean constant new data set recreation, which can't be amortized anymore.

And connecting to N nodes and some kind of voting structure.

That's still sybillable, but less so.

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

I have a schedule conflict with tomorrow's meeting

Options: cancel until next week, or delay to another convenient time

Recommendations welcome

It was a holiday weekend in the U.S., so some people may not have much to share

cancel imo

That's one vote for cancel

I mean, someone else can lead a meeting whenever they like

or just show up and share research

OK, unless there's a strong vote otherwise, I'll assume tomorrow's meeting is either cancelled, or will be run by someone else

I'll make a note of this in channel tomorrow prior to that time

and update the agenda issue to reflect the next regularly-scheduled meeting