-
gingeropolous
huzzah!
-
Inge-
yay!
-
Inge-
What are we huzza-ing?
-
moneromooo
sarang being badass again ?
-
Inge-
I thought that was the normal state of things :D
-
kinghat[m]
how is surae doing?
-
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
-
sarang
^ kinghat[m]
-
kinghat[m]
very cool ty!
-
jwinterm
kinghat[m], he is on tweeter nonstop
-
sarang
I don't have any additional details, sorry
-
moneromooo
Is that healthy ?
-
jwinterm
trump seems like pretty much most healthy individual ever, so probably I guess
-
moneromooo
Physical health I guess.
-
kinghat[m]
amphetamines are a hell of a drug
-
kinghat[m]
off topic, sorry.
-
victorSN
-
sarang
Seems like a huge privacy downgrade
-
sarang
I would not support such an idea
-
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
-
sech1
Parallel transaction verification on GPU would be better approach
-
sarang
Depends on how inputs are or aren't correlated with chain or external knowledge
-
sarang
Linking the tag to a DH shared secret at least ensures uniqueness, at the cost of extra operations besides simple address comparison
-
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.
-
sarang
Effectiveness has many components
-
sarang
and quantifying effectiveness is extremely difficult, since it's highly related to your particular threat model
-
sarang
which in turn may depend heavily on knowledge of potentially colluding parties
-
UkoeHB_
Well just because it's hard, doesn't mean we can ignore it
-
sarang
No, but I don't think quantifying it cleanly is a straightforward task with a straightforward answer
-
sarang
and segmentation has a definite and quantifiable effect on the address space
-
sarang
A big part of why suraeNoether's graph-weighting approach is so challenging is the need to specify how an adversary assigns weights
-
sarang
it's totally dependent on information the adversary has access to, and in turn this depends on users' threat models
-
sarang
which likely differ hugely
-
sarang
e.g. are you concerned about repeated poisoned outputs?
-
sarang
or timing data from an ISP?
-
sarang
or repeated exchange interactions where the exchange colludes with other parties?
-
sarang
or just on-chain timing data?
-
sarang
etc.
-
sarang
And the extent to which signer ambiguity plays into particular threat models isn't really known in practice
-
Isthmus
"<UkoeHB_> Well just because it's hard, doesn't mean we can ignore it"
-
Isthmus
🤠
-
Isthmus
Where's the best documentation of information exchanged between nodes at the peer-to-peer layer? Do we broadcast a user agent string?
-
Isthmus
-
moneromooo
src/{p2p,cryptonote_protocol}/*defs.h. No.
-
Isthmus
Oh good.
-
Isthmus
Seems unnecessary. Peers need to agree on protocol version, but imho shouldn't leak software info in the context of a privacy coin :- )
-
Isthmus
Thanks @mooo
-
moneromooo
You can probably fingerprint anyway.
-
Isthmus
What would you use to probe the software version?
-
moneromooo
via p2p ?
-
Isthmus
Yea
-
moneromooo
Ask 101 blocks. If it replies, it's not master.
-
moneromooo
If it sends you 250 addresses every "tick", it's older than a few months ago.
-
» Isthmus is fascinated
-
moneromooo
(make this if it sends you some it's already sent you)
-
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.
-
moneromooo
That one's probabilistic though.
-
moneromooo
If it doesn't send local time, it's pretty new.
-
moneromooo
If it claims a version prior to what you expect it to be for that height, it's very old (and forked off).
-
Isthmus
I saw on Reddit that peers are claiming versions {12, 13, 60} which is pretty interesting
-
moneromooo
If you manage to OOM it and it's got the same peer id when it restarts, it's *very* old.
-
Isthmus
Ooooh
-
moneromooo
If you ask for 501 blocks and it replies, it's fairly old.
-
moneromooo
If it claims pruning, it's at least moderately recent.
-
sarang
Isthmus: FWIW I don't think that difficult problems should be ignored :)
-
moneromooo
You can check for fairly recent also by asking for pruned blocks, it's a fairly recent addition for p2p.
-
Isthmus
@sarang that's already pretty obvious from your work. :- )
-
moneromooo
Also fairly recent is duplicate peer lists for backward compat. The dupes are not sent anymore now.
-
moneromooo
Probably lots more but I just lost interest in thinking about it :)
-
sarang
That's a very interesting problem to consider
-
moneromooo
You'd have to scour the git log for exact commit times though.
-
hyc
they haven't abandoned that work? nice
-
hyc
(oops, replying to scrollback. re: read/write locks)
-
moneromooo
The rw lock ? I've not heard anything in a while, but I assume not.
-
selsta
Who is working on that?
-
hyc
there was a locknig rewrite PR
-
moneromooo
Oh, it was PRed ?
-
hyc
we NAK'd it because it changed more than just that
-
hyc
that's not what you'r thinking of? the db_lmdb rewrite
-
moneromooo
Oh, that does ring a bell, yes...
-
selsta
-
selsta
they have closed the PR because they don’t have the time to work on it
-
moneromooo
Closed with the comment, to make sure nobody reads it :D
-
hyc
lol
-
moneromooo
Well, too bad. Maybe I'll have a go when I get more time.
-
moneromooo
Unless el hyc wants to cook us a turbo charged db ^_^
-
hyc
ufff
-
hyc
I've always put that off, because the changes would be on the scale of that PR - large and invasive
-
hyc
it would be a pain for anyone to review
-
moneromooo
Just changes to db_lmdb. I expected changes mostly in blockchain.cpp.
-
moneromooo
To replace the lock with a rw lock and associated bookkeeping.
-
hyc
I have the feeling things would leak beyond blockchain.cpp
-
hyc
to really do things right I would want read-only and reawrite txns used consistently
-
hyc
that means everything that accesses blockchain data will have to have a txn-aware wrapper somewhere
-
moneromooo
That can be done first I guess. Preliminary work in a PR.
-
hyc
and then flatten the blockchain_db abstraction layer
-
hyc
right now add_block calls down and up and down again fromb blockchain_db to db_mdb and back
-
hyc
it's nuty
-
hyc
nutty