04:34:26 <stillramone> Is there a faucet for stagenet? The links on the monerodocs.org site don't work.
04:37:43 <stillramone> even the block explorers don't work for me. does this have something to do with xmr.to banned in america?
04:38:27 <stillramone> I will have to use a vpn for this?
04:40:13 <selsta> stillramone: https://melo.tools/faucet/stagenet/
04:40:51 <stillramone> Thank you.
05:09:55 <stillramone> I've noticed in the GUI wallet that tx_keys are blank for all tx's when clicked on but spend proofs are available for all tx's. In the CLI wallet tx_key's are only available for recent tx's. Would anyone care to elaborate on this? Are tx_key's going to be legacy at some point and we are moving to only spend proofs?
05:13:26 <stillramone> The reason I ask is because someone was having trouble with the Secret Monero bridge and he used the GUI which didn't give him a tx_key.
05:13:51 <stillramone> Which is required to complete the tx.
05:14:22 <stillramone> The getmonero GUI.
05:16:40 <selsta> stillramone: the original wallet cache should have a tx_key
05:45:12 <stillramone> how do you access the cache?
05:47:29 <stillramone> For example when I pull up my transactions in the CLI I can only access the tx key for only the tx's done in the last few days. Anything past that time gives an error. When looking at the same transaction in the GUI I am unable to view any tx keys.
05:48:40 <stillramone> Is there some time limit to the tx keys? This is what I want to understand.
05:51:42 <selsta> stillramone: do you open the same wallet file with both cli and gui?
05:52:13 <stillramone> No the GUI is using a remote node.
05:52:33 <stillramone> I restore from seed.
05:52:53 <stillramone> the same seed
05:54:45 <selsta> yes, if you restore from seed the tx_key isn't visible
05:54:54 <selsta> you have to use the original wallet cache where you made the transactions
05:58:16 <stillramone> Ok that makes sense then because I restored my CLI wallet from seed not too long ago.
05:58:29 <stillramone> So it's only able to give the key for those new tx's.
05:59:58 <stillramone> Where does the spend proof come in? Can this be used as a substitute for a tx key?
06:09:37 <selsta> 07:58 <stillramone> So it's only able to give the key for those new tx's <-- correct
06:09:57 <selsta> you can make backups of the wallet cache, it's the file that is called `wallet_name`
06:10:07 <selsta> `wallet_name.keys` is the keys file
06:12:09 <selsta> stillramone: spend proofs https://monero.stackexchange.com/questions/8122/what-is-the-spendproofv1-or-outproofv1-in-the-details-of-a-sent-transa
06:20:37 <stillramone> You are correct that the tx keys get transferred with the wallet file. Nice. Thanks.
11:29:37 <mj-xmr[m]> <endogenic> ""I looked at wallet2_api and..." <- Well you're the expert on this one, but I see no movement in any direction for now.
11:32:33 <mj-xmr[m]> And my point is, that we pay for this during every compilation (that's not cached).
11:48:09 <mj-xmr[m]> I'll move further comments to the PR.
17:24:22 <ErCiccione> cool: https://github.dev/monero-project/monero
17:31:26 <UkoeHB> huh never seen a webapp with such good performance
17:32:56 <ErCiccione> TIL you can self host Code
17:33:52 * moneromooo gonna self eat dinner soon
17:36:22 <sarang> waaaaat
17:37:16 <wfaressuissia> "https://vortex.data.microsoft.com/collect/v1" are you kidding ? it's web version of vscode with built-in telemetry, it's completely opposite to cool.
17:40:49 <ErCiccione> Well, i wouldn't use it, but integrating an IDE on github is definitely cool and will be convenient for many.
17:42:46 <moneromooo> That's the "Extend" phase.
17:50:28 <wfaressuissia> even kids understand that github isn't free and m$ is bad, there is no future is this
17:51:51 <moneromooo> There are still loads of MS apologists around. I've even seen a number of people claiming their days of being flaming assholes are over and they're freedom loving now.
17:52:55 <sarang> Telemetry aside, I find VS Code to be a really nice IDE
17:53:11 <l33t_bit[m]> sarang: Use vscodium then
17:53:18 <sarang> orly
17:53:18 <l33t_bit[m]> It's a fork with the telemetry removed.
17:53:21 <sarang> Oh nice
17:54:11 <sarang> Is it kept up to date with upstream?
17:54:38 <wfaressuissia> I've tried all IDEs and none of them is as flexible as vim/tmux for monero/monero-gui development
17:55:07 <sarang> I used to use Vim exclusively, but I found Code with Vim bindings to be an improvement
17:56:27 <wfaressuissia> sarang, could you answer few questions in monero-research-lounge about number of multisig rounds ?
17:56:51 <sarang> "many rounds"
17:57:19 <wfaressuissia> any upper bound ?
17:57:33 <wfaressuissia> 10/100 ?
18:01:38 <wfaressuissia> sorry for stupid questions
18:17:24 <hyc> PSA: if you're doing development on Ubuntu, probably should not upgrade to 21
18:17:57 <hyc> they ship glibc 2.33 which breaks gdb, gdb attach is broken
18:18:51 <hyc> ful info here https://bugs.archlinux.org/task/69657
18:19:11 <hyc> or just avoid any distro on unpatched glibc 2.33
18:21:24 <wfaressuissia> now I see why I don't experience this problem on arch anymore, they've patched glibc
18:21:53 <hyc> if you want to rebuild glibc yourself, you need this fix https://sourceware.org/git/?p=glibc.git;a=commit;h=ea299b62e83cc38b0d910bbd1a879f7d1f836e96
18:22:13 <hyc> I'm still in the middle of rebuilding it
18:53:25 <mj-xmr[m]> <moneromooo> "There are still loads of MS..." <- Haha, I'm not an apologist for sure and have never been, but I keep writing code, that's compatible with Win32. I use the M$ crowd as the best customers you can get, since they are lazy.
18:53:51 <mj-xmr[m]> Anybody else is able to just write their own shit from scratch :)
20:15:54 <Rucknium[m]> Status report: I brainstormed and have a really rough draft for what an overhauled mixin selection algorithm may look like and I shared it with jberman. This is distinct from the small fix that jberman is working on. It doesn't incorporate binning as of yet; I'm not sure whether it can incorporate binning, but I think it might.
20:16:59 <luigi1112> binning sounds great
20:18:55 <Rucknium[m]> I don't fully understand binning yet. To be able to know whether my mixin selection 3.0 could incorporate it, I will have to study it more.
20:19:43 <luigi1112> (I don't either)
20:23:54 <UkoeHB> If your selection algorithm can do CDF and inverse CDF, then it should be compatible with binning.
20:25:03 <Rucknium[m]> Ok great. Yes, it should be able to do that. It would produce a CDF nonparametrically.
20:25:41 <Rucknium[m]> Like via kernel density estimation or another nonparametric estimator of a  pdf/cdf
20:27:12 <Rucknium[m]> Note: with my current draft, a full implementation would require blockchain consensus changes.
20:27:39 <UkoeHB> What kind of changes?
20:31:03 <Rucknium[m]> I mean, it is literally something that I brainstormed in the last few hours, so it is very tentative.
20:31:03 <Rucknium[m]> 1) Place into each block data describing the "correct" nonparametric estimate of the PDF of real spends.
20:31:03 <Rucknium[m]> 2) Enforce proper selection of mixin distribution by wallets via a hypothesis test. If the submitted mixins are too far from the correct pdf, then a tx would be rejected.
20:31:03 <Rucknium[m]> It's pretty speculative and early-version now.
20:33:04 <Rucknium[m]> I think I can share a draft since it doesn't go into any detail really about formulating attacks on the current selection algorithm. But it sort of assumes knowledge of parts of conversations that jberman and I have had.
20:35:18 <UkoeHB> Sure :) although I can't promise I will understand it :p
20:36:25 <Rucknium[m]> What would be the best way to securely share a text file?
20:37:20 <wfaressuissia> e2e encrypted matrix pm/room
20:38:05 <UkoeHB> I will msg u
21:17:03 <mj-xmr[m]> <Rucknium[m]> "What would be the best way to se" <- gpg -c file.txt
21:17:04 <mj-xmr[m]> and phone the password?
21:18:40 <hyc> all my PMs are encrypted with OTR. you're not using that already?
21:21:12 * plowsof[m]  < https://libera.ems.host/_matrix/media/r0/download/libera.chat/84baf297a56c012069c2dc5805299d4be2e60dda/message.txt >
21:24:41 <binaryFate> plowsof[m]: nice :)
21:31:20 * nikg83[m]  < https://libera.ems.host/_matrix/media/r0/download/libera.chat/feccfade99e2b6bd6352be56fa7d245e86c77ae7/message.txt >
21:34:42 <plowsof[m]> I dont know anything about the security (its on my local network.. so its a hot wallet) It's downloading the files over ssh (passwordless) using rsync. (its a very simple/convenient solution imo) 
21:34:42 <nikg83[m]> Also the remote machine would be a hot wallet ?
21:35:47 <nikg83[m]> * Also the remote machine would be a hot wallet ?  Nvm you already answered it
21:36:09 <plowsof[m]> Yes (a full node setup using Seth's guide with firewall rules etc with also an rpc wallet running on it)
21:37:36 <nikg83[m]> plowsof[m]: So I will need the hot wallet to be synced first manually? Or it can be automated too 
21:39:51 <plowsof[m]> Automated as in it lives on the node machine being saved every 10 mins
21:41:48 <plowsof[m]> (the idea is you already have a hot wallet running on a mobile device)
21:49:53 <nikg83[m]> <plowsof[m]> "(the idea is you already have a..." <- Tx_key will go missing if one spends from mobile on next rsync ? 
21:50:32 <nikg83[m]> Or we can sync that changes to rpc node aswell
21:53:34 <plowsof[m]> Im assuming that would be the cache file? if yes then that would make the script 3 lines instead of 2 and it can sync the local cache to the remote one (i deserve no praise for this btw.. its just an idea for the devs to consider xxx) 
21:54:34 <plowsof[m]> oh nothing will go missing on the next sync, the magic is all handled by 'rsync' 
21:58:17 <nikg83[m]> plowsof[m]: That will be good then 👍