<h​ardenedsteel:monero.social> are these answers still up to date? monero.stackexchange.com/questions/…art-of-the-daemon-rpc-is-restricted

<h​ardenedsteel:monero.social> how risky to share unrestricted RPC node to someone else?

<r​ecanman:agoradesk.com> Pretty much, yeah. Same risks

<h​ardenedsteel:monero.social> > If the RPC is used to retrieve information not dependent on any spending, consider using a view-only to prevent abuse.

<h​ardenedsteel:monero.social> getmonero.dev/docs/interacting/mone…rence.html#linux-production-example

<h​ardenedsteel:monero.social> can someone spend the coins using unrestricted RPC?

<r​ecanman:agoradesk.com> I would say yes, with the `transfer` method

<r​ecanman:agoradesk.com> getmonero.org/resources/developer-guides/wallet-rpc.html#transfer

MeowingCat #monero-community for ccs proposal discussion

<f​:monero.social> Creating a stagenet wallet from CLI with `--offline --restore-date "$(date +%Y-%m-%d)"` sets `refresh-from-block-height` about 3.7 days (~2660 blocks in my test) into the future, so that no `refresh` or rescan ever causes the funds to be found.

<f​:monero.social> I have also been wondering why an explicit `refresh 0` (or similar) will still respect the configured limit.

stagenet wallet restore height will be fixed in the next release

hi

<j​effro256:monero.social> Confirming on a different channel that I am infact renewing my GPG key: monero-project/monero #9326

<j​effro256:monero.social> @selsta seems like there is windows CI build issues: monero-project/monero #9326, monero-project/monero #9326

luigi has to do merges to get it fixed

<j​effro256:monero.social> kk cool thanks for being on top of it