<s​yntheticbird:monero.social> Lmao new channel unlocked

<w​oodser:monero.social> it would be nice if get_height can return the last known processed height immediately, instead of waiting for the next chunk to be processed. on tor and such, the progress can be very slow, and there's no way to know if it's making any progress for many minutes

<k​ayabanerve:matrix.org> Dedicated cell for RPC get height which subscribes to notifications of new blocks to update itself 🤤

new blocks get sent via zmq every time

<w​oodser:monero.social> but monero-wallet-rpc does not support zmq to notify of syncing updates afaik

<o​frnxmr:xmr.mx> Fwiw, monerod doesnt respond while syncing either

<o​frnxmr:xmr.mx> Monerod's download process doesnt block, but the sync does. i dont remember if wallet-rpc's download process blocks, but it probably does

<m​onero.arbo:matrix.org> I have vague concerns about it somehow causing a net split that leads to more disruption than the current re-orgs

<m​onero.arbo:matrix.org> I also wonder if we have enough confirmed support from mining pools to know that enough of them will follow the checkpointed chain that the alt chain doesn't stay ahead

<m​onero.arbo:matrix.org> also not sure if this is really better than the detective mining suggestion. it seems to me detective mining holds truer to the 'longest chain' rule, it's just that you have to snoop to figure out what the heaviest chain IS since it's being withheld. Checkpoints on the other hand, are seemingly trying to force a 'first seen' rule on top of the heaviest chain rule, in the hopes tha<clipped message>

<m​onero.arbo:matrix.org> t the earlier chain will catch up

<o​frnxmr:xmr.mx> aiui, detective mining is essentially defeated by them adding their (wn txs to blocks

<o​frnxmr:xmr.mx> Dns checkpoints wont be enabled/updated until mining pools are confirmed on board and actively enforcing

<m​onero.arbo:matrix.org> I thought the issue was more that you're kinda forced to mine empty blocks when doing detective mining to not risk mining invalid transactions but 🤷‍♀️

<w​oodser:monero.social> is there any way to make monero-wallet-rpc automatically save while the wallet is auto refreshing in the background? the `store` call blocks on long syncs, so all progress is lost if the wallet is force shut down?

<o​frnxmr:xmr.mx> You can send `store` during the refresh

<o​frnxmr:xmr.mx> It doesn't / shouldnt block. It should be executed between refreshes, and theres nothing to save if the refresh cycle hasnt been completed

<w​oodser:monero.social> on slow tor connections, that refresh cycle (of 256 bocks I think), can block for many minutes

<w​oodser:monero.social> so if I'm not mistaken, no progress would be saved during that time or if they force shut down (due to seeming unresponsiveness)

<w​oodser:monero.social> would be nice if the wallet could automatically save itself every minute or so as part of the background refresh, so progress isn't lost no matter how slow

<o​frnxmr:xmr.mx> During which there is nothing to save

<o​frnxmr:xmr.mx> If sent a store, close_wallet, stop_wallet, or sigterm, the wallet will save / save and close / save and stop during once that refresh cycle finishes

<o​frnxmr:xmr.mx> the wallet doesnt save periodically (i dont think cli does either). It saves on open_wallet, close_wallet, stop_wallet, store, and probably a few other calls. If you send any command during the refresh, it will execute as soon as the refresh cycle completes

Hi, I am a big fan of Monero project and recently set up independent node. I want to contribute to the core code now, a little bit unsure of where to start exactly. I have a lot of experience in corporate world as software developer mostly in JAVA, but totally fine in C/C++ too just been awhile since I worked with them. Also good at Python. I have

a significant amount of time I want to dedicate to this. Anyone able to help point me at some good issues/features/optimizations to get started on?

<s​yntheticbird:monero.social> hi dabbonda, the core code is located in the github.com/monero-project/monero repository. One of oldest and still valuable advice when people ask about contributing is to find some issues with either your own usage or within the codebase and try to fix it.

<j​effro256:monero.social> 1) If you have feature requests or experience bugs while using Monero, try to challenge yourself to implement / fix them. 2) Try browsing open Github issues github.com/monero-project/monero/issues and seeing if you can write tests to reproduce the issues (doing so will get you familiar with the functional behavior of the codebase), and then see if you can fix them

Thank you SyntheticBird and @jeffro256  I have certainly looked through some of the more recent github open issues. This one looks a little interesting to me: monero-project/monero #9965 I might try to see if I can recreate and improve that. When I set up my independent node on an older laptop it took several days to sync

which seems excessive to me. Perhaps I can find some inefficiencies in the setup/install process. This is about the only issue I have personally faced so far. Then maybe later I can look towards other ways of optimizing other core code. Hopefully that sounds reasonable, thanks again for the tips.