<o​frnxmr:agoradesk.com> What chain was it that recently added that as a "feature"? Bch?

<o​frnxmr:agoradesk.com> Let me rephrase:

<o​frnxmr:agoradesk.com> i dont remember where i read about it. Maybe its a monero pr. Maybe is old news.

<o​frnxmr:agoradesk.com> but i do remember that some chain'a feature was to spend before sync

Boog900 full time work on Cuprate (3 months) has moved to funding! ccs.getmonero.org/proposals/boog_3_months_cuprate.html

<i​nterestingband:matrix.org> "...work on the protocol ..."

<i​nterestingband:matrix.org> hahahaha

<l​akshmana:matrix.org> How can I contribute to the Monero project

<m​onerobull:matrix.org> hi there, many different ways to do so :)

<m​onerobull:matrix.org> can you code?

<m​onerobull:matrix.org> a good place to get started might be bounties.monero.social

<l​akshmana:matrix.org> I can code a little but I'm guessing the bar is too high for me to be of much use

<l​akshmana:matrix.org> Ill start running a full node 24/7 and look at the bounties I do know a few languages

<m​onerobull:matrix.org> full node is already a great first step, also better for your own privacy :)

<m​onerobull:matrix.org> be sure to open ports if you can

<m​onerobull:matrix.org> helps make the network more decentralized

<l​akshmana:matrix.org> which ports

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/uEecPHyxsgwQTBWfwfiJicOG

<g​fdshygti53:monero.social> 18080 & 18089

<g​fdshygti53:monero.social> Actually I route my 18081 to internet 18089

<m​onerobull:matrix.org> 18089?

<g​fdshygti53:monero.social> and 18089 to 18089

<g​fdshygti53:monero.social> I use 18081 for unrestricted rpc

<l​akshmana:matrix.org> Alright ill do that

<g​fdshygti53:monero.social> Actually I route my 18081 to internal 18089

<m​onerobull:matrix.org> dont make unrestricted rpc public though

<m​onerobull:matrix.org> im pretty sure someone could set your node to mine xmr that way :P

<g​fdshygti53:monero.social> Or shut your node down

<m​onerobull:matrix.org> im using github.com/lalanza808/docker-monero-node

<m​onerobull:matrix.org> its very nice

<g​fdshygti53:monero.social> I want these stats without installing the docker thing

<l​akshmana:matrix.org> This looks great Ill definitely use it

<l​akshmana:matrix.org> What linux distro should I try next?

<l​akshmana:matrix.org> And dont say Arch

<g​fdshygti53:monero.social> Alpine

<m​onerobull:matrix.org> i think you can manually install it if you set up everything yourself

<g​fdshygti53:monero.social> I seam to use many stuff (prometheus, Grafana and nodemapper)

<g​fdshygti53:monero.social> Have to figure out how to use that stuff or just switch to the docker thing (I can probably do it while keeping the lmdb I already have)

<l​akshmana:matrix.org> Looks sweet thanks

<m​onerobull:matrix.org> yeah

<m​onerobull:matrix.org> you just need to tell it where the chaindata is

<a​js_:matrix.org> Anyone have any idea of what’s the deal with the recent transaction influx

<m​onerobull:matrix.org> could be binance

<l​akshmana:matrix.org> Market makers making the markets?

<m​onerobull:matrix.org> more like shutting down shoü

<m​onerobull:matrix.org> more like shutting down shop

<p​reland:matrix.org> On that topic, does anyone know if xmr is affected by the “gamma squeeze” nonsense happening with Bitcoin?

the what

<r​4v3r23:monero.social> isnt bitcoin gamma squeeze resistant?

<r​4v3r23:monero.social> i thought it could resist all teh things?

<g​fdshygti53:monero.social> Did the "peer map" loaded initially or it take time?

<g​fdshygti53:monero.social> Or it's broken...

<g​fdshygti53:monero.social> top section have nothing in "peer counts" yet I have uploaded more than 1GB in 5 minutes...

<m​onerobull:matrix.org> Is you node public?

<m​onerobull:matrix.org> Is your node public?

<g​fdshygti53:monero.social> yes of course

<g​fdshygti53:monero.social> my non docker node hade like 12(out)+149(in) or something like that

<m​onerobull:matrix.org> It uses rpc to get the data, didn't you say you changed some ports?

<g​fdshygti53:monero.social> I used the normal ports, that one use different one (unrestricted on 18083 and restricted on 18081). That should not matter as it's all configured in the docker stuff.

<g​fdshygti53:monero.social> I just adjusted my firewall to redirect all incoming (18081/83/89) to 18081.

<g​fdshygti53:monero.social> 18080 is also forwarder and did not touch to that one as it's not changed

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/xyyTshynJuvvbZeTSIqukKAP

<g​fdshygti53:monero.social> I think the GEOIP stuff is broken

<g​fdshygti53:monero.social> or something

<g​fdshygti53:monero.social> probably why the peers don't show up in the dashboard

<m​onerobull:matrix.org> You may have to generate an API key

<m​onerobull:matrix.org> It's been a long time since I've set mine up

<g​fdshygti53:monero.social> I see, will take a look

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/nwLzqsQsXkwonpManvclPMiW

<g​fdshygti53:monero.social> Something definitively broken

<g​fdshygti53:monero.social> I'm going to keep it as other metrics do work (except the map and peer list)

<m​onerobull:matrix.org> Cool

<m​onerobull:matrix.org> Good luck figuring out the issue if you're going to pursue it

<s​iren:kernal.eu> The geoip database it's trying to query is down.

<s​iren:kernal.eu> Many things are down, could be that the geoip api was hosted on AWS. downdetector.com

<s​iren:kernal.eu> Python developers are great as usual

<s​iren:kernal.eu> Something as minor as displaying a country flag can break your whole program, lovely

<m​onerobull:matrix.org> lol

<m​onerobull:matrix.org> internet gone again

<s​iren:kernal.eu> Only the shit parts of it :D

Maybe it finally happened techcentral.co.za/fears-red-sea-attack-on-internet-cables/239195

<r​ucknium:monero.social> There is a large backlog of Monero txs now. Try `print_pool_stats` in your monerod console, "estimated 14 block (28 minutes) backlog"

<r​ucknium:monero.social> Increase your fee if you don't want your tx put into the backlog.

<m​onerobull:matrix.org> sech1 it did

<m​onerobull:matrix.org> there was a cable blown up i believe last week

<m​onerobull:matrix.org> but that was where the rebels fight the US right now

<m​onerobull:matrix.org> theres also that retard trying to reuse zeph hashrate

<r​ucknium:monero.social> monerobull: Do you mean the monerod messages that say you are years behind in the blockchain? Probably not related to ZEPH. Their blockchain height is much lower than Monero's now.

<m​onerobull:matrix.org> yeah those

<m​onerobull:matrix.org> anyways, why do my rpc requests fail when im INSIDE THE DOCKER CONTAINER

<m​onerobull:matrix.org> root@1e760f5471d3:/# monerod print_net_stats

<m​onerobull:matrix.org> 2024-03-05 17:51:07.323 I Monero 'Fluorine Fermi' (v0.18.3.1-release)

<m​onerobull:matrix.org> Error: Unsuccessful-- rpc_request:

<r​ucknium:monero.social> Because Docker is hard to debug. I never really try to send those commands to monerod like that. I just keep the monerod console open and `screen` into it to ask it what is happening.

<p​lowsof:matrix.org> sech1 jeffros deduct tx fee from output makes spamming the chain 50% more convenient and probably cheaper

seems like some nodes are falling a-3 blocks behinds rn

including mine

plowsof sweep_single does exactly the same (deduct fee from output), and it also creates 1/2 transactions

ah good point, i should have mentioned "for a pleb like me" lol

has p2pool been getting any luck with mining these full blocks?

p2pool.observer xD

nioCat: my nodes so far have been fine

<g​fdshygti53:monero.social> Because the thing don't use the normal port

<g​fdshygti53:monero.social> unrestricted is 18081 normally while that docker thing put it to 18083 instead (and put 18081 as the restricted one)

selsta: all are good now but wasn't when I posted, I was checking sync_info

nioCat: hmm i'm not sure but i think sync_info is sometimes delayed

<g​fdshygti53:monero.social> So it work fine for the container ecosystem, all the stuff configured to use 18083 for restricted but yeah, if you use monerod commands it will try to use 18081

the height of the other nodes in sync_info

I was getting messages that I was 1 or 2 blocks behind for ~30mins

same time that I checked sync_info

i'll keep an eye out on my nodes

<g​fdshygti53:monero.social> matrix.monero.social/_matrix/media/…ero.social/OFwlTnpeMVUDZSflTzNEBbKu

mine didn't have any behin messages

<q​q110245:matrix.org> Can you speak Chinese here?

English only please

<m​onerobull:matrix.org> how do i run them then?

<o​frnxmr:agoradesk.com> ./monerod command

<g​fdshygti53:monero.social> 1> It's probably possible to tell monerod to connect to a different RPC port, in that case specify 18083 (don't have the parameters in my head

<g​fdshygti53:monero.social> 2 > You can edit all the containers stuff so it use 18081 for unrestricted and 18089 for restricted (the normal ports)

<g​fdshygti53:monero.social> Then route you're port appropriatly (internet 18081 -> local 18089, internet 18083 -> 18089... etc etc)

<g​fdshygti53:monero.social> Then you will be able to run monerod command

<g​fdshygti53:monero.social> 3 > You can probe the methodes manually (wget 127.0.0.1:18083/get_peer_list (or whatever command) then decode the json with your brain

<g​fdshygti53:monero.social> monerobull

<o​frnxmr:agoradesk.com> Selsta - my node too, has not fallen behind or had any reorgs

<o​frnxmr:agoradesk.com> And yes, its better to _add_ restricted rpc binds, not to restrict the unrestricted

<o​frnxmr:agoradesk.com> Else you lose the ability to _use_ the unrestricted...

<g​fdshygti53:monero.social> It's just that the monero docker node decited to put restricted on 18081 😂

<o​frnxmr:agoradesk.com> yes

<o​frnxmr:agoradesk.com> Most configs are bad

<g​fdshygti53:monero.social> Like that's the default

<g​fdshygti53:monero.social> I assume it's fine for like if you install that on a VPS that is directly connected on the net or something

<o​frnxmr:agoradesk.com> nah its still silly

<o​frnxmr:agoradesk.com> You need unrestricted if you want to talk to the daemon

<g​fdshygti53:monero.social> Sorry, I ment, they pur unrestricted on 18081 and restricted on 18083

<g​fdshygti53:monero.social> While all tools normally expect unrestricted on 18081 and restricted on 18089

<g​fdshygti53:monero.social> Sorry, I ment, they pur restricted on 18081 and unrestricted on 18083

<g​fdshygti53:monero.social> While all tools normally expect unrestricted on 18081 and restricted on 18089

<o​frnxmr:agoradesk.com> Lalanzas?

<g​fdshygti53:monero.social> yes

Boog900 full time work on Cuprate (3 months) is now fully funded! ccs.getmonero.org/proposals/boog_3_months_cuprate.html @luigi1111

<s​hortwavesurfer2009:monero.social> With the high amount of transactions, it looks like we've had a hundred full blocks. Is the block size likely to expand? And where can I see the Monero Mempool?

.mempool

try xmrchain.net for mempool and related info

<s​hortwavesurfer2009:monero.social> Thx

<b​oog900:monero.social> wow, thank you ❤️

block size is already expanding

median block size limit is up to just over 300kB up from, what was it, 297?

<s​hortwavesurfer2009:monero.social> I wasn't aware the blocks could shrink to anything under 300 kilobytes.

Median block size limit: 300.57 kB

300.57 kB = 307783 bytes

normally it's 300000 bytes = 292.97 kB

<s​hortwavesurfer2009:monero.social> So blocks over that dont get the full .6xmr fee correct?

<s​hortwavesurfer2009:monero.social> The tx fees have to be bigger than that loss

yes

Monerobull was mad i didnt know that.. i dont think ive been forgiven

<m​onerobull:matrix.org> lol

Definitely not forgiven^ Tail emission video if youve not seen shortwavesurfer2009 yewtu.be/watch?v=sRwSqM0YBto

<s​hortwavesurfer2009:monero.social> Thanks, does that kick in at the median like right now or is there some higher limit

<s​hortwavesurfer2009:monero.social> I think 18081/get_info said something about something over 600k bytes

<0​xfffc:matrix.org> Honest question. Does anyone in entire cosmos use this? github.com/mj-xmr/SolOptXMR

<e​ndor00:matrix.org> Once it's finished, I hope so

<e​ndor00:matrix.org> Currently working on the energy redistribution algorithm (i.e. prioritize mining during the most profitable hours within the predicted timeframe, while keeping the battery charge above a given threshold)

<e​ndor00:matrix.org> Getting the implementation right is a pain in the ass, so I'm in the process of rewriting it with heavy testing to ensure that everything is consistent

<s​nowman:tetaneutral.net> I was able to just tie miners into home automation software. can start them, stop them and change cpu #'s. just this alone can allow an infinite number of usages

<s​nowman:tetaneutral.net> Xmrig has a nice http api. That all is needed. No need for package, though I like people tinkering

<s​nowman:tetaneutral.net> I was able to create a custom thermostat automation in home assistant that turn my miner on and off if temp gets too high or low depending on temp sensor in the room

<s​nowman:tetaneutral.net> i can even pull in hashrate data- if it goes undetected, i get a notification.

<s​nowman:tetaneutral.net> battery pack status can easily be pulled into automation by a simple arduino / voltage sensor.

<e​ndor00:matrix.org> Yeah, the automation part is not that complicated

<e​ndor00:matrix.org> What you're missing is a smarter criterium to choose when to turn your miners on for maximum profit

<e​ndor00:matrix.org> While also looking at weather forecasts to estimate solar energy production, and combining these two in the most efficient way

<e​ndor00:matrix.org> Otherwise you can end up mining when the difficulty is higher, and then your battery is drained just when the diff is starting to drop again