00:00:36 <hyc> doesn't even make sense to my why any kerberos stuff is built into there but whatever
00:00:53 <wfaressuissia[m]> "https://salsa.debian.org/debian/krb5/-/merge_requests/5/" this unmerged PR will add static libs into the most recent version
00:01:11 <wfaressuissia[m]> "https://sources.debian.org/src/zeromq3/4.3.1-4+deb10u2/debian/rules/#L21" they added krb5  in this version of libzeromq
00:01:27 <wfaressuissia[m]> "https://sources.debian.org/src/zeromq3/4.2.1-4+deb9u2/debian/rules/#L21" previous version was without krb5
00:02:11 <wfaressuissia[m]> But it's waste of time to sync with each distro in order to build static binaries, easier to use depends
00:49:31 <hyc> yeah, I guess so
03:23:40 <jakroo09[m]> Hey guys its hard for me to keep up is the ring decoy issue going to be patched soon or is it still being duscussed which approach to take?
03:29:20 <c0mm4nd> Hello bros, does anyone know current monero daemon follows which RingCT version? 1.0, 2.0 or 3.0? Or the progress of this?
03:33:35 <jberman[m]> <jakroo09[m]> "Hey guys its hard for me to keep" <- Shooting to have an improved patch ready for re-review within the next day, possibly tonight. AFAIK once the patch is merged, assuming nothing else is holding up a release, the next release would ship 2 weeks later
03:35:19 <jakroo09[m]> jberman[m]: Oh ok thanks jberman I saw you on that monerotopia thing you seem like a really knowledgable dude......really appreciate what you are doing for the monero community
03:35:39 <jakroo09[m]> its guys like you and younger passionate guys that will keep XMR going into the future
03:38:03 <jberman[m]> Thank you :)
03:39:26 <jakroo09[m]> even though we have a general fund we dont have a massive dev fund like ETH....so the future of XMR purely relies on the hard work of the devs we have
03:39:33 <jakroo09[m]> but i feel the future is bright and we are in good hands
03:39:42 <selsta> "the next release would ship 2 weeks later" <-- might be even faster
03:39:49 <selsta> though depends on how available some people are
03:42:36 <jakroo09[m]> selsta: Hey Selsta!  Is there any chance do you think we see Triptych this year or is there still other ways the Monero project can go in terms of the massive ring upgrade?
03:43:26 <selsta> BP+ with a slight ring size bump is more more likely this year
03:43:48 <selsta> the problem with Triptych is the complexity of multisig
03:44:59 <luigi1111w> triptych ain't happening this year
03:45:20 <jakroo09[m]> ok yeah i figured as much i understand there is a lot that goes into it
03:45:40 <nikg83[m]> luigi1111w: Is it ever happening 🤔 if multisign is not feasible 
03:46:55 <selsta> multisig is possible but more complex
03:47:17 <nikg83[m]> selsta: Yah I mean a acceptable implementation 
03:47:18 <selsta> there are other schemes that are similar to triptych but with easier multisig, but they require everyone to generate a new address (different address scheme)
03:48:22 <jakroo09[m]> hmm wasnt there another implementation option called seraphis/lelantis?
03:48:24 <luigi1111w> it's also possible some "magical" new scheme will come out in the meantime; this area is in pretty active development
03:48:44 <jakroo09[m]> luigi1111w: that would be pretty sick
03:48:50 <selsta> jakroo09[m]: yes but they require a different address scheme
03:49:02 <jakroo09[m]> ah ok got it
03:50:48 <nikg83[m]> selsta: Should be fine, what happens with subadress? Has the migration been thought through yet 
03:50:56 <luigi1111w> no
03:52:44 <luigi1111w> jakroo09[m]> luigi1111w: that would be pretty sick <= agreed
04:45:06 <UkoeHB> luigi1111w: your comments motivated my subconscious to come up with a new idea that might work
04:45:44 <luigi1111w> eggcellent
04:49:27 <UkoeHB> Unfortunately I think it's impossible to come up with a scheme that has the same properties and efficiency as Seraphis, while also perfectly matching the current address format and permission structure. So, there will be non-trivial tradeoffs to consider (if everything pans out in the end).
05:05:48 <UkoeHB> and on further thought... my idea was mistaken; it's probably impossible
05:06:06 <UkoeHB> *impossible to match current address format and permission structure
05:13:03 <luigi1111w> that's the spirit
05:20:29 <UkoeHB> The problem is any new key image scheme on a fixed base point will let the view key holder know when outputs are spent. So, current view-only wallets would gain that power. Seraphis solves this by changing the address format so there are 3 private keys instead of 2.
05:55:40 <jberman[m]> Relevant: for most users today, a view key also lets you guess with a high degree of accuracy when an output has been spent. That’s how light wallets work to my knowledge; I don’t believe they use key images to determine spent outputs, the server guesses
05:56:53 <UkoeHB> hm looking at change outputs?
06:00:18 <jberman[m]> Yep
06:00:18 <jberman[m]> If you know all past outputs sent to an address, then see a new tx with an output sent to the address, you can check the rings of that tx for past outputs that were sent to the address. If all rings in the tx contain an output belonging to the address, you have a high degree of certainty those outputs were spent in that tx
06:06:29 <UkoeHB> guess I forgot you could do that lol
06:50:57 <jberman[m]> Are the Seraphis efficiency gains + same address format maintained if that property is dropped?
06:51:42 <UkoeHB> no to retain the address format there are efficiency losses
06:53:48 <jberman[m]> Got it
07:09:09 <luigi1111w> jberman[m] that's incorrect
07:09:31 <luigi1111w> that would require extra indexing and wouldn't be 100% anyway
07:09:46 <luigi1111w> for sure mymonero uses keyimages
07:10:59 <luigi1111w> never mind indexing
07:28:59 <jberman[m]> the light wallet API doesn't seem like it takes in key images as input anywhere: https://github.com/monero-project/meta/blob/master/api/lightwallet_rest.md#methods
07:28:59 <jberman[m]> it looks like the mymonero client uses the spend key to filter out key images that can't be correct: https://github.com/mymonero/mymonero-app-js/blob/a5db2ccc76daa21774736e57312b9e87f9b203bc/local_modules/HostedMoneroAPIClient/response_parser_utils.js#L56-L71
07:32:45 <UkoeHB> I think what's important is that current view keys already leak significant data about your spent outputs, so making that more reliable wouldn't necessarily affect users' threat models. You could argue that 'in theory' users could avoid this view-only data leak with a custom tx builder, but I don't know of any reason to think one exists.
07:34:49 <jberman[m]> Yes, that^ that's why I felt it was relevant
17:46:22 <ndorf> anyone know how exactly block_weight differs from just raw block_size?
17:47:11 <luigi1111w> exactly would be in the code, but it's to do with number of outputs mostly, since BP scales poorly in compute and strongly in space
17:47:41 <ndorf> gotcha, thanks.
17:48:02 <moneromooo> Weight is the notional size that a tx would have if its bulletproofs were to have 2 outputs at most.
17:48:16 <moneromooo> Or something like that. 
17:48:36 <ndorf> thanks for that as well
17:50:55 <UkoeHB> ndorf see ZtM2 section 7.3.2
17:51:08 <luigi1111w> of course ukoe wrote about it
17:53:36 <ndorf> nice. thanks again
18:07:50 <sech1> ndorf weight = size for all 2-output transactions. If transactions have more than 2 outputs, their weight is bigger than size. Exact details are in the code
18:13:49 <ndorf> just wanted to document the relevant fields in the daemon rpc guide, so this is already good enough, i think. feedback welcome of course https://github.com/erciccione/monero-site/pull/25/commits/56e81b1f810a5dc17870e16953d55ed042257eee
18:30:04 <UkoeHB> LGTM
20:34:37 <monerodev880022[> Hello. I am looking for some help. I am building the site xmrmemes.com and I had everything working fine on test net locally. Once I attempted to take the site live on mainnet, I have faced a bunch of issues.
20:34:37 <monerodev880022[> The payments occasionally would go through but sometimes it would take hours even though Monerod is fully synced. I seem to be having issues with the RPC returning nothing the large majority of the time. I have been trying to debug it and am getting [] (blank array) when checking the transfers.
20:34:48 <monerodev880022[> I really don't know what to do.
20:35:12 <monerodev880022[> monerod says I am fully synced
20:35:12 <monerodev880022[> rpc command says 2021-08-10 20:31:51.896	W Loaded wallet keys file, with public address: 47iHdE1TQ3c84EKE7PDF7Qb6hnncpW4ysS6zU3SoR8Pwcw2zRmNGD4wUz9sMhWL37Jg8rxZPYvSW4KLGg3hU4y9bDhLH6ZL
20:35:32 <monerodev880022[> but when I interact with the RPC file using one of the Monero integrations libraries, i get nothing returned. But it all works on test net.
20:36:37 <monerodev880022[> Digitalocean backend shows the server is using only 60% memory an 15% cpu the past hour
20:36:52 <monerodev880022[> Any ideas how I can debug? Not sure where else to ask. I have been trying to fix this for days.
20:37:32 <moneromooo> #monero's the best place to ask I think. But it's possibly a RPC timeout due to a lot more traffic on mainnet.
20:38:43 <monerodev880022[> Okay I will ask there, thank you. Do you know if there is anyway to prevent an RPC timeout?
20:42:38 <moneromooo> Set a massive timeout.
20:43:03 <moneromooo> Might not be a great idea either. Find what RPC is taking time (hopefully just one).
20:43:12 <moneromooo> Assuming it's that in the first place.
20:43:44 <moneromooo> IIRC getting rct output data is heavy on the daemon the first time, but it's cached so only the first tx will take a while to create.
20:44:37 <moneromooo> If a tx is created but takes hours to go through, it might be you have random network connection issues. Relay is "blind" and txes get re-relayed every... 4 hours IIRC.
20:45:14 <moneromooo> You can also run monero-wallet-rpc with --log-level 2, you should see any errors in the log.
20:46:07 <moneromooo> Timeouts won't say "timeout" per se, it'll say... "recv fail" or the like.
20:46:49 <moneromooo> Log level 1 on monerod should also help in case the daemon itself is going wonky, you never know.
20:47:50 <monerodev880022[> moneromooo: Thank you very much
20:50:18 <monerodev880022[> Well now I realize it is something else. Because the verification of XMR addresses works flawlessly and fast on registration. I just used the wallet with the monero-wallet-cli tool and the "show_transfers" command actually returns nothing so the RPC I think is actually working. It almost seems as the wallet was corrupted or something? Have you ever seen something like this? There was definitely transactions before but now it shows
20:50:19 <monerodev880022[> none. The Monero library also won't overwrite a wallet with the same name so I don't think I overwrote it.
20:51:27 <monerodev880022[> I will try to create a new wallet and see if things work. but honestly very bizarre the wallet data would go blank like this
20:52:52 <monerodev880022[> And excuse my ignorance, I don't see anyone talking in the main Monero group on Matrix. Maybe I clicked the wrong one. I am new to matrix. Anyway to link the group here?