Hello. Last night I was syncing the monero blockchain into a new node setup of mine, which is running on raspberry pi 4 (4GB), with debian 11 (raspi.debian.net).

I woke up this morning to see that my raspberry pi wasn't responding to my ssh connection requests. It was simply waiting after I gave the `$ ssh user⊙111`

So, I had to force shutdown the raspi, and restart it.

Now I logged into the raspi, and I was checking the bitmonero.log file

I recognize the following log as being the origin of the issue:

as you can see, for quite a while (continuing up the log for some time) the syncing node didn't pull the block data from other peers, but only pulled the new top block.

and then, at line 16 above, gave a total FATAL error.

Now I have restarted the monerod, and I am syncing the blockchain data.

I was worried that my force shutdown to the raspi would again result in corrupted state of the local data for monero blockchain. But to my surprise, after the hard shutdown, and restarting the monerod, it didn't complain about "core dumped."

Any comments as to what happened overnight that caused my node to FATAL-ly fail and before that not pull any of the blockchain data from other peers?

line 16 isn't a fatal error. it's an INFO message.

judging by the datestamp, it's the startup message from when you restarted monerod

you really should read more carefully

"New log categories: ..." and then a list of log levels. not an error message at all, it's just telling you what the current log settings are.

a hung machine probably means its storage device was hanging

Pis have notoriously bad IO subsystems

hyc: ah, you are right, it is an INFO message.

thanks for clearing that up. from the datestamps, I was also suspicious of that.

<hyc> "a hung machine probably means..." <- that is probably true. makes sense

<hyc> "Pis have notoriously bad IO..." <- yeah. I guess I will just cross my fingers and hope for the best

what is p2pool.io/mini ?

mechanic41turk[m]: A smaller sidechain that's been spun up, so more often getting shares but less often getting blocks.

Makes smaller miners feel better I guess

> <@sethsimmons[m]:libera.chat> > <@mechanic41turk[m]:libera.chat> what is p2pool.io/mini ?

>

> A smaller sidechain that's been spun up, so more often getting shares but less often getting blocks.

so it is another p2pool instance?

sethsimmons[m]: yeah, that I can guess

yes it is another p2pool instance

they even have an irc channel :)

> <@mechanic41turk[m]:libera.chat> > <@sethsimmons[m]:libera.chat> > <@mechanic41turk[m]:libera.chat> what is p2pool.io/mini ?... (full message at libera.ems.host/_matrix/media/r0/do…b25ee560b208ea29bb3761e3ff2ae1e5f98)

nice

good to see more than one p2pool chain going on

more shares of a smaller pie, or fewer shares of a bigger pie. it's all psychobabble

hyc: yup

either way, you get pie :D

at about the same frequency too

hyc fewer shares of a bigger pie are better because you save on fees when combining your inputs later

sech1: Ahh, that is the one real advantage! Hadn't considered that it ends up being a lower fee pool, in a sense.

I would think the p2pool minimum payout size is the same regardless

no?

it's better to have 3-4-5 shares in PPLNS window and get bigger payouts with each block

if you only get the minimal payout with each block, it's ~0.8% transaction fee when you combine inputs

*consolidate

pretty sure I'm getting minimum payouts right now.

most casual miners will be, if they get anything at all

if small enough then it might make little difference

right

so perhaps we should talk about that. is it better to sweep all the tiny outputs into one output in the mining wallet first, before sending to main wallet?

or just send directly to main wallet in tiny pieces

it's more efficient to sweep all

and wait until you have ~190 inputs

then it's only ~519 bytes per input

and you can sweep all directly to your main wallet

1 transaction can have 192-193 inputs before it hits the size limit

194 from personal experience 😛

heh

virtually no savings waiting for that many inputs and txs of that size can be very resource intensive for people's daemons

why no savings? You save ~3x on the fees compared to a 1in/2out transaction

savings of 1 194 input vs 2x97 input txs is 0.5kB

have not looked at percentages

Yeah I just batch when I have a "good number" of payout outputs instead of maximizing to 194 now

it's easy to maximize on p2pool-mini because blocks don't come that often there :P

You certainly shouldn't sweep_single, but the scaling isn't necessarily worth waiting for ~194 inputs before being able to spend funds.

yes, 50 inputs or more is already enough to gain most of the possible fee savings

xmrvsbeast is certainly maximising on mini :) and considering the services he provides around 210 miners, hell, well deserved :)