00:21:13 is the congestion fixed? 06:34:34 jokeman: looks like there is still an inflow of transactions, but blocksize has increased a bit and is now managing the 140K tx/day without congestion 06:35:44 The new norm? 07:06:06 We are supposed to get new wallet updates right this weekend-maybe? 07:06:07 After that the auto fee should auto fee 07:06:07 And even if we lose most of the rings decoys, we still have RingCT and Stealth Addresses, so still better then bitcorn 07:22:09 "lost most of the rings decoys"? 07:26:25 if*, by that I mean recent TX will use some of these spam TX as decoy. 07:26:26 Without knowing where the attack come from, we can't know if they keep logs of there spend... or no... 07:32:20 ok yeah, After some time this shouldn't be a problem I think but it would be good to know mathematically how long to wait after a decoy spam attack to be least likely to include tainted decoys 07:37:19 Articmine seems to think it may not be spam and that since binance shutdown, etc that we may be seeing more on-chain traffic vs cex ledger updates 07:39:58 Hi, 07:39:58 Xmr noob here, I setup my own node 2-3 days ago, it was syncing fine but once it went above 95%, it suddenly got slow af, is it normal? Now its at 99% and says 7 hours left 07:40:13 He said to keep an eye on DEXes and p2p services like LocalMonero to see if liquidity improves and street price reduces some through more competition 07:41:01 EdSnow yes 07:41:05 Depends on hardware and internet bandwidth 07:41:37 Mine took days to sync too because i was using an old machine 07:41:46 I'm using a sata ssd, proxmox and i've 100m symmetrical fiber 07:42:09 If this gets any slower i doubt i'll ever catch up 07:42:33 Youll catch up 07:42:35 I've seen some people say that their node was syncing for a month, but never caught up 07:43:01 Im fully caughr up with 30mbps/10mbps 07:43:26 Those people probably used an hdd connected to a sbc like a raspberry pi 07:43:29 Ahh..must be my hardware then 07:43:38 Im fully caught up with 30mbps/10mbps 07:44:13 As long as you're using an ssd, you'll catch up eventually 07:44:15 I'm on an old HP box running proxmox 07:44:22 Just give it time 07:44:37 The chain is 180GB 07:45:18 Note that sync speed is mainly dictated by the number of transactions you're processing, than the number of blocks 07:45:20 Yup, but its a sata ssd, connected using a usb 3.0 dongle thingy 07:45:32 I'm using pruned 07:45:37 And towards the end, the chain has a lot more transactions per block 07:46:14 Oh..so thats why it went fast at first but now has slowed down 07:46:18 Sata ssd is plenty fine. The usb dongle... MAY be a bottleneck 😅 07:46:44 You might open your console with monerod running and issue "status" command and look for peers out. Example 16(out)+16(in) 07:46:51 the estimate is not accurate either, as its cant see into the future ^ e.g. it has no idea that there is a huge influx of transactions on the way on the 4th march 07:47:04 That too ^ 07:47:51 Hardware-wise, the main bottleneck is disk random read IOPS -> hence the preference for ssds over hdds 07:48:14 *strong preference 07:48:38 But idk how usb dongles affect ssd performance 07:49:14 It depend of the usb dongle 07:50:01 I'll get a pcie adapter if this doesn't work, i'm not sure about random r/w of that dongle 07:50:21 I ran out of sata ports so i went with a dongle 07:51:55 Once your node is caught up, it will be able to keep up even on an hdd (connected to a sata port) - it's just the initial sync that is more brutal, since you have nearly a decade (!) of history to download and verify, block by block, tx by tx 07:52:10 Speaking of - when's Monero's 10th birthday? 07:52:31 And what about a 10th birthday special hardfork gift 🤣 07:52:56 In april right? 07:52:57 Fine for me, tell me one day before and I can do it on all node 07:54:43 Block #1 is timestamped 2014/04/18 10:49:53 08:02:57 ThTs UTC im guessing 08:03:24 Yup. 09:49:39 has fixedfloat dropped xmr for good ? it's been unavailable for awhile.. and most other coins are back (they seem to have performed some kind of big update to the platform) 12:36:34 woof5326: update to v0.18.3.2 once it is released today, it will speed up your sync 14:29:11 client? node? both? 14:32:03 node sync due to new checkpoints 14:32:20 v0.18.3.1 has almost half a year without checkpoints 17:18:05 As far as I know, FixedFloat was hacked and re-did a lot. Prior to the hack, many times both XMR or BTC would be unavailable. So I wouldn't take it as a sign of anything for awhile 17:19:33 Latest Monerotopia show was all about recent surge in transaction count. Tuxsudo talked about CakeWallet's nodes having long response times for RPC. Arctic Mine suggested monerod code could be improved to do better parallel processing, to take advantage of GPU or multi threaded CPU. 17:20:28 Is someone working on the parallel processing already? Is there a fundraiser I can support for this? 17:35:06 Of course we can't ourselves, but we should try again with everybody running the latest version of the software. It has, among other things, an optimization to better deal with large mempools, and of course a working fee-choosing function. The result of a re-run would be interesting. 18:09:24 I can't talk for monerod, but there is a decent work on parallelization from Cuprate side. Hopefully it'll lead to decent results. With enough chance some of our architectural choice might be possible to port to monerod. 18:10:28 I can't talk for monerod, but there is a decent work on parallelization from Cuprate side. Hopefully it'll lead to decent results. With enough chance some of our optmizations might be possible to port to monerod. 18:13:23 But I don't want to give false hope of course. It's mainly due to Rust making it easy to parallelize work compared to C++ 18:15:52 However I am curious about the GPU use ? I don't see any workload in monerod that could benefit from it 18:21:14 the next hardfork will be a huge boost in efficiency for public remote nodes.. everyone using the latest version.. a utopia 18:22:19 what will exactly drive this efficiency ? Are we talking about Seraphis ? 18:22:49 HF in april? 18:23:10 v0.18.3.1 had improvements in regards to txpool efficiency between wallet and remote nodes 18:23:34 but since a lot of people were using older wallet versions they increased the load for everyone else 18:23:47 :( 18:24:01 forgive me if im missing names, but rbrunner and jberman played a big role in some efficiency gains for remote nodes^ 18:24:05 yes 18:24:58 unrelated but blockchain growth has been sensible these 6 last months 18:25:08 so just by virtue of forcing everyone to use the latest versions of cli/gui, not seraphis related 18:25:22 alright 18:25:54 previously it would send the complete txpool to every wallet every 20? seconds (don't know the exact number) 18:26:03 lmao 18:26:06 after the update it would only send the difference from the last request 18:26:14 reducing bandwidth significantly 18:26:22 delta update, that's great 18:42:48 HF in april? <> we should, it's been too long :D 18:43:08 Happy 10th anniversary 19:01:18 HF in april? <> we should, it's been too long :D <--- And yet a lot of people think Monero is still hardforking every 6 months ... 19:08:58 s​elsta: "after the update it would only send the difference from the last request" Is there a way to get this with a JSON RPC request, or is it only binary output sent from nodes to wallet software? Thanks. I am doing the old way with my mempool archiver. 19:13:56 you'd have to ask rbrunner or jberman 19:14:09 they implemented it and will know best 19:16:25 Thanks. rbrunner7 : Does your incremental mempool efficiency update work with a regular JSON RPC request, or only node <-> wallet in binary data format? 19:16:39 <1​23bob123:matrix.org> 20 days left till multi sig is required 19:53:23 Rucknium: Check the PR, it has some info: https://github.com/monero-project/monero/pull/8076 19:59:41 This is the daemon RPC call in question: https://github.com/monero-project/monero/blob/1bec71279e43bfde46506409377630c7e020a1cf/src/rpc/core_rpc_server_commands_defs.h#L162 20:00:22 "pool_info_since" suspiciously named param 20:01:04 ? 20:01:47 i mean i definitely know its not been added to the rpc docs, will make an issue 20:03:52 SyntheticBird45 i trusted your script would not lead us astray 20:08:22 Binaries for Monero v0.18.3.2 are now available at www.getmonero.org 21:10:31 Awesome! 21:39:11 failed.png 21:40:20 to be honest half of my openrpc core document is based on the website doc. I start looking at each methods for wallet rpc. I should have been more careful, I didn't even knew about get_blocks_fast 21:50:46 that's enough, from tomorrow I'll recheck all the core openrpc method from monerod src 21:52:41 If I were using `curl`, how would I form the request for `get_blocks_fast`? 21:53:27 Try #monero:monero.social . This channel is for community stuff. 21:56:42 `curl http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_blocks_fast","params":{ requested_info: 2, block_ids: [],start_height: 0, prune:true, no_miner_tx:true, pool_info_since:0 }}' -H 'Content-Type: application/json'` 21:56:47 Ig somethings like that 22:00:12 By the way, I don't mean to be toxic or harsh or anything, but please can you agree on a way to keep documentation updated for ffs. Once the OpenRPC is finished and merged in the repo, please just think about updating it whenever you change something 22:05:12 Thanks. I am getting `parse error` with that exact command. I will have to fill in some of the parameters I think. 22:06:09 oh 22:06:15 I forgot the " 22:06:49 `curl http://127.0.0.1:18081/json_rpc -d '{"jsonrpc":"2.0","id":"0","method":"get_blocks_fast","params":{"requested_info":2,"block_ids": [],"start_height": 0,"prune":true,"no_miner_tx":true,"pool_info_since":0}}' -H 'Content-Type: application/json'` 22:06:57 should be better like that 22:09:06 I get "Method not found". I am running 0.18.3.1-release of monerod 22:09:42 hold on i need to clone repo 22:12:24 bad news. its not a /json_rpc methods but the one defined at `http://127.0.0.1:18081/getblocks.bin` 22:13:01 and its an epee binary request so you can't do that with `curl`. Sry rucknium 22:13:26 just look at the PR for more info strikes again 22:13:29 That is what I was afraid of 😢 22:17:13 oh wait. But if get_block_fast isn't a json_rpc method. That means I didn't failed my core rpc doc! THAT MEANS I DONT NEED TO VERIFY IT TOMORROW