-
m-relay
<boog900:monero.social> the minimum was passed and the size limit was passed.
-
m-relay
<ofrnxmr:xmr.mx> In practice, the pr (idk which part) seems to have mostly fixed it. theres added logging to show when proceed is triggered
-
m-relay
<ofrnxmr:xmr.mx> I dont think ive been able to get spans above a couple hundred mb or 200 spans using the pr. I'll pass msg to 0x though
-
m-relay
<boog900:monero.social> that would just be adding another bandaide something that seems to have happened a lot with this section of code
-
m-relay
<boog900:monero.social> that would just be adding another bandaide and that seems to have happened a lot with this section of code
-
m-relay
<ofrnxmr:xmr.mx> So whats the real fix? 😁
-
m-relay
<ofrnxmr:xmr.mx> The logging added checks the stripes and conditions etc
-
m-relay
<boog900:monero.social> I did speak with 0x at the time and honestly I don't know. It has the be in those lines I linked, I did document what those lines did at the time:
-
m-relay
<boog900:monero.social> ```cpp
-
m-relay
<boog900:monero.social> bool stripe_proceed_main =
-
m-relay
<boog900:monero.social> (
-
m-relay
<boog900:monero.social> (m_sync_pruned_blocks && local_stripe && add_stripe != local_stripe) // True if we should sync pruned blocks, we are pruned and the peer has the next blocks pruned.
-
m-relay
<boog900:monero.social> || add_stripe == 0 // True if the next block is within the tip-blocks which won't be pruned.
-
m-relay
<boog900:monero.social> || peer_stripe == 0 // True if the peer does no pruning.
-
m-relay
<boog900:monero.social> || add_stripe == peer_stripe // True if the peer is pruned and has the next block un-pruned.
-
m-relay
<boog900:monero.social> )
-
m-relay
<boog900:monero.social> &&
-
m-relay
<boog900:monero.social> (
-
m-relay
<boog900:monero.social> as you can see if you are syncing an alt chain it'll just keep downloading past the limit
-
m-relay
<ofrnxmr:xmr.mx> yeah but i'm not syncing an alt chain in the 4gb screenshot
-
m-relay
<ofrnxmr:xmr.mx> Thats main chain shenanigans
-
m-relay
<boog900:monero.social> also this function seems incorrect, which is used to get `next_needed_height`:
github.com/monero-project/monero/bl…_protocol/block_queue.cpp#L151-L168
-
m-relay
<boog900:monero.social> If you follow it in ideal circumstances (all spans following each other) starting after our chain, then it will return the height of the next block we don't know about. If any spans don't line up it'll return a height way below that.
-
m-relay
<boog900:monero.social> oh and if the first span is empty it returns our chain height
-
m-relay
<ofrnxmr:xmr.mx> Making me hungry
-
m-relay
-
NorrinRadd
isn't that the cringe site w/ the bad advice?
-
m-relay
<fareve:matrix.org> @m-relay:monero.socialuse can just a cex exchange to buy usdt from it only and then use an non kyc swap site to swap that usdt you got from coinbase for xmr
-
m-relay
<kevino:tchncs.de> i don't think it has really bad advice
-
m-relay
<kevino:tchncs.de> Justin is also a user on their forum
-
NorrinRadd
seems like i recall them recommending vpns for privacy & security....
-
m-relay
<fareve:matrix.org> @m-relay:monero.socialvpns don't make you anonymous
-
m-relay
<fareve:matrix.org> @m-relay:monero.sociali had to do research on YouTube so I know I have proton VPN free version
-
m-relay
<syntheticbird:monero.social> Noooooooooooo NORDVPN WILL DIE FOR ME!!!!!!!
-
m-relay
<jivan:opaline.uk> @fareve:matrix.org the user @m-relay
-
m-relay
<jivan:opaline.uk> @fareve:matrix.org The user @m-relay:monero.social is an IRC bridge bot. The actual user's name is in the \<angle brackets\>
-
m-relay
<jivan:opaline.uk> @fareve:matrix.org The user @m-relay:monero.social is an IRC bridge bot. The actual user's name is in the <angle brackets>