01:18:15 <m-relay> <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
01:42:01 <selsta> would be good to also add a test case that catches this in the future
01:42:26 <m-relay> <j​effro256:monero.social> Agreed
02:27:40 <m-relay> <j​effro256:monero.social> jk its totally that PR, fix is simple though
02:38:09 <m-relay> <0​xfffc:matrix.org> jeffro256:  https://github.com/monero-project/monero/issues/9235#issuecomment-1987521040
03:45:34 <gingeropolous> xmrchain on 18.3.2 uptime 1d 12h 33m 50s
03:46:57 <gingeropolous> and my main remote node which always seems to be serving about 46 wallet users: uptime 1d 12h 40m 56s
04:10:59 <selsta> .merge+ 9228 9229 9237 9238
04:10:59 <xmr-pr> Added
04:41:30 <m-relay> <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
04:41:55 <m-relay> <r​ecanman:agoradesk.com> Example:
04:41:55 <m-relay> <r​ecanman:agoradesk.com> `888tNkZrPN6JsEgekjMnABU4TBzc2Dt29EPAvkRxbANsAnjyPbb3iQ1YBRk1UXcdRsiKc9dhwMVgN5S9cQUiyoogDavup3H`
04:41:56 <m-relay> <r​ecanman:agoradesk.com> `f359631075708155cc3d92a32b75a7d02a5dcf27756707b47a2b31b21c389501`
04:41:56 <m-relay> <r​ecanman:agoradesk.com> Integrated:
04:41:57 <m-relay> <r​ecanman:agoradesk.com> `4DrvGduF3ynBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVPmcCGKLkQMSRcAqdhF`
05:06:18 <selsta> the first is a subaddress
05:06:31 <selsta> there are no integrated subaddresses
05:57:11 <m-relay> <r​ecanman:agoradesk.com> Oops, I meant a base address
05:57:16 <m-relay> <r​ecanman:agoradesk.com> That was the monero general fund
05:57:28 <m-relay> <r​ecanman:agoradesk.com> 44AFFq5kSiGBoZ4NMDwYtN18obc8AemS33DBLWs3H7otXft3XjrpDtQGv7SqSsaBYBb98uNbr2VBBEt7f2wfn3RVGQBEP3A
05:57:44 <m-relay> <r​ecanman:agoradesk.com> Well, I mean in general. Not pertained to a specific address
10:48:57 <m-relay> <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.
11:37:27 <m-relay> <t​obtoht:monero.social> Build with -DSTACK_TRACE=OFF
11:41:44 <m-relay> <s​ethforprivacy:agoradesk.com> Thank you!
11:44:44 <m-relay> <s​ethforprivacy:agoradesk.com> Hmm, these are my flags now but still errors out on missing execinfo.h:
11:44:44 <m-relay> <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 ../.. \
11:44:45 <m-relay> <s​ethforprivacy:agoradesk.com> `
11:45:08 <m-relay> <s​ethforprivacy:agoradesk.com> `23.92 /monero/external/easylogging++/easylogging++.h:384:13: fatal error: execinfo.h: No such file or directory`
12:01:26 <m-relay> <t​obtoht:monero.social> Does cmake log contain "Stack trace on exception disabled" ?
12:19:19 <m-relay> <t​obtoht:monero.social> Seth: if it's of any help, this builds: https://paste.debian.net/plainh/346ca815
12:55:39 <m-relay> <s​ethforprivacy:agoradesk.com> Yes, I do
12:55:47 <m-relay> <s​ethforprivacy:agoradesk.com> Wonder if there is some hard requirement for static builds...
12:58:34 <m-relay> <s​ethforprivacy:agoradesk.com> Still seems like it looks for a backtrace library:
12:58:35 <m-relay> <s​ethforprivacy:agoradesk.com> ```
12:58:35 <m-relay> <s​ethforprivacy:agoradesk.com> #18 14.95 -- Looking for backtrace
12:58:36 <m-relay> <s​ethforprivacy:agoradesk.com> #18 14.98 -- Looking for backtrace - not found
12:58:36 <m-relay> <s​ethforprivacy:agoradesk.com> #18 14.98 -- Backtrace_LIBRARY: 
12:58:37 <m-relay> <s​ethforprivacy:agoradesk.com> #18 14.98 -- Could NOT find Backtrace (missing: Backtrace_LIBRARY Backtrace_INCLUDE_DIR)
12:58:37 <m-relay> <s​ethforprivacy:agoradesk.com> ```
13:10:57 <m-relay> <t​obtoht:monero.social> I'd be happy to debug if you can share the Dockerfile
13:19:53 <m-relay> <s​ethforprivacy:agoradesk.com> https://paste.sethforprivacy.com/?e26ac2c266bac81b#8KqFGUs2QUqmkHFS4eReBrUX3B4BSuJYYbuxf1xWbUVp
13:20:48 <m-relay> <s​ethforprivacy:agoradesk.com> The source for it is here but I haven't pushed the latest there yet: https://github.com/sethforprivacy/simple-monerod-docker/blob/bump-deps/Dockerfile
13:42:29 <m-relay> <t​obtoht:monero.social> Remove "-DELPP_FEATURE_CRASH_LOG" on line 90
13:53:39 <selsta> should i wait another day for more possible bug reports or tag today with the rpc-login fix?
13:55:06 <sech1> 0.18.3.3, so soon?
13:55:15 <sech1> Maybe add new checkpoints as well
13:55:34 <dEBRUYNE> selsta: Did you active the automatic updater already for the GUI?
13:55:38 <selsta> no
13:56:02 <selsta> will wait for .3
13:56:18 <selsta> and yes i'll add checkpoints
13:59:01 <sech1> checkpoints through the current full blocks will really help
14:07:37 <m-relay> <s​ethforprivacy:agoradesk.com> Amazing, that fixed it :D Thanks so much tobtoht
14:33:53 <selsta> .merge+ 9239
14:33:53 <xmr-pr> Added
14:36:22 <m-relay> <x​fedex:matrix.org> how about doubling the transaction fees?
14:39:05 <m-relay> <o​frnxmr:agoradesk.com> Dont troll here
14:39:15 <m-relay> <o​frnxmr:agoradesk.com> Were not hard forkin tmrw
14:40:01 <m-relay> <x​fedex:matrix.org> i'm not talking about tomorrow, more like in future months
14:40:33 <m-relay> <o​frnxmr:agoradesk.com> Auto is aka elevate to normal is >2x
14:41:10 <m-relay> <o​frnxmr:agoradesk.com> so you want "normal" to be 2x,before youve used or seen normal>
14:49:42 <m-relay> <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
14:59:32 <m-relay> <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 https://github.com/UkoeHB/Seraphis/blob/master/implementing_seraphis/Impl-Seraphis-0-0-3.pdf
14:59:54 <m-relay> <j​effro256:monero.social> *better than Cryptonote light wallets
15:02:23 <m-relay> <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: https://github.com/monero-project/monero/pull/8800
15:02:24 <m-relay> <j​effro256:monero.social> No deterministic tx information is revealed. The only information light wallet servers can compute is view tags
15:02:35 <m-relay> <r​ucknium:monero.social> So changing fees won't fix that
15:04:00 <m-relay> <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.
15:04:42 <m-relay> <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.
15:05:50 <m-relay> <j​ack_ma_blabla:matrix.org> Jamtis light wallet can be done before serpahis ?
15:08:10 <m-relay> <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
15:09:36 <m-relay> <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
15:10:06 <sech1> just double XMR price and you'll get 2x higher fees
15:10:26 <m-relay> <j​ack_ma_blabla:matrix.org> if devs can do that :)
15:11:26 <m-relay> <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
15:11:53 <m-relay> <x​fedex:matrix.org> because higher price = more users
15:12:02 <hyc> lol
15:13:34 <m-relay> <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
15:14:00 <sech1> fees are not cheaper yet
15:14:31 <m-relay> <j​ack_ma_blabla:matrix.org> so it can still get cheaper, didnt know that good times ahead
15:15:59 <m-relay> <f​rankojus:matrix.org> Hey guys, is there a way i can compile monero from source so it runs using more cpu cores?
15:16:56 <m-relay> <g​fdshygti53:monero.social> You will need to also update the code so it can do that.
15:16:56 <m-relay> <g​fdshygti53:monero.social> And publish the patch so everyone could benefit from it.
15:21:41 <m-relay> <f​rankojus:matrix.org> alright.. thanks.
15:21:41 <m-relay> <f​rankojus:matrix.org> i'm facing an issue, where i have allocated 3cpu core but nodes are only consuming 1core... is this normal?
15:22:50 <selsta> do you run in docker or something similar?
15:23:18 <m-relay> <f​rankojus:matrix.org> yes, i use docker
15:28:03 <selsta> i have seen a couple people ask that when using docker
15:28:13 <selsta> but i don't know what the conclusion was
15:29:53 <selsta> monerod itself can take advantage of multiple cores without having to do anything
15:31:51 <m-relay> <j​effro256:monero.social> Technically speaking, yes, but there's no plans to do so
15:32:12 <m-relay> <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.
15:33:00 <m-relay> <j​ack_ma_blabla:matrix.org> wouldnt it be better to do that before seraphis, wallets would be well tested by then ?
15:33:28 <m-relay> <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
15:36:39 <m-relay> <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
15:37:18 <m-relay> <x​fedex:matrix.org> i've created an issue on Github. https://github.com/monero-project/monero/issues/9240
16:34:25 <m-relay> <f​rankojus:matrix.org> do you have any link or direction you could point me to. That would be helpful. Thanks
18:22:04 <selsta> .merges
18:22:04 -xmr-pr- 9228 9229 9237 9238 9239
18:22:42 <selsta> luigi1111w: please do merges and then tag v0.18.3.3
19:07:21 <rbrunner> It does get a bit hectic, with .3 already :)
19:07:39 <rbrunner> But on the other hand we show a good reactio time, if you ask me
19:10:40 <m-relay> <g​fdshygti53:monero.social> Fast reaction time is a good metric imo. It show to others that we actually do care...
19:10:41 <m-relay> <g​fdshygti53:monero.social> It also did show to the world that the Monero team will even work a weekend to fix issues...
19:12:24 <m-relay> <1​23bob123:matrix.org> Still have to wait for core…
19:29:38 <rbrunner> Yes, it's refreshing to see how we improve after the chance to stress-test everything that this provided :)
19:46:46 <sech1> https://github.com/monero-project/monero/pull/9234 is ready to be reviewed
19:51:28 <luigi1111w> wow we release fast
20:00:37 <moneromoooo> 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 ?
20:23:00 <m-relay> <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.
20:23:00 <m-relay> <e​dge7:matrix.org> Got it from:
20:23:01 <m-relay> <e​dge7:matrix.org> https://github.com/monero-project/monero/pull/9023#issuecomment-1773914631
20:24:07 <moneromoooo> ty
20:28:27 <m-relay> <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.
20:34:00 <moneromoooo> OK, I see your reasoning's intuition. Thanks.
22:19:22 <m-relay> <j​effro256:monero.social> edge7: thats a great summary
22:20:40 <m-relay> <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
22:21:28 <m-relay> <j​effro256:monero.social> The more we force the picks to take on unique values, the less it represents the original distribution
23:50:21 <selsta> luigi1111w: let's wait until tomorrow to see if we get more bug reports, otherwise we tag
23:50:38 <selsta> only one person so far has complained about the regression so appear there aren't too many affected