spitballing.. might there be a userbase/tx volume level where it would be worthwhile to split up the address set and isolate ring member selection to only outputs from your address's output set? The utility is reducing how much churn is necessary to deal with heuristics that become stronger with tx volume (e.g. fixed-size output loops). There is also utility for output scanning (clearly, reducing outputs

necessary to scan by 1/2, reduces scan time by half)

Im assuming that level is lower than the max tx volume the network can support, some optimization point

and if max tx volume rises, then more bifurcation points might be crossed

the biggest problem is it can reveal something about tx recipients, since e.g. in a 2-out tx if the recipients have different

segmentation_flags then they must not be the same recipient

and the more segments there are, the more likely that will happen

What we should do is obtain the cipherspy algorithm, run it, and select ring members that look suspicious.

Take what they eat, and stuff it in their face.

<[keybase] unseddd>: +1 moneromooo, stick it to them

<[keybase] unseddd>: of course, need to be cautious whatever algorithm is used isn't too greedy, and marks legitimate stuff as suspicious/malicious

back up

the power is. and apparently my sentence construction is not

Im curious if for this room you used the matterbridge or the keybase bridge being that the matterbridge also does keybase.

Also if you dont host your own server how did you did this?

I implemented non-linkable, spontaneous, anonymous, group signatures on the Ristretto curve and SHA512 hash: github.com/edwinhere/zero/blob/master/src/main.rs#L374

But my BLSAG implemetation on Ristretto curve and SHA512 hash is failing: github.com/edwinhere/zero/blob/master/src/main.rs

The reconstructed challenge does not match the original challenge. Any help is appreciated

The assert at the end of this function fails when comparing the challenges

Are the challenge inputs being hashed in the same order each time?

Might be useful for debugging to terminal-print everything that's added, and ensure they match each time the challenge is constructed

sarang: thanks. let me try

maybefbi: line 503 it should be a*Hp(K) not a*key_image

UkoeHB_: checking

UkoeHB_: thanks! that fixed it. Good spot. I misread the zero-to-monero-2

:p

There was also one other bug about using cs[1..n] instead of reconstructed_c and i fixed that too

the dreaded two-bug problem

lol

it is 3 AM here. must sleep. got work tomorrow. thanks for all the help. sarang thanks for writing the zero-to-monero. i will make it up to guys somehow

Zero to Monero was UkoeHB_

I only contributed

UkoeHB_: ! thanks i didnt know

Updated PR for handling key encryption in memory and key files: monero-project/monero #6493

<[keybase] unseddd>: you guys are so funny

<[keybase] unseddd>: who are you accusing of being a 3letter agent this week maybefbi? pls, let's not devolve into accusing one another of being agents, it's a technique used to cause infighting in communities. if you have proof, show it

?