<g​allerystrengthsiren:nope.chat> non-kyc places to buy monero?

<m​etrics:unredacted.org> 🤍

<m​etrics:unredacted.org> Exchange

<m​etrics:unredacted.org> silent.exchange

<h​avenouser:monero.social> retoswap.com

<k​evino:tchncs.de> just read cuprate is ready for casual usage . means i can use it for personal use without encountering any errors ?

<3​21bob321:monero.social> Production use ?

<m​etrics:unredacted.org> youtube.com/watch?v=spLqyfHV8TQ

<s​yntheticbird:monero.social> no it's not

<s​yntheticbird:monero.social> It was bad wording ngl

<k​evino:tchncs.de> why

<s​yntheticbird:monero.social> it's very experimental, prone to bug (since alpha) and isn't ready for "casual" usage since RPC not available

<s​yntheticbird:monero.social> the only thing that has been assert so far is syncing performance, and the fact that it won't explode 3 sec after running it

<s​yntheticbird:monero.social> obviously a lot of bugs have been smashed since a while, but there are a lot down the way

<s​yntheticbird:monero.social> and i would say it's ready for "casual usage" when it reaches beta stage

<3​21bob321:monero.social> Alpha tag it

<s​yntheticbird:monero.social> Understand hinto's message as "cuprated is now meant to be run by casual users for testing purposes"

<3​21bob321:monero.social> V0.01 alpha

<s​yntheticbird:monero.social> which wasn't the case some times ago

<k​evino:tchncs.de> also i bet it can't use the existing blockchain downloaded from monerod ?

<s​yntheticbird:monero.social> yup

<k​evino:tchncs.de> yes i test

<k​evino:tchncs.de> but can it use my local monerod node to create its own blockchain db ?

<k​evino:tchncs.de> it might make things faster ?

<s​yntheticbird:monero.social> we don't have any `excluside-node` option at the moment

<s​yntheticbird:monero.social> so no unfortunatel

<k​evino:tchncs.de> ohhh k

<k​evino:tchncs.de> pruned blockchain is also 91gb in size right now , damnit :(

<s​yntheticbird:monero.social> i want pruned blockchain so bad

<k​evino:tchncs.de> cuprate does have pruned option right ?

<s​yntheticbird:monero.social> nope

<k​evino:tchncs.de> 🤔

<s​yntheticbird:monero.social> and our current database is 1.2x time larger than monerod

<s​yntheticbird:monero.social> currently 260GB on my computer

<k​evino:tchncs.de> i saw rottens X post he mentioned about some pruned node

<s​yntheticbird:monero.social> ?

<s​yntheticbird:monero.social> well no there are no prune support in cuprate

<s​yntheticbird:monero.social> all we support is fetching blockchain from pruned nodes

<k​evino:tchncs.de> i would love to run a full node but don't have that much space right now , sorry

<s​yntheticbird:monero.social> np it's understandable

<k​evino:tchncs.de> i would love to run a full node but i don't too much space right now , sorry

<q​8monero:matrix.org> same

<k​evino:tchncs.de> i should've bought 2gb ssd instead 1tb 🥲

<k​evino:tchncs.de> at one time i had blockchains for about 3-4 coins

<k​evino:tchncs.de> at one time i had blockchains downloaded for about 3-4 coins

<3​21bob321:monero.social> Not dedicated storage for it ?

<k​evino:tchncs.de> no , portable ones are better

<s​yntheticbird:monero.social> lol bro wants a usb stick

<k​evino:tchncs.de> i should've bought 2gb ssd instead of 1tb 🥲

<k​evino:tchncs.de> i would love to run a full node but i don't have too much space right now , sorry

<s​yntheticbird:monero.social> you wrote 2gb instead of 2tb

<k​evino:tchncs.de> i should've bought 2tb ssd instead of 1tb 🥲

<k​evino:tchncs.de> lol my bad , but you get it right xD

<k​evino:tchncs.de> i also have a 1Tb hdd but its of no use 🫠

ah bloody hell u gotta change the fork heights in the wallet too?

<k​evino:tchncs.de> maybe to keep backups but it won't sync

<k​evino:tchncs.de> maybe to keep backups but not sync chain from it.

<k​evino:tchncs.de> When was the last monero hard fork ?

<k​evino:tchncs.de> 2022 ?

<g​ingeropolous:monero.social> raggafragga

<g​ingeropolous:monero.social> and all the available "private testnets" make you sync the existing testnet. blargh

<g​ingeropolous:monero.social> private testnet tutorials etc

<g​ingeropolous:monero.social> i changed the heights. what else do you want!?>!?>!>!>

<g​ingeropolous:monero.social> well i guess im not winning this battle against entropy this morning

<o​frnxmr:xmr.mx> Chek wownero

<o​frnxmr:xmr.mx> They use rct from genesis, so probably made the chsnges that youre looking for

<k​evino:tchncs.de> Do the peer nodes check if a monero node applies consensus rules uniformly ?

<k​evino:tchncs.de> specifically asked because cuprate is a new node implementation, so it should go by the same rules

<k​evino:tchncs.de> does it have any effect on dandelion++ , or fingerprinting attached to a node

<o​frnxmr:xmr.mx> A lot of things arent consensus. A modified monerod peer node can even be configured to not follow d++

<b​oog900:monero.social> cuprated follows the dandelion++ paper closer than monerod does currently so it is slightly different. The node you run is also finger printable: cuprated or monerod

<k​evino:tchncs.de> but since a transaction cannot not be traced back to a node , so fingerprinting a node should not be a concern i guess

<b​oog900:monero.social> it depends, there probably wont be that many people running cuprated for a while so if someone knows you are running cuprated it might make it more easy for them to find your node and do a targeted attack.

<o​frnxmr:xmr.mx> A tx can be traced back to a node

<o​frnxmr:xmr.mx> (Thats why dandelion++ was implemented. To make it harder)

<k​evino:tchncs.de> in bitcoin yes :)

<o​frnxmr:xmr.mx> And monero

<o​frnxmr:xmr.mx> D++ makes it harder, but far from impossible

<k​evino:tchncs.de> i see ser

<o​frnxmr:xmr.mx> btc has stuff like `onlynet=onion` that (i think) works to alleviate concerns there

<k​evino:tchncs.de> i think you can configure monerod to send transactions over Tor too

<k​evino:tchncs.de> on btc though its a whole another issue with transparent blockchain , so hiding node don't do anything.

<e​longated:matrix.org> Wish it was by default, and better a monero network tor like network itself for p2p stuff 😅

<k​evino:tchncs.de> its not hard to setup

<k​evino:tchncs.de> many tutorials are i guess

<k​evino:tchncs.de> after initial sync you are supposed to change the config to only use tor

<e​longated:matrix.org> Someday somewhere someone will make it and do a pr

<k​evino:tchncs.de> there is another mode where it does all other gossip through clearnet , but only at the time of sending a transaction it uses Tor

<k​evino:tchncs.de> there is another mode where it does all other gossip through clearnet , but when sending a transaction it uses Tor

<o​frnxmr:xmr.mx> --tx-proxy=tor,127.0.0.1:9050

<o​frnxmr:xmr.mx> Hey boog900, my monerod sync is at 23hrs today 🥳

<b​oog900:monero.social> have you tried cuprate :)

<o​frnxmr:xmr.mx> I dont have 260gb, but i'll sync like 150gb of cuprate after

Ill cross the finish line some time next aeek

<o​frnxmr:xmr.mx> Monerod locked up on me yesterday with 400k blocks remaining. So resyncing to see if i can reproduce

<o​frnxmr:xmr.mx> (Testing the gitian build of 18.4.0)

<o​frnxmr:xmr.mx> its real sad. Does like 1.4 blocks/sec at the tip

<o​frnxmr:xmr.mx> I'll likely sync cuprate w/ and w/o checkpoints to compare

<b​oog900:monero.social> I can sync cuprated in ~16 hrs on my PC with out fast sync, fast sync is like 7 to 8 due to poor internet

<b​oog900:monero.social> I can sync cuprated in ~16 hrs on my PC without fast sync, fast sync is like 7 to 8 due to poor internet

<3​21bob321:monero.social> Without smoke ?

<3​21bob321:monero.social> What's the lowest low end device you have used to run cuprate on ?

<b​oog900:monero.social> full verification sync does make my PC pretty hot, it's like I am mining.

<b​oog900:monero.social> Raspberry Pi 4 2GB

<s​yntheticbird:monero.social> the plot is that boog900's pc is a raspberry pi 4 2gb

<o​frnxmr:xmr.mx> boog900 after restarting cuprated, the bss is very low (like 1-5). Known issue? It eventually starts to grow, but takes a few mins

<b​oog900:monero.social> protection against huge blocks, we always start low and build up.

<b​oog900:monero.social> it can actually be configed in the block downloader that just isn't exposed to end users.

<o​frnxmr:monero.social> For monerod, we used the median of the last 100 blocks as estimator

<b​oog900:monero.social> we do similar, the block downloader only takes into account downloaded blocks though

<o​frnxmr:monero.social> For downloaded blocks, we take the avg of the largest batch in queue to estimate a block size

<o​frnxmr:monero.social> So it compared median vs queued, and uses the higher of the two as the estimate

<o​frnxmr:monero.social> monero-project/monero #9494

<o​frnxmr:monero.social> The only "issue" i have, is in my testing, 5+mb batches syncs less blocks/sec than slower than 3mb :/

<o​frnxmr:monero.social> Otherwise i think its ready for production 🥲

<o​frnxmr:monero.social> (also the max a user can set is set is 50mb, but our current serialization limits only allow ~30. So setting to 50 will cause issues). I don't really see this as an issue. 50 was chosen to be half of the packet size limit (100mb) and the serialization limits should eventually be fixed to allow for 100mbs

<o​frnxmr:monero.social> Either with 7999 or 8867, or with something like 0xfffc serialization increase pr

<o​frnxmr:monero.social> i don't understand why 5+MB is so much slower than 3mb though. Were using 10MB as default.. idk if we should drop to 3 and modify it after fixing whatever issue is causing 5+MB to be slow. Ive only tested in 1 system, so that doesnt really help

<b​oog900:monero.social> that's for monerod?

<o​frnxmr:xmr.mx> Yeah

<o​frnxmr:xmr.mx> The seralization limit was due to a dom / oom attack where objects would deserialize to like 12gb, so we limited the counts severely, which limits the batch size to ~30mb

<o​frnxmr:xmr.mx> 7999 was a fix for it (not merged), 8867 is another fix that replaces the serialization. Both big prs

<b​oog900:monero.social> Yeah cuprate's epee parser doesn't use a DOM, it doesn't even copy bytes, it references into the raw bytes using the `bytes` crate.

<b​oog900:monero.social> so we don't have those limits, we still have the overall message limits though

<b​oog900:monero.social> I also see cuprate slowing down when the batch size limit is too high, although it happens higher than 5mb, more like around 30

<o​frnxmr:xmr.mx> Maybe depends on the system

<o​frnxmr:xmr.mx> Here (near chain tip) it goes from ~1.25-1.75 blocks/sec @3mb to ~0.7-1.0 @ 5+mb

<o​frnxmr:xmr.mx> Any immediate thoughts on the approaches taken in 7999 or 8867?

<o​frnxmr:xmr.mx> Iirc they both remove the DOM

<b​oog900:monero.social> ngl I haven't looked and they are quite big, I think 8867 is already in the process of being adopted

<b​oog900:monero.social> the write interface seems to be already merged

<o​frnxmr:xmr.mx> Yeah there are a few merged prs related to 8867

<o​frnxmr:xmr.mx> think we should prioritize it?

<b​oog900:monero.social> I think the tx propagation changes should be prioritized first

<b​oog900:monero.social> and then maybe even the tx-pool being re-validated on a HF as no HF can happen until that is fixed IMO

<o​frnxmr:xmr.mx> yeah, i can just spam 300mb into the pool at hf time and break monero 😆

<o​frnxmr:xmr.mx> Smh

<b​oog900:monero.social> yeah lol

<o​frnxmr:xmr.mx> i'm loling rn

<b​oog900:monero.social> good

<o​frnxmr:xmr.mx> those should be easy fixes tho, probably

<o​frnxmr:xmr.mx> The hf one**

<o​frnxmr:xmr.mx> The tx propagation needs some design work still, right?

<b​oog900:monero.social> hopefully, it being part of consensus is going to make people uneasy though

<b​oog900:monero.social> The main idea is there, I think there are some details that need to be decided but code work can start on it.

<o​frnxmr:xmr.mx> I think totally unreasonable, considering that we lucked out for prior hardforks

<o​frnxmr:xmr.mx> Like, would cost 500$ to break monero

<o​frnxmr:xmr.mx> And an idiot like me could have figured it out by fkn around on testnet

<o​frnxmr:xmr.mx> 100mb is like 2.6xmr in fees to fk up the chain for over an hour

<b​oog900:monero.social> yep Monero has had quite a bit of luck that some vulns were not found by bad actors.

<o​frnxmr:xmr.mx> i keep telling irs to stop being cheapasses

<o​frnxmr:xmr.mx> If they offered like 300b + immunity, maybe we'd call that hotline

<o​frnxmr:xmr.mx> 600k?? assholes.

<o​frnxmr:xmr.mx> Even rpc lol. Until relatively recently, you couldnt connect to a wallet to a nodes rpc port if the txpool was >100mb

<o​frnxmr:xmr.mx> Now you can, but only using restricted rpc (because the responses are split into 100tx)

<o​frnxmr:xmr.mx> those serialization limits are big trouble too tho 🥲

<o​frnxmr:xmr.mx> Part of why dynamic block sync size is necessary imo

<o​frnxmr:xmr.mx> Dynamic doesnt solve the issue, but it prevents it from effecting all new syncs

<o​frnxmr:xmr.mx> And then you have the runaway spans lol

<o​frnxmr:xmr.mx> Eating up your ram if you download too quickly

<o​frnxmr:xmr.mx> matrix.monero.social/_matrix/media/…oad/xmr.mx/AqtFLMvjEXjpghxPjNljdarZ

<o​frnxmr:xmr.mx> This was just a few hrs ago

<b​oog900:monero.social> monerod's syncing code is fucked, needs a refactor

<b​oog900:monero.social> very fragile code IMO

<o​frnxmr:xmr.mx> Even the 100BSS limit is fkd

<o​frnxmr:xmr.mx> Its supposed to be 2048

<o​frnxmr:xmr.mx> Idk how it got limited to 100, but it cant be fixed w/o a hard fork, because if your node requests >100, if the responding node isnt updated, it will refuse to send anything

<o​frnxmr:xmr.mx> But yeah.. its not just theoretically fragile, some of it is already cracking

<o​frnxmr:xmr.mx> like --block-download-max-size doesnt work at all

<b​oog900:monero.social> You could add a support flag for it, that's something I also think the new tx relay will do, so nodes know which nodes have the new protocol.

<o​frnxmr:xmr.mx> (i want to deprecate / replace it with dynamic spans)

<b​oog900:monero.social> you will always need a max limit

<o​frnxmr:xmr.mx> i guess so. Can only request >100 from nodes that signal that they arent broken :P

<o​frnxmr:xmr.mx> The dynamic spans pr currently targets in time (2min lookahead)

<o​frnxmr:xmr.mx> Like a video buffer

<o​frnxmr:xmr.mx> It checks sync speed, and only stops downloading once it reaches ~2mins ahead

<o​frnxmr:xmr.mx> This to give time to start downloading before you catch up (from slow peers), but also to prevent the screenshot above (downloading 2hrs in advance)

<b​oog900:monero.social> that makes sense although the limit is inherently a memory limit so to me it should just be a single constant of how much memory you want to use for the queue.

<o​frnxmr:xmr.mx> The default (broken) is suppsoed to be 10 batches.. which is way too low imo

<o​frnxmr:xmr.mx> If it wasnt broken, it would dl 10 batches (which can be synced in like 3 seconds). Causing a lot of time waiting for connections and downloads to resume

<b​oog900:monero.social> it's an `or`

<o​frnxmr:xmr.mx> we have a constant flag atm (broken) --block-download-max-size

<b​oog900:monero.social> so it proceeds if under 10 batches or less than the queue limit

<o​frnxmr:xmr.mx> Yeah, the or should be an and

<b​oog900:monero.social> why?

<o​frnxmr:xmr.mx> (and the rule is clearly broken anyway, as evidenced by my screenshot)

<o​frnxmr:xmr.mx> As its both above the size limit and above the batch limit

<o​frnxmr:xmr.mx> Hit 800 spans and 4gb

<b​oog900:monero.social> there is another exception for if you are syncing blocks below the height of your chain (alt blocks): github.com/monero-project/monero/bl…yptonote_protocol_handler.inl#L2003

<b​oog900:monero.social> it's fucked

<o​frnxmr:xmr.mx> Yeah we changed all that in the dynamic span pr

<o​frnxmr:xmr.mx> Seems to work to keep spans under control

<o​frnxmr:xmr.mx> The span pr still needs work

what all on master branch constitutes "hard fork"?

really wish no hf stuff was put on master

<o​frnxmr:xmr.mx> For dbss, you can specify a fixed bss using --block-sync-size=N or a dynamic (default) bss using --batch-max-weight=N

<b​oog900:monero.social> I feel like the `or` was there purposefully, to make sure you were always queuing blocks

<o​frnxmr:xmr.mx> For dynspans, ideally we could keep --block-download-max-size as well as the time based --span-limit

<b​oog900:monero.social> if it was a real limit I would have thought it would be higher

<o​frnxmr:xmr.mx> we changed it to 10minimum and 200 threshold

<o​frnxmr:xmr.mx> It was 10 threshold before

<o​frnxmr:xmr.mx> This line was changed to

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> bool queue_proceed = (nspans < m_span_limit) && (size < block_queue_size_threshold);

<o​frnxmr:xmr.mx> ```

<b​oog900:monero.social> because of the `or` it was 10 minimum

<o​frnxmr:xmr.mx> And

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> m_span_limit = m_span_limit ? m_span_limit : BLOCK_QUEUE_NSPANS_THRESHOLD;

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> m_span_limit = (m_bss && blocks_per_seconds) ? (( blocks_per_seconds * 60 * m_span_time ) / m_bss) : BLOCK_QUEUE_NSPANS_MINIMUM;

<o​frnxmr:xmr.mx> if (m_span_limit < BLOCK_QUEUE_NSPANS_MINIMUM)

<o​frnxmr:xmr.mx> m_span_limit = BLOCK_QUEUE_NSPANS_MINIMUM;

<o​frnxmr:xmr.mx> ```

<o​frnxmr:xmr.mx> In any case, we didnt get rid of the --block-download-max-size and should probably make it override the dynamic span if set (like block-sync-size overrides dymamic bss)

<o​frnxmr:xmr.mx> (Block-download-max-size is supposed to set the max queue size)

<o​frnxmr:xmr.mx> I think default time-based spans will work best though, because it will adapt to your hardware

<b​oog900:monero.social> this PR is only needed due to run away spans right?

<o​frnxmr:xmr.mx> runaway spans was the inspiration

<b​oog900:monero.social> IMHO this doesn't actually fix the issue

<b​oog900:monero.social> this line is the line that was changed although:

<o​frnxmr:xmr.mx> ofrn thought "why am i downloading 30hrs worth of blocks, and then if i shut down monerod i lose them. I dont need to be more than a couple minutes ahead at any given point in time"

<b​oog900:monero.social> github.com/monero-project/monero/bl…te_protocol_handler.inl#L2024-L2026 those lines also decide if we proceed or not

<b​oog900:monero.social> `queue_proceed` should have been `false` in this case, which means the error has to be elsewhere