<j​okeman203:hackliberty.org> is the congestion fixed?

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

<r​ottenwheel:kernal.eu> The new norm?

<g​fdshygti53:monero.social> We are supposed to get new wallet updates right this weekend-maybe?

<g​fdshygti53:monero.social> After that the auto fee should auto fee

<g​fdshygti53:monero.social> And even if we lose most of the rings decoys, we still have RingCT and Stealth Addresses, so still better then bitcorn

"lost most of the rings decoys"?

<g​fdshygti53:monero.social> if*, by that I mean recent TX will use some of these spam TX as decoy.

<g​fdshygti53:monero.social> Without knowing where the attack come from, we can't know if they keep logs of there spend... or no...

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

<s​hortwavesurfer2009:monero.social> 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

<w​oof5326:tchncs.de> Hi,

<w​oof5326:tchncs.de> 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

<s​hortwavesurfer2009:monero.social> 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

<p​lowsof:matrix.org> EdSnow yes

<s​hortwavesurfer2009:monero.social> Depends on hardware and internet bandwidth

<s​hortwavesurfer2009:monero.social> Mine took days to sync too because i was using an old machine

<w​oof5326:tchncs.de> I'm using a sata ssd, proxmox and i've 100m symmetrical fiber

<w​oof5326:tchncs.de> If this gets any slower i doubt i'll ever catch up

<s​hortwavesurfer2009:monero.social> Youll catch up

<w​oof5326:tchncs.de> I've seen some people say that their node was syncing for a month, but never caught up

<s​hortwavesurfer2009:monero.social> Im fully caughr up with 30mbps/10mbps

<e​ndor00:matrix.org> Those people probably used an hdd connected to a sbc like a raspberry pi

<w​oof5326:tchncs.de> Ahh..must be my hardware then

<s​hortwavesurfer2009:monero.social> Im fully caught up with 30mbps/10mbps

<e​ndor00:matrix.org> As long as you're using an ssd, you'll catch up eventually

<w​oof5326:tchncs.de> I'm on an old HP box running proxmox

<s​hortwavesurfer2009:monero.social> Just give it time

<s​hortwavesurfer2009:monero.social> The chain is 180GB

<e​ndor00:matrix.org> Note that sync speed is mainly dictated by the number of transactions you're processing, than the number of blocks

<w​oof5326:tchncs.de> Yup, but its a sata ssd, connected using a usb 3.0 dongle thingy

<w​oof5326:tchncs.de> I'm using pruned

<e​ndor00:matrix.org> And towards the end, the chain has a lot more transactions per block

<w​oof5326:tchncs.de> Oh..so thats why it went fast at first but now has slowed down

<e​ndor00:matrix.org> Sata ssd is plenty fine. The usb dongle... MAY be a bottleneck 😅

<s​hortwavesurfer2009:monero.social> You might open your console with monerod running and issue "status" command and look for peers out. Example 16(out)+16(in)

<p​lowsof:matrix.org> 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

<e​ndor00:matrix.org> That too ^

<e​ndor00:matrix.org> Hardware-wise, the main bottleneck is disk random read IOPS -> hence the preference for ssds over hdds

<e​ndor00:matrix.org> *strong preference

<e​ndor00:matrix.org> But idk how usb dongles affect ssd performance

<g​fdshygti53:monero.social> It depend of the usb dongle

<w​oof5326:tchncs.de> I'll get a pcie adapter if this doesn't work, i'm not sure about random r/w of that dongle

<w​oof5326:tchncs.de> I ran out of sata ports so i went with a dongle

<e​ndor00:matrix.org> 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

<e​ndor00:matrix.org> Speaking of - when's Monero's 10th birthday?

<e​ndor00:matrix.org> And what about a 10th birthday special hardfork gift 🤣

<w​oof5326:tchncs.de> In april right?

<g​fdshygti53:monero.social> Fine for me, tell me one day before and I can do it on all node

<e​ndor00:matrix.org> Block #1 is timestamped 2014/04/18 10:49:53

<s​hortwavesurfer2009:monero.social> ThTs UTC im guessing

<r​brunner7:monero.social> Yup.

<a​leenor:matrix.org> 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)

woof5326: update to v0.18.3.2 once it is released today, it will speed up your sync

client? node? both?

node sync due to new checkpoints

v0.18.3.1 has almost half a year without checkpoints

<s​implifiedprivacy:hackliberty.org> 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

<f​iatdemise:matrix.org> 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.

<f​iatdemise:matrix.org> Is someone working on the parallel processing already? Is there a fundraiser I can support for this?

<r​brunner7:monero.social> 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.

<s​yntheticbird:monero.social> 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.

<s​yntheticbird:monero.social> 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.

<s​yntheticbird:monero.social> 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++

<s​yntheticbird:monero.social> However I am curious about the GPU use ? I don't see any workload in monerod that could benefit from it

<p​lowsof:matrix.org> the next hardfork will be a huge boost in efficiency for public remote nodes.. everyone using the latest version.. a utopia

<s​yntheticbird:monero.social> what will exactly drive this efficiency ? Are we talking about Seraphis ?

<g​fdshygti53:monero.social> HF in april?

v0.18.3.1 had improvements in regards to txpool efficiency between wallet and remote nodes

but since a lot of people were using older wallet versions they increased the load for everyone else

<s​yntheticbird:monero.social> :(

<p​lowsof:matrix.org> forgive me if im missing names, but rbrunner and jberman played a big role in some efficiency gains for remote nodes^

yes

<s​yntheticbird:monero.social> unrelated but blockchain growth has been sensible these 6 last months

<p​lowsof:matrix.org> so just by virtue of forcing everyone to use the latest versions of cli/gui, not seraphis related

<s​yntheticbird:monero.social> alright

previously it would send the complete txpool to every wallet every 20? seconds (don't know the exact number)

<s​yntheticbird:monero.social> lmao

after the update it would only send the difference from the last request

reducing bandwidth significantly

<s​yntheticbird:monero.social> delta update, that's great

<gfdshygti53:monero.social> HF in april? <> we should, it's been too long :D

Happy 10th anniversary

<gfdshygti53:monero.social> 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 ...

<r​ucknium:monero.social> 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.

you'd have to ask rbrunner or jberman

they implemented it and will know best

<r​ucknium:monero.social> Thanks. rbrunner7 : Does your incremental mempool efficiency update work with a regular JSON RPC request, or only node <-> wallet in binary data format?

<1​23bob123:matrix.org> 20 days left till multi sig is required

<r​brunner7:monero.social> Rucknium: Check the PR, it has some info: monero-project/monero #8076

<r​brunner7:monero.social> This is the daemon RPC call in question: github.com/monero-project/monero/bl…ore_rpc_server_commands_defs.h#L162

<p​lowsof:matrix.org> "pool_info_since" suspiciously named param

<r​brunner7:monero.social> ?

<p​lowsof:matrix.org> i mean i definitely know its not been added to the rpc docs, will make an issue

<p​lowsof:matrix.org> SyntheticBird45 i trusted your script would not lead us astray

Binaries for Monero v0.18.3.2 are now available at www.getmonero.org

<s​implifiedprivacy:hackliberty.org> Awesome!

<s​yntheticbird:monero.social> failed.png

<s​yntheticbird:monero.social> 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

<s​yntheticbird:monero.social> that's enough, from tomorrow I'll recheck all the core openrpc method from monerod src

<r​ucknium:monero.social> If I were using `curl`, how would I form the request for `get_blocks_fast`?

<e​laryan:hackliberty.org> Try #monero:monero.social . This channel is for community stuff.

<s​yntheticbird:monero.social> `curl 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'`

<s​yntheticbird:monero.social> Ig somethings like that

<s​yntheticbird:monero.social> 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

<r​ucknium:monero.social> Thanks. I am getting `parse error` with that exact command. I will have to fill in some of the parameters I think.

<s​yntheticbird:monero.social> oh

<s​yntheticbird:monero.social> I forgot the "

<s​yntheticbird:monero.social> `curl 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'`

<s​yntheticbird:monero.social> should be better like that

<r​ucknium:monero.social> I get "Method not found". I am running 0.18.3.1-release of monerod

<s​yntheticbird:monero.social> hold on i need to clone repo

<s​yntheticbird:monero.social> bad news. its not a /json_rpc methods but the one defined at `127.0.0.1:18081/getblocks.bin`

<s​yntheticbird:monero.social> and its an epee binary request so you can't do that with `curl`. Sry rucknium

<p​lowsof:matrix.org> just look at the PR for more info strikes again

<r​ucknium:monero.social> That is what I was afraid of 😢

<s​yntheticbird:monero.social> 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