01:12:19 <riceandbeans> has anyone ever used https://github.com/fireice-uk/xmr-stak for monero?
01:12:50 <riceandbeans> I got it to build on my system but it's not showing up on minexmr on my dashboard at all when running
01:12:59 <riceandbeans> trying to port xmrig to my main os too
01:35:30 <nioc> riceandbeans don't bother with stak
01:51:57 <riceandbeans> nioc: Why do you say that?
01:52:16 <riceandbeans> nioc: I'm hitting a few snags in porting xmrig
01:54:06 <riceandbeans> nioc: So far with stak all I see is all my shares being rejected :\
01:54:13 <nioc> riceandbeans: stak is made by someone that wants monero to fail
01:54:17 <nioc> and AIUI has not been maintained recently although I don't really know if that is true
01:54:36 <riceandbeans> Well that sucks
01:54:37 <nioc> it just copies code from xmrig
01:54:50 <riceandbeans> It did have some awfully similar looking functions
01:55:07 <riceandbeans> As someone that has spent a few hours today getting them to build on DragonFly BSD
01:55:16 <nioc> I just download and run the binaries of xmrig cause imma ignorant
01:55:39 <nioc> since imma ignorant I use windows
01:55:41 <riceandbeans> Yeah well that doesn't work when instead of being a ignorant you're a stupid and a weirdo running DragonFly BSD
01:55:46 <riceandbeans> :)
01:55:54 <riceandbeans> So, I'm trying to get it to work
01:56:29 <riceandbeans> CMakeFiles/xmrig.dir/src/backend/common/Workers.cpp.o:Workers.cpp:function xmrig::Workers<xmrig::CpuLaunchData>::start(std::vector<xmrig::CpuLaunchData, std::allocator<xmrig::CpuLaunchData> > const&): error: undefined reference to 'pthread_create'
01:56:33 <riceandbeans> CMakeFiles/xmrig.dir/src/crypto/rx/RxDataset.cpp.o:RxDataset.cpp:function xmrig::RxDataset::init(xmrig::Buffer const&, unsigned int, int): error: undefined reference to 'pthread_create'
01:56:37 <riceandbeans> CMakeFiles/xmrig.dir/src/crypto/rx/RxDataset.cpp.o:RxDataset.cpp:function void std::vector<std::thread, std::allocator<std::thread> >::_M_realloc_insert<void (&)(randomx_dataset*, randomx_cache*, unsigned long, unsigned long, int), randomx_dataset*&, randomx_cache*, unsigned int const&, unsigned int, int&>(__gnu_cxx::__normal_iterator<std::thread*, std::vector<std::thread, std::allocator<std::thread>
01:56:43 <riceandbeans> > >, void (&)(randomx_dataset*, randomx_cache*, unsigned long, unsigned long, int), randomx_dataset*&, randomx_cache*&&, unsigned int const&, unsigned int&&, int&): error: undefined reference to 'pthread_create'
01:56:47 <riceandbeans> CMakeFiles/xmrig.dir/src/crypto/rx/RxQueue.cpp.o:RxQueue.cpp:function xmrig::RxQueue::RxQueue(xmrig::IRxListener*): error: undefined reference to 'pthread_create'
01:56:50 <riceandbeans> collect2: error: ld returned 1 exit status
01:56:52 <riceandbeans> I think I'm going to mess with it later when I have more patience to get past this current breakage
01:57:13 <riceandbeans> Also trying to get powhasher built and working too
01:57:49 <nioc> you can try in #monero-pools but few people are around at this hour and when they are there is much shitposting and trolling along with some help
01:59:30 <riceandbeans> So pretty much the #linux IRC channels I cut my teeth on 20 years ago.
01:59:39 <riceandbeans> Oh, this looks promising
01:59:41 <riceandbeans> https://github.com/Ragnaroek/mithril.git
02:00:03 <riceandbeans> I'm a sucker for Rust
02:00:20 <riceandbeans> Except when it makes gratuitous use of libc, and then I make sad faces
02:01:07 <riceandbeans> Also when they don't document that you have to use nighly rust because they depend on nightly features......like this project does....
02:01:14 <riceandbeans> Also, which isn't available on DragonFly...
02:01:51 <riceandbeans> I take it back, they do mention nightly :( I'm just stupid
02:58:26 <bigslim[m]> How did I not know Monero was forking in a few days
03:02:14 <gingeropolous> bigslim[m], what monero news sources do u follow?
06:46:23 <riceandbeans> what monero news sources SHOULD we follow?
06:48:08 <dixie__flatline[> riceandbeans: definitely get the RSS feed of getmonero.org to your reader.
06:48:31 <dixie__flatline[> https://www.getmonero.org/feed.xml
06:49:08 <dixie__flatline[> Other than that, check out the subreddit every once in a while. And take a look at the IRC/Matrix chat.
06:52:38 <riceandbeans> dixie__flatline[: So where is the news that it's forking in a few days?
06:54:08 <dixie__flatline[> riceandbeans: on the homepage of getmonero.org, there is an orange banner up above.
06:54:47 <dixie__flatline[> Also, the most recent 3rd blog post on the RSS feed link I posted mentions the October 17th network upgrade.
07:07:40 <Inge-> riceandbeans: revuo newsletter is a great tl;dr source of info
07:50:19 <riceandbeans> so network upgrade is code for fork
07:52:08 <sech1> is it even a fork if new chain is not created and dies out after a few blocks? I don't think so
07:52:15 <sech1> just a network upgrade
08:01:13 <Inge-> riceandbeans: well yes - Monero has had many years of typically two non-contentious hard forks every year. That seems to be slowing down a bit now - licking wounds after the ASIC-resistance forking that got a bit out of hand until RandomX came along.
08:01:40 <Inge-> riceandbeans: But as long as the forks are non-contentious, they are pretty much network upgrades - bringing privacy improvements and other enhancements to Monero.
08:46:44 <kayront> I, for one, welcome our new orion overlord
09:03:28 <dixie__flatline[> As long as the upgrades improve privacy of monero, they do not carry the negative connotation of "hard fork" as in btc.
09:06:10 <horsepatat> what's going on with monero price? it's on fire lol, some big event behind it? ( I dont follow monero much )
09:07:41 <dixie__flatline[> King is claiming his rightful spot.
09:08:59 <horsepatat> about time
09:09:17 <horsepatat> I always knew this coin is least of all full of shit
09:09:46 <dixie__flatline[> The only coin with an actual usage.
09:12:50 <horsepatat> I updated monerod to that new release of oxygen something, yet my wallet opening is still far from speedy
09:13:25 <horsepatat> maybe I am running my local daemon wrong or something
09:13:39 <horsepatat> I use monero-wallet-cli and monerod
09:14:00 <horsepatat> so I opent wallet and it started refresh and it gonna take some 5 mins or more, is that typical?
09:14:33 <sech1> I depends on how many blocks you need to sync
09:14:41 <horsepatat> okay
09:14:54 <sech1> For me it's no more than a minute after 2 weeks of not opening it
09:15:01 <sech1> and that's with older v0.16
09:15:04 <horsepatat> aha
09:15:15 <horsepatat> may I ask if that blockchain of yours lives on SSD?
09:15:58 <sech1> No, my node runs on HDD, but is has 64 GB RAM, so I guess it's all cached there
09:16:02 <horsepatat> maybe I need to prune it
09:16:47 <horsepatat> yea that makes hell of a cache for disk reads
09:18:46 <horsepatat> I could use monero-blockchain-prune tool to create a pruned copy and then tell monerod to use that?
09:20:00 <Inge-> that takes it down to about 25GB
09:20:58 <horsepatat> which could be speedier? not sure how LMDB works
09:24:53 <horsepatat> off it goes pruning...
09:47:45 <selsta> not faster, just takes less space
09:50:55 <horsepatat> then I guess my disks just doesnt have great random access speeds
09:51:14 <horsepatat> they are lazy NAS grade drives, I just figured having bunch of them will make it suck less
10:10:26 <Inge-> ssd helps a lot
10:10:44 <Inge-> HDD's basically work like a vinyl player. Random access isn't their thing.
10:13:08 <horsepatat> ok, I will prune and try on SSD to compare
10:13:15 <horsepatat> pruning will take all night it seems
10:29:58 <selsta> you might want to resync on ssd with --prune-blockchain flag
10:30:12 <selsta> should not take longer than 6-7 hours
10:30:34 <selsta> or just wait for your pruning to finish
10:33:02 <horsepatat> that makes sense, too late now I guess
10:33:18 <horsepatat> faster to resync pruned than prune full chain
11:17:55 <bigslim[m]> gingeropolous: are you referring to news source as general news or monero? I found out about the monero fork reading cakewallet release notes last night for an update
11:21:50 <Inge-> bigslim[m]: it has been like the top post in reddit/r/monero for weeks and weeks
11:21:54 <Inge-> top / pinned
11:22:16 <bigslim[m]> Yea haven’t been on there in a while
11:22:45 <bigslim[m]> And not front page so Reddit’s algos killing it
11:23:17 <bigslim[m]> Even not coming up on Twitter
11:24:07 <bigslim[m]> I am not on the monero mailing list though, or wownero. Totally forgot about that fork. Busy weekend
11:52:42 <horsepatat> what does locked mean in show_transfers output? on 3rd column
11:56:21 <selsta> bigslim[m]: how would you suggest to announce the hardfork?
11:57:03 <selsta> almost every second tweet contains the info, there is a huge banner on the website, mailing list, reddit, etc
11:57:10 <selsta> are we missing something?
11:57:20 <asy> a marching band
11:57:27 <asy> skywriting
11:58:34 <Inge-> Ad during superbowl
12:00:19 <charolastra> a formation of drones writing it in RGB pixels into the sky
12:02:10 <horsepatat> banner on monero.org website?
12:02:43 <selsta> getmonero.org
12:14:13 <dixie__flatline[> via an emergency SMS direct alert system
12:28:55 <bigslim[m]> selsta: I think you guys do great. Honestly I thought I had monero on git followed for releases. Apparently I wasn’t there either.
12:29:29 <selsta> https://github.com/monero-project/monero/releases/tag/v0.17.0.0
12:29:40 <bigslim[m]> Yup
12:29:41 <selsta> it is written there but it does not stand out that much
12:29:55 <bigslim[m]> I’ll get stuff updated tonight now that I have a little free time
12:31:14 <bigslim[m]> Going to see how monero syncs on fiber now
12:32:16 <Inge-> I'm guessing, if you have a reasonable ssd, that the limitation will be CPU clock
12:32:51 <selsta> Inge-: how long did it take you again to sync?
12:33:40 <Inge-> <5 hours on high end hw/ssd/300mbps internet connection
12:34:15 <selsta> you know what’s weird, it took me less than 6 hours on a $10 VPS with rather low end hardware (but with SSD)
12:34:21 <selsta> so I wonder what the bottleneck is
12:34:51 <Inge-> yeah I don't think there was a huge diff between an i7-8650u and a threadripper 3970x
12:35:01 <hyc> definitely puzzling. I've done pretty fast syncs over a LAN
12:35:09 <Inge-> hyc: define pretty fast?
12:35:13 <hyc> but I see a lot of time where network is idle
12:35:25 <selsta> yea resources are barely used during sync
12:35:27 <hyc> and also time where CPU is idle
12:35:44 <Inge-> disk access?
12:35:53 <hyc> sometimes, but not every time
12:36:20 <selsta> talking about checkpoint fast sync, resources get used a lot after checkpoints
12:36:34 <Inge-> I'd make a wild guess that paralellization is somewhat limited ( I guess you could do all tx in a block in parallel - but need to complete one block before verifying the next) - and you need the random access to all inputs ...
12:47:41 <horsepatat> for long can a transfer of coins be stuck? mine is 3 hours already I think
12:48:34 <selsta> horsepatat: simple mode GUI?
12:49:14 <horsepatat> monero-wallet-cli
12:49:44 <moneromooo> transfers are locked for 10 blocks. Should be... 20 minutes on average. Unless the sender set a lock time, in which case it's whatever the sender set (min 20 blocks).
12:50:08 <horsepatat> I didnt set no lock time
12:50:13 <moneromooo> Try: show_transfer TXID in the wallet
12:50:25 <moneromooo> It should tell you if it's locked, and for how much time.
12:50:38 <horsepatat> that timestamp nearby word locked?
12:51:08 <moneromooo> Seemed better not to put it elsewhere, yes.
12:51:40 <horsepatat> it says pending, out and today's date, seeminly when I sent it
12:51:52 <moneromooo> Pending means it's not mined yet.
12:52:29 <moneromooo> So it might be it's only in your txpool, but the network did not learn about it yet. Fixed in git.
12:52:35 <horsepatat> the receivers wallet says pool, in locked and same date
12:52:39 <moneromooo> You can do, in monerod: relay_tx TXID
12:52:51 <moneromooo> Both using hte same daemon ?
12:52:54 <horsepatat> yea
12:53:01 <horsepatat> literally
12:53:03 <moneromooo> Is hte tx visible in an explorer ?
12:54:47 <moneromooo> If not, it's likely what I just said, and you need to relay the tx as it failed to propagate to the network.
12:55:18 <horsepatat> doesnt seem so
12:55:27 <horsepatat> that would make sense then
12:56:10 <moneromooo> selsta: are you including 6875 in that coming release ?
12:56:22 <selsta> yes
12:56:27 <moneromooo> THanks :)
12:56:29 <horsepatat> wait, that command is for monerod, not wallet
12:56:30 <selsta> once vtnerd approved it
12:56:47 <moneromooo> relay_tx is monerod, show_transfer for the wallet.
12:58:27 <horsepatat> I run it non interactive
12:58:36 <horsepatat> so I will restart it interactive to do just that
13:00:07 <Inge-> can't all those commands be sent via RPC as well?
13:02:00 <horsepatat> issued that command
13:03:25 <horsepatat> seems it froze
13:15:41 <bigslim[m]> selsta: 5hrs from a full sync, not fast sync or pruning?
13:16:04 <bigslim[m]> Last time I did with same hardware on cable it took me 6 days to full sync
13:16:13 <moneromooo> "monerod relay_tx TXID" will work.,
13:16:25 <bigslim[m]> 1950x with 32gb ram
13:16:31 <moneromooo> HDD ?
13:16:37 <bigslim[m]> M.2
13:16:48 <bigslim[m]> Sabrent rocket
13:16:56 <moneromooo> Is that a HDD ? :)
13:17:14 <selsta> did you add `--fast-block-sync=0` ?
13:17:17 <bigslim[m]> But apparently was getting 25Mbps or less average
13:17:18 <moneromooo> I mean the spinning type, as opposed to flash.
13:17:31 <bigslim[m]> No just straight ./monerod
13:17:34 <bigslim[m]> From 0
13:17:57 <bigslim[m]> The only hdd I have are for media server
13:18:10 <selsta> 6 days sounds extremely long for SSD, when was that?
13:18:20 <selsta> it should take you ~6 hours to sync up now
13:18:30 <selsta> maybe even less with your hardware
13:18:33 <bigslim[m]> Iirc 14.0
13:18:43 <moneromooo> OK. Then run top, and see what's taking time, if anything. user, kernel, I/O (wa). Third line in top's output IIRC.
13:19:02 <bigslim[m]> I have noticed standard sync with like 30k blocks takes maybe 20-30min now as opposed to 3hours
13:19:31 <bigslim[m]> Windows :)
13:19:31 <Quotes> fuck windows, use linux!
13:19:36 <bigslim[m]> Lol
13:19:52 <moneromooo> It's got a task manager somewhere that shows similar info.
13:20:01 <bigslim[m]> It’s my do all server. Vms, dev, Plex, other
13:20:28 <bigslim[m]> Monerod always sucks up resources but never more than maybe 12gb ram and 30-40% cpu
13:21:11 <bigslim[m]> I’ll try here when I get a chance to update it and start. I’ll let you know. Need to update wownero too. Bummer I missed the fork
13:49:56 <takel> cmake is not possible to work with ndk!
13:50:13 <takel> we must turn to build.sh
13:51:23 <selsta> takel: when was the last time build.sh worked for you?
13:54:15 <takel> i did git for 2019 november but still didnt work so is before
13:54:26 <takel> more than 1 year before
13:54:59 <takel> the bad is that lot of good things that were added wont play now
14:40:27 <Inge-> oh wow. the Sarang vacation CCS is 5 xmr away from being fully funded in 4 days.
14:47:51 <nioc> last chance to contribute guys!!!!!
14:48:16 <nioc> and CLSAG goes live in 4 days \o/
14:48:34 <nioc> https://ccs.getmonero.org/proposals/sarang-vacations.html
15:26:41 <sethsimmons> Get your moneroj on there and let’s try to make this the highest contributor count CCS yet 😉
15:28:43 <charolastra> a 26k$ vacation? that's alot of cocain and hookers
15:29:05 <dixie__flatline[> well deserved
15:57:00 <riceandbeans> Am I the only peron here that doesn't twitter, facebook, or reddit? I'll make sure I have the getmonero rss feed though, hopefully that's enough. Just, every time I hear fork I think of crap like BTC -> LTC or BTC -> BTC Cash
16:00:11 <ErCiccione> riceandbeans: the getmonero feed will be enough. There is also the mailing list for important updates. I think we cover more or less everything, don't know what else we could add
16:00:40 <riceandbeans> Eh, I mean, sometimes I miss things here, it's life
16:33:30 * jonathancross sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/RECjzPLnJMoOHHjLzqJLmfEy/message.txt >
16:42:06 <thrmo> jonathancross, I think there is some bug with dandelion which might be causing that
16:43:47 <selsta> jonathancross: Can you be more specific with sync speed? Daemon sync from block 0?
16:44:05 <jonathancross> <thrmo "jonf3n, I think there is some bu"> Hmmm... interesting.  I'd assumed Dandelion++ was only used for transaction broadcast between peers.  Could it affect block download as well?
16:44:30 <jonathancross> <selsta "jonf3n: Can you be more specific"> No, I just needed to sync the most recent few thousand blocks.
16:44:45 <selsta> You have to consider the large increase in daily transactions.
16:46:07 <jonathancross> <selsta "You have to consider the large i"> Yes. But the bandwidth just was not being used.
16:46:27 <selsta> yes, because bottleneck is verification not network speed
16:46:53 <jonathancross> CPU / Ram / disk also not being used.
16:46:54 <selsta> Was this on HDD or SSD?
16:48:35 <moneromooo> It none is used, it's possibly waiting on data from a peer. If that peer's busy, it might wait a bit before sending. Can't really tell with just "it is slow".
16:48:38 <jonathancross> It is a HDD.  But only `100 - 300 KB/s` being used.  I tested the disk speed during the sync and still got `17.1 MB/s` -- so there was extra disk bandwidth that was not being used.
16:49:06 <moneromooo> It's seek time that matters, not contiguous r/w speed.
16:49:14 <selsta> yes, HDD will always be extremely slow during verification.
16:50:22 <thrmo> speaking on that is there a meaningful difference between a sata ssd and a nvme one?
16:51:07 <jonathancross> <moneromooo "It's seek time that matters, not"> Ah, I'd assumed seek time was important when constructing a TX, but not so important when getting blocks from the network.
16:51:45 <jonathancross> I'll test that next time if issue shows up again.
16:54:05 <Inge-> jonathancross: disk queue length is indicative (while transfers/sec will be very low for random reads on a HDD) and if any single cpu core is pinned at 100% (overall CPU utilization could be very low as there is a limit to how parallelizable the workload is))
16:56:17 <jonathancross> <thrmo "speaking on that is there a mean"> Seek time for nvme is generally 10x faster than SATA III SSD. So...
16:56:57 <jonathancross> <Inge- "jonf3n: disk queue length is ind"> Good point.
17:21:30 <jonathancross> Is there something in Dandelion++ that could also slow down block download from peers?
17:21:43 <moneromooo> Not that I can think of.
17:26:01 <jonathancross> moneromooo: Thanks. I thought so.
17:27:13 <jonathancross> moneromooo: And per Inge-'s suggestion, that multiple cores might not be utilized for verification.  Does that sound reasonable to you?
17:31:37 <moneromooo> Inge- said just one line AFAICT. I don't know much about disk queue so can't say. It doens't sound bonkers at least :)
17:33:08 <hyc> hm, currently the blockchainDB is protected by a single criticalSection
17:33:17 <hyc> so perhaps that limits concurrency in tx verification
17:33:41 <moneromooo> Not really. The lock is taken for a chunk of 20 blocks.
17:34:19 <moneromooo> But the parallel part is low level, it's not "verify 20 blockjs in 20 threads", it's "run this same low level routine N times".
17:34:28 <hyc> hmmm
17:35:01 <hyc> hard to guess whether "verify 20 blocks in 20 threads" would be better
17:35:52 <hyc> I suspect it could be though
17:36:32 <hyc> far less overhead in running N copies of a serial job than trying to parallelize all the components of a single job
17:39:26 <hyc> of course in the latter approach, if you have more than 20 cores you need to increase the syncblock size
17:39:38 <moneromooo> It cannot always be though. If block 19 requires block 9, say.
17:40:23 <moneromooo> Anyway, it's a hell of a lot faster than it used to, but people always forget I guess.
17:40:31 <moneromooo> At some point I just think... not again...
17:40:38 <hyc> one can never have enough speed
17:40:50 <hyc> especially since the blockchain only ever grows
17:41:27 <moneromooo> The thing I'd like is a rw lock in the Blockchain class now.
17:41:38 <moneromooo> Without rewriting random things like the previous patch did.
17:42:05 <moneromooo> Wallet syncnug at the same time as blockchain syncing -> very slow.
17:42:30 <hyc> yeah, the whole locking stratey is garbage
17:42:39 <moneromooo> s/garbage/safe/ :)
17:43:04 <hyc> well, LMDB is N-readers+1-writer and perfectly safe
17:43:10 <hyc> better than rwlocks
17:43:19 <jonathancross> <hyc "so perhaps that limits concurren"> My system is old (4 core Xeon), but wouldn't others have complained loudly if verification only used a single core?
17:43:34 <moneromooo> Sure, not really my point though. You have something super complicated and safe too.
17:43:51 <moneromooo> Oh, they did, you can be certain about it.
17:43:59 <moneromooo> It used to.
17:44:27 <moneromooo> I mean you have something 100% memory safe in hand coded asm too. It's just much harder.
17:45:05 <moneromooo> Well, for, I dunno, a std::multimap usage, say.
17:45:13 * moneromooo stops rambling
17:45:36 <hyc> jonathancross: you probably would never have noticed. I have 8 cores and pretty much never see more than 4 cores used
17:45:49 <hyc> there's definitely something artificially limiting throughput
17:46:01 <hyc> I just don't know how to pinpoint what it is
17:46:29 <takel> cpu firmware
17:47:46 <jonathancross> <takel "cpu firmware"> Could test if that is a bottleneck using a ramdisk.
17:49:56 <takel> the issue is firmware closed source
17:50:11 <takel> this is the real issue
17:50:22 <takel> they can do whatever and u dont know
17:51:53 <Inge-> To be fair I didn't mean to indicate it was single core, just that the number of cores that can be utilized are limited. I would expect parallel verification of transactions is possible, while parallel validation of blocks is more difficult (although maybe possible to verify with assumptions, and do a second pass to check block hashes are correct once they have all been calculated
17:57:31 * jonathancross sent a long message:  < https://matrix.org/_matrix/media/r0/download/matrix.org/FoQNrZrGqSenMNKLIUMSuooO/message.txt >
18:37:02 <dixie__flatline[> Hey, I want to setup a monero full node at home.
18:37:58 <dixie__flatline[> However, first I want to really make sure that my home network router settings are watertight and can stand against a rogue pentester (i.e., hacker) in my neighborhood.
18:38:20 <dixie__flatline[> Anybody here have some nice internet tutorials on that?
18:39:25 <Copenhagen_Bram> Will activating "Enable displaying balance in other currencies" send my balance to a website, or just request the current price of Monero and convert the values locally?
18:39:36 <bigslim[m]> moneromooo: 2.19mil blocks left to sync. Let’s see how this goes
18:39:48 <bigslim[m]> 6.5yrs behind lol
18:40:05 <Copenhagen_Bram> Also I heard that Monero is doing a hard fork, I'm on version 0.17.0.1, do I need to do anything?
18:41:01 <moneromooo> No, though updating to 0.17.0.whatevercomessoon is probably a good idea. Either way, you should be fine for the fork.
19:46:59 <Copenhagen_Bram> oh wow
20:55:01 <bigslim[m]> Wow three hours in and 50% blockchain synced, 52%
20:55:13 <bigslim[m]> Only a million blocks left
20:55:32 <bigslim[m]> This is where it gets rough with ring CT
21:15:54 <Inge-> bigslim[m]: yeah first 60-75% are a breeze ...
21:16:45 <Inge-> Copenhagen_Bram: I believe it only looks up exchange rate, not sending any other info
22:39:05 <Copenhagen_Bram> <Inge-> Copenhagen_Bram: I believe it only looks up exchange rate, not sending any other info
22:39:07 <Copenhagen_Bram> And if I have the proxy set to 127.0.0.1:9050, it looks up the exchange rate over Tor, right?
22:56:55 <selsta> Copenhagen_Bram: yes
23:20:15 <Copenhagen_Bram> cool
23:20:41 <Copenhagen_Bram> How come I keep getting "Maximum number of clients reached" for every keystroke I make in the Monero window?
23:21:42 <selsta> Never seen that message.
23:21:47 <selsta> Where does it print that?