<j​effro256:monero.social> Thanks for bringing it to my attention, I'm looking into it. At first glance, it seems like a bug with the server HTTP auth code, but could definitely be a problem with my linked PR

would be good to also add a test case that catches this in the future

<j​effro256:monero.social> Agreed

<j​effro256:monero.social> jk its totally that PR, fix is simple though

<0​xfffc:matrix.org> jeffro256: monero-project/monero #9235#issuecomment-1987521040

xmrchain on 18.3.2 uptime 1d 12h 33m 50s

and my main remote node which always seems to be serving about 46 wallet users: uptime 1d 12h 40m 56s

.merge+ 9228 9229 9237 9238

Added

<r​ecanman:agoradesk.com> Hi, I wanted to double-check something: When generating an integrated address from a primary address and a secret view key, there is no similarity in the first few characters of the addresses

<r​ecanman:agoradesk.com> Example:

<r​ecanman:agoradesk.com> `888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1UXcdRsiKc9dhwMVgN5S9cQUiyoogDavup3H`

<r​ecanman:agoradesk.com> `f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501`

<r​ecanman:agoradesk.com> Integrated:

<r​ecanman:agoradesk.com> `4DrvGduF3ynBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVPmcCGKLkQMSRcAqdhF`

the first is a subaddress

there are no integrated subaddresses

<r​ecanman:agoradesk.com> Oops, I meant a base address

<r​ecanman:agoradesk.com> That was the monero general fund

<r​ecanman:agoradesk.com> 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A

<r​ecanman:agoradesk.com> Well, I mean in general. Not pertained to a specific address

<s​ethforprivacy:agoradesk.com> Hey all, quick question -- is there a way to compile without requiring any execinfo? It's for a Docker container so backtraces aren't commonly needed, and I can't update my base image without removing this as all libexecinfo packages have been deprecated for Alpine.

<t​obtoht:monero.social> Build with -DSTACK_TRACE=OFF

<s​ethforprivacy:agoradesk.com> Thank you!

<s​ethforprivacy:agoradesk.com> Hmm, these are my flags now but still errors out on missing execinfo.h:

<s​ethforprivacy:agoradesk.com> ` && cmake -D ARCH=${CMAKE_ARCH} -D STATIC=ON -D BUILD_64=ON -D CMAKE_BUILD_TYPE=Release -D BUILD_TAG=${CMAKE_BUILD_TAG} -D STACK_TRACE=OFF ../.. \

<s​ethforprivacy:agoradesk.com> `

<s​ethforprivacy:agoradesk.com> `23.92 /monero/external/easylogging++/easylogging++.h:384:13: fatal error: execinfo.h: No such file or directory`

<t​obtoht:monero.social> Does cmake log contain "Stack trace on exception disabled" ?

<t​obtoht:monero.social> Seth: if it's of any help, this builds: paste.debian.net/plainh/346ca815

<s​ethforprivacy:agoradesk.com> Yes, I do

<s​ethforprivacy:agoradesk.com> Wonder if there is some hard requirement for static builds...

<s​ethforprivacy:agoradesk.com> Still seems like it looks for a backtrace library:

<s​ethforprivacy:agoradesk.com> ```

<s​ethforprivacy:agoradesk.com> #18 14.95 -- Looking for backtrace

<s​ethforprivacy:agoradesk.com> #18 14.98 -- Looking for backtrace - not found

<s​ethforprivacy:agoradesk.com> #18 14.98 -- Backtrace_LIBRARY:

<s​ethforprivacy:agoradesk.com> #18 14.98 -- Could NOT find Backtrace (missing: Backtrace_LIBRARY Backtrace_INCLUDE_DIR)

<s​ethforprivacy:agoradesk.com> ```

<t​obtoht:monero.social> I'd be happy to debug if you can share the Dockerfile

<s​ethforprivacy:agoradesk.com> paste.sethforprivacy.com/?e26ac2c26…UqmkHFS4eReBrUX3B4BSuJYYbuxf1xWbUVp

<s​ethforprivacy:agoradesk.com> The source for it is here but I haven't pushed the latest there yet: github.com/sethforprivacy/simple-mo…od-docker/blob/bump-deps/Dockerfile

<t​obtoht:monero.social> Remove "-DELPP_FEATURE_CRASH_LOG" on line 90

should i wait another day for more possible bug reports or tag today with the rpc-login fix?

0.18.3.3, so soon?

Maybe add new checkpoints as well

selsta: Did you active the automatic updater already for the GUI?

no

will wait for .3

and yes i'll add checkpoints

checkpoints through the current full blocks will really help

<s​ethforprivacy:agoradesk.com> Amazing, that fixed it :D Thanks so much tobtoht

.merge+ 9239

Added

<x​fedex:matrix.org> how about doubling the transaction fees?

<o​frnxmr:agoradesk.com> Dont troll here

<o​frnxmr:agoradesk.com> Were not hard forkin tmrw

<x​fedex:matrix.org> i'm not talking about tomorrow, more like in future months

<o​frnxmr:agoradesk.com> Auto is aka elevate to normal is >2x

<o​frnxmr:agoradesk.com> so you want "normal" to be 2x,before youve used or seen normal>

<x​fedex:matrix.org> I've noticed that wallet sync time has increased significantly in the last days. A significant part of Monero's user base is on mobile devices. If Monero wants to remain a currency, it needs to be easily usable for everyone, without using "Light Wallets" which compromise privacy

<j​effro256:monero.social> You might be interested in the Jamtis light wallet developments, which are light wallets (~100x faster than full wallets) with significantly better privacy guarantees github.com/UkoeHB/Seraphis/blob/mas…ng_seraphis/Impl-Seraphis-0-0-3.pdf

<j​effro256:monero.social> *better than Cryptonote light wallets

<r​ucknium:monero.social> xfedex: It is suspected that the sync slowdown is because of the size of the mempool + users not updating to the 0.18.3.1 wallet version that reduced mempool data transfer: monero-project/monero #8800

<j​effro256:monero.social> No deterministic tx information is revealed. The only information light wallet servers can compute is view tags

<r​ucknium:monero.social> So changing fees won't fix that

<r​ucknium:monero.social> AFAIK it's mostly mobile wallets that connect users to their own nodes, e.g. Cake and Exodus, that are having the most slowdown. Probably those wallets could require users to upgrade by blocking wallets that do not use the new mempool update code, as a last resort.

<r​ucknium:monero.social> AFAIK, Exodus uses their own custom code instead of `wallet2`. I don't know what they would have to do to fix sync times.

<j​ack_ma_blabla:matrix.org> Jamtis light wallet can be done before serpahis ?

<x​fedex:matrix.org> sure, wallet sync time can be improved if you upgrade to latest version and use faster nodes, but my point is that i think ~0.004-5$ for a 1 input 2 outputs transaction is too low, because it allows spamming the network too much easily

<x​fedex:matrix.org> median Bitcoin transaction fee is 3.35$, i don't think $0.01-0.02 fees would bother normal Monero users much - but they would make attackers spend 2x more money

just double XMR price and you'll get 2x higher fees

<j​ack_ma_blabla:matrix.org> if devs can do that :)

<x​fedex:matrix.org> if XMR price doubles, wouldn't transaction fees in XMR reduce, thus remain similar in USD amount? considering that, if price increases, then the number of transaction per block increase

<x​fedex:matrix.org> because higher price = more users

lol

<j​ack_ma_blabla:matrix.org> more users = more transactions ? dont we already have more transactions and cheaper txs , more txs = more cheaper xmr fees, its works well for whoever is sending these transactions

fees are not cheaper yet

<j​ack_ma_blabla:matrix.org> so it can still get cheaper, didnt know that good times ahead

<f​rankojus:matrix.org> Hey guys, is there a way i can compile monero from source so it runs using more cpu cores?

<g​fdshygti53:monero.social> You will need to also update the code so it can do that.

<g​fdshygti53:monero.social> And publish the patch so everyone could benefit from it.

<f​rankojus:matrix.org> alright.. thanks.

<f​rankojus:matrix.org> i'm facing an issue, where i have allocated 3cpu core but nodes are only consuming 1core... is this normal?

do you run in docker or something similar?

<f​rankojus:matrix.org> yes, i use docker

i have seen a couple people ask that when using docker

but i don't know what the conclusion was

monerod itself can take advantage of multiple cores without having to do anything

<j​effro256:monero.social> Technically speaking, yes, but there's no plans to do so

<f​rankojus:matrix.org> interesting.. we currently run our monero nodes on k8s... and we are facing this issue..trying to see if compiling from source using docker helps or not.

<j​ack_ma_blabla:matrix.org> wouldnt it be better to do that before seraphis, wallets would be well tested by then ?

<j​ack_ma_blabla:matrix.org> wouldnt it be better to do that before seraphis, wallets would be well tested by then ? or it doubles the work for seraphis

<j​effro256:monero.social> It would mean a lot of extra dev work, and since we may switch to a new elliptic curve for Seraphis anyways, we would have to upgrade the address format again

<x​fedex:matrix.org> i've created an issue on Github. monero-project/monero #9240

<f​rankojus:matrix.org> do you have any link or direction you could point me to. That would be helpful. Thanks

.merges

luigi1111w: please do merges and then tag v0.18.3.3

It does get a bit hectic, with .3 already :)

But on the other hand we show a good reactio time, if you ask me

<g​fdshygti53:monero.social> Fast reaction time is a good metric imo. It show to others that we actually do care...

<g​fdshygti53:monero.social> It also did show to the world that the Monero team will even work a weekend to fix issues...

<1​23bob123:matrix.org> Still have to wait for core…

Yes, it's refreshing to see how we improve after the chance to stress-test everything that this provided :)

monero-project/monero #9234 is ready to be reviewed

wow we release fast

j​effro256: I read your commit message in dfb990e8bb606c4c50ed0e06b439601d348c86a7. I do not understand what in monero corresponds to removing marbles with letter A if we picked a marble with A. Can you expand a little on this please ?

<e​dge7:matrix.org> The marbles don't represent outputs themselves, they represent units of probability proportional to how likely a unique value will be picked.

<e​dge7:matrix.org> Got it from:

<e​dge7:matrix.org> monero-project/monero #9023#issuecomment-1773914631

ty

<e​dge7:matrix.org> I read it twice to convince myself. In short as gamma has values that are far more likely than others, if you start sampling without replacement at some point the distribution naturally would like to take something that had been already taken.. But they need to be unique... The more you sample (# potential decoys to choice from) the more the thing gets worse.

OK, I see your reasoning's intuition. Thanks.

<j​effro256:monero.social> edge7: thats a great summary

<j​effro256:monero.social> The gamma distribution is very concentrated on a few values and wants to repeat some picks. However, if we force uniqueness of the picks, the distribution will start skewing towards a uniform distribution the more and more we pick

<j​effro256:monero.social> The more we force the picks to take on unique values, the less it represents the original distribution

luigi1111w: let's wait until tomorrow to see if we get more bug reports, otherwise we tag

only one person so far has complained about the regression so appear there aren't too many affected