Grupo Monero no Xmpp

Mais leve que a rede Matrix, e muito mais fluido

xmpp:monero-brasil---sem-ban⊙cci?join

9~ hours to create many addresses . now 9~ minutes thanks to moneromoo monero-project/monero #5370#issuecomment-1436154807

You're welcome :)

damn

sounds like unordered map really sucks

is flat_map ordered?

sucks how?

looking at the perf diff noted above

it's O(1). Yes, actual default implementations may be slow or waste memory, but there are better implementations

like the one I use in p2pool

9 hours down to 9 minutes sounds more like poor hashing function, so it's not O(1) anymore

indeed

flat_map probably just takes better precautions when hashing user data

is it ordered? since they're taking the trouble to sort to check for duplicates

seems odd to me that the map itself can't warn you of duplicates

now wait, it's not a hash map

Complexity: Logarithmic.

ah yes, ordered sequence container

so, some kind of tree, not a hash

"random access iterators" - the word "iterator" was always a mistake. these are cursors.

C++ is such a stupid language...

ordered sequence container that uses a vector to store elements, interesting

so it takes advantage of CPU caching for faster access

and has random access iterators

so if O(logN) container beats O(1) container, it's definitely a problem with hash function

beats by 60x, lol

simple stuff we learned in data structures classes in the 1980s. seems like all forgotten by the current generation

it's a different problem here though: std::vector<std::vector<std::string>> m_subaddress_labels;

current code resizes the vertor every time you call wallet2::add_subaddress(), so it's O(N^2)

if you add addresses one by one

monero-project/monero #5370/commits/cc379879e755315953e47e3bfb69b464cf634840 fixes it so vector gets resized only once

so, it's got nothing to do with the map type at all

Seraphis meeting today at 18:00 UTC in Matrix room--No Wallet Left Behind.

I had a second patch to use a map for non-empty labels, didn't help save/open but I did not test insert...

tevador: here is my idea for the eclib abstraction UkoeHB/monero 5b9b030 however it has a linker error in the unit test (the eclib::utils::util_func()) that I am stumped on. What I'm trying to do is instantiate the utils functions inside the eclib_interface.cpp file so the linker can connect with those. I don't want to include the full eclib_utils template everywhere

since that would be a compiletime horror.

the overall goal is that you can switch this statement `using eclib = crypto::eclib_test;` and everything that uses `eclib::` will just continue to work nicely

UkoeHB: I think you need to put "template<>" in front of "eclib_test::core_func" in eclib_test.cpp

tevador: the core_func() works fine, its the util_func() that doesn't link

you can't just include a template in a single file, other files won't see it and won't be able to instantiate it

if you want to do this, you have to declare each instantiation of this template in a header

then these instantiations will link

TLDR - Need a quantifiable counter measure for preventing the Overseer Attack. Will be paying for this research. Want to get started sooner rather than later.... (full message at <libera.ems.host/_matrix/media/v3/do…6dedc8b46b2583e49d97e499997ae31f7b2>)

it doesn't need to be in the header, it can be explicitly instantiated in one cpp file

I mean, yes

sech1: I put a template declaration in a header file

template declaration in a header, and explicit instantiaion in some cpp

and trying to instantiate the bodies in one cpp

no, it doesn't work like this. You have to explicitly instantiate it as a declaration in this cpp

it still needs template<> void eclib_utils<eclib_test>::util_func(...); somewhere

if you don't do it, compiler makes it internal linkage, or even just inlines the code

ok looks like I needed to add `template struct eclib_utils<eclib_test>;` to the eclib_interface.cpp file