10:40:17 <gingeropolous> huzzah!
10:51:09 <Inge-> yay!
10:51:15 <Inge-> What are we huzza-ing?
10:51:30 <moneromooo> sarang being badass again ?
10:51:41 <Inge-> I thought that was the normal state of things :D
16:22:19 <kinghat[m]> how is surae doing?
16:59:18 <sarang> I just asked him via separate channel. He says he is alive and healthy, and working on two private repos that will be made public soon
17:01:00 <sarang> ^ kinghat[m]
17:01:49 <kinghat[m]> very cool ty!
17:02:41 <jwinterm> kinghat[m], he is on tweeter nonstop
17:03:01 <sarang> I don't have any additional details, sorry
17:03:08 <moneromooo> Is that healthy ?
17:03:36 <jwinterm> trump seems like pretty much most healthy individual ever, so probably I guess
17:04:44 <moneromooo> Physical health I guess.
17:05:18 <kinghat[m]> amphetamines are a hell of a drug
17:05:36 <kinghat[m]> off topic, sorry.
20:39:34 <victorSN> https://ethresear.ch/t/open-problem-improving-stealth-addresses/7438/2
20:45:00 <sarang> Seems like a huge privacy downgrade
20:45:06 <sarang> I would not support such an idea
20:48:38 <UkoeHB_> I'm interested in that approach for large tx volumes, due to anti-ring sig heuristics that become stronger as more tx are available
20:49:46 <sech1> Parallel transaction verification on GPU would be better approach
20:50:52 <sarang> Depends on how inputs are or aren't correlated with chain or external knowledge
20:52:34 <sarang> Linking the tag to a DH shared secret at least ensures uniqueness, at the cost of extra operations besides simple address comparison
20:53:01 <UkoeHB_> If we can define a 'ring sig effectiveness' design goal (with safety factor), there is for any given ring size a tx volume that is too high to achieve it. So, it's possible to segment the address space each time tx volume gets so high that the active segment size passes the limit.
20:53:30 <sarang> Effectiveness has many components
20:54:09 <sarang> and quantifying effectiveness is extremely difficult, since it's highly related to your particular threat model
20:54:29 <sarang> which in turn may depend heavily on knowledge of potentially colluding parties
20:54:32 <UkoeHB_> Well just because it's hard, doesn't mean we can ignore it
20:55:04 <sarang> No, but I don't think quantifying it cleanly is a straightforward task with a straightforward answer
20:55:45 <sarang> and segmentation has a definite and quantifiable effect on the address space
21:00:42 <sarang> A big part of why suraeNoether's graph-weighting approach is so challenging is the need to specify how an adversary assigns weights
21:01:19 <sarang> it's totally dependent on information the adversary has access to, and in turn this depends on users' threat models
21:01:24 <sarang> which likely differ hugely
21:03:31 <sarang> e.g. are you concerned about repeated poisoned outputs?
21:03:38 <sarang> or timing data from an ISP?
21:03:49 <sarang> or repeated exchange interactions where the exchange colludes with other parties?
21:03:53 <sarang> or just on-chain timing data?
21:03:55 <sarang> etc.
21:04:17 <sarang> And the extent to which signer ambiguity plays into particular threat models isn't really known in practice
23:10:15 <Isthmus> "<UkoeHB_> Well just because it's hard, doesn't mean we can ignore it"
23:10:18 <Isthmus> 🤠
23:11:04 <Isthmus> Where's the best documentation of information exchanged between nodes at the peer-to-peer layer? Do we broadcast a user agent string?
23:12:59 <Isthmus> https://usercontent.irccloud-cdn.com/file/fEqWmkLo/image.png
23:13:41 <moneromooo> src/{p2p,cryptonote_protocol}/*defs.h. No.
23:13:49 <Isthmus> Oh good.
23:14:16 <Isthmus> Seems unnecessary. Peers need to agree on protocol version, but imho shouldn't leak software info in the context of a privacy coin :- )
23:14:18 <Isthmus> Thanks @mooo
23:14:51 <moneromooo> You can probably fingerprint anyway.
23:15:26 <Isthmus> What would you use to probe the software version?
23:15:41 <moneromooo> via p2p ?
23:15:45 <Isthmus> Yea
23:16:08 <moneromooo> Ask 101 blocks. If it replies, it's not master.
23:16:59 <moneromooo> If it sends you 250 addresses every "tick", it's older than a few months ago.
23:17:14 * Isthmus is fascinated
23:17:16 <moneromooo> (make this if it sends you some it's already sent you)
23:18:35 <moneromooo> Hopefully soon, you'll be able to make a read request (ie, get blocks), then quickly a write request (ie, submit block), and it'll get quicker. Someone's been working on making the lock read/write.
23:18:50 <moneromooo> That one's probabilistic though.
23:19:43 <moneromooo> If it doesn't send local time, it's pretty new.
23:20:33 <moneromooo> If it claims a version prior to what you expect it to be for that height, it's very old (and forked off).
23:21:08 <Isthmus> I saw on Reddit that peers are claiming versions {12, 13, 60} which is pretty interesting
23:21:12 <moneromooo> If you manage to OOM it and it's got the same peer id when it restarts, it's *very* old.
23:21:28 <Isthmus> Ooooh
23:21:52 <moneromooo> If you ask for 501 blocks and it replies, it's fairly old.
23:22:58 <moneromooo> If it claims pruning, it's at least moderately recent.
23:23:22 <sarang> Isthmus: FWIW I don't think that difficult problems should be ignored :)
23:23:55 <moneromooo> You can check for fairly recent also by asking for pruned blocks, it's a fairly recent addition for p2p.
23:23:57 <Isthmus> @sarang that's already pretty obvious from your work. :- )
23:24:49 <moneromooo> Also fairly recent is duplicate peer lists for backward compat. The dupes are not sent anymore now.
23:25:08 <moneromooo> Probably lots more but I just lost interest in thinking about it :)
23:25:21 <sarang> That's a very interesting problem to consider
23:25:36 <moneromooo> You'd have to scour the git log for exact commit times though.
23:30:12 <hyc> they haven't abandoned that work? nice
23:30:31 <hyc> (oops, replying to scrollback. re: read/write locks)
23:30:37 <moneromooo> The rw lock ? I've not heard anything in a while,  but I assume not.
23:31:05 <selsta> Who is working on that?
23:31:46 <hyc> there was a locknig rewrite PR
23:32:03 <moneromooo> Oh, it was PRed ?
23:32:05 <hyc> we NAK'd it because it changed more than just that
23:32:15 <hyc> that's not what you'r thinking of? the db_lmdb rewrite
23:32:27 <moneromooo> Oh, that does ring a bell, yes...
23:32:53 <selsta> https://github.com/monero-project/monero/pull/6401
23:33:06 <selsta> they have closed the PR because they don’t have the time to work on it
23:33:37 <moneromooo> Closed with the comment, to make sure nobody reads it :D
23:33:46 <hyc> lol
23:34:23 <moneromooo> Well, too bad. Maybe I'll have a go when I get more time.
23:34:51 <moneromooo> Unless el hyc wants to cook us a turbo charged db ^_^
23:35:03 <hyc> ufff
23:35:21 <hyc> I've always put that off, because the changes would be on the scale of that PR - large and invasive
23:36:02 <hyc> it would be a pain for anyone to review
23:36:06 <moneromooo> Just changes to db_lmdb. I expected changes mostly in blockchain.cpp.
23:36:20 <moneromooo> To replace the lock with a rw lock and associated bookkeeping.
23:36:53 <hyc> I have the feeling things would leak beyond blockchain.cpp
23:37:21 <hyc> to really do things right I would want read-only and reawrite txns used consistently
23:37:56 <hyc> that means everything that accesses blockchain data will have to have a txn-aware wrapper somewhere
23:37:57 <moneromooo> That can be done first I guess. Preliminary work in a PR.
23:39:46 <hyc> and then flatten the blockchain_db abstraction layer
23:40:09 <hyc> right now add_block calls down and up and down again fromb blockchain_db to db_mdb and back
23:40:14 <hyc> it's nuty
23:40:16 <hyc> nutty