06:29:54 <mechanic41turk[m> 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 (https://raspi.debian.net).
06:30:45 <mechanic41turk[m> 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`
06:31:03 <mechanic41turk[m> So, I had to force shutdown the raspi, and restart it.
06:31:23 <mechanic41turk[m> Now I logged into the raspi, and I was checking the bitmonero.log file
06:31:39 <mechanic41turk[m> I recognize the following log as being the origin of the issue:
06:32:14 * mechanic41turk[m sent a code block: https://libera.ems.host/_matrix/media/r0/download/libera.chat/c59863c0d56462cde2796fb8db9c5c16997cce51
06:33:02 <mechanic41turk[m> 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.
06:33:20 <mechanic41turk[m> and then, at line 16 above, gave a total FATAL error.
06:34:06 <mechanic41turk[m> Now I have restarted the monerod, and I am syncing the blockchain data.
06:35:19 <mechanic41turk[m> 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."
06:36:01 <mechanic41turk[m> 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?
06:51:16 <hyc> line 16 isn't a fatal error. it's an INFO message.
06:51:43 <hyc> judging by the datestamp, it's the startup message from when you restarted monerod
06:52:18 <hyc> you really should read more carefully
06:52:54 <hyc> "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.
06:53:37 <hyc> a hung machine probably means its storage device was hanging
06:53:55 <hyc> Pis have notoriously bad IO subsystems
07:02:53 <mechanic41turk[m> hyc: ah, you are right, it is an INFO message.
07:03:05 <mechanic41turk[m> thanks for clearing that up. from the datestamps, I was also suspicious of that.
07:03:23 <mechanic41turk[m> <hyc> "a hung machine probably means..." <- that is probably true. makes sense
07:04:10 <mechanic41turk[m> <hyc> "Pis have notoriously bad IO..." <- yeah. I guess I will just cross my fingers and hope for the best
15:36:25 <mechanic41turk[m> what is p2pool.io/mini ?
15:37:41 <sethsimmons> mechanic41turk[m]: A smaller sidechain that's been spun up, so more often getting shares but less often getting blocks.
15:37:53 <sethsimmons> Makes smaller miners feel better I guess
15:37:58 <mechanic41turk[m> > <@sethsimmons[m]:libera.chat> > <@mechanic41turk[m]:libera.chat> what is p2pool.io/mini ?
15:37:58 <mechanic41turk[m> > 
15:37:58 <mechanic41turk[m> > A smaller sidechain that's been spun up, so more often getting shares but less often getting blocks.
15:37:58 <mechanic41turk[m> so it is another p2pool instance?
15:38:05 <mechanic41turk[m> sethsimmons[m]: yeah, that I can guess
15:38:57 <nioc> yes it is another p2pool instance
15:39:09 <nioc> they even have an irc channel :)
15:39:12 <sethsimmons> > <@mechanic41turk[m]:libera.chat> > <@sethsimmons[m]:libera.chat> > <@mechanic41turk[m]:libera.chat> what is p2pool.io/mini ?... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/6f4a4b25ee560b208ea29bb3761e3ff2ae1e5f98)
15:39:24 <mechanic41turk[m> nice
15:39:35 <mechanic41turk[m> good to see more than one p2pool chain going on
15:39:56 <hyc> more shares of a smaller pie, or fewer shares of a bigger pie. it's all psychobabble
15:40:06 <sethsimmons> hyc: yup
15:59:53 <pauliouk> either way, you get pie :D
16:11:58 <hyc> at about the same frequency too
16:16:25 <sech1> hyc fewer shares of a bigger pie are better because you save on fees when combining your inputs later
16:17:12 <sethsimmons> sech1: Ahh, that is the one real advantage! Hadn't considered that it ends up being a lower fee pool, in a sense.
16:17:59 <hyc> I would think the p2pool minimum payout size is the same regardless
16:18:06 <hyc> no?
16:18:24 <sech1> it's better to have 3-4-5 shares in PPLNS window and get bigger payouts with each block
16:18:50 <sech1> if you only get the minimal payout with each block, it's ~0.8% transaction fee when you combine inputs
16:18:57 <sech1> *consolidate
16:19:28 <hyc> pretty sure I'm getting minimum payouts right now.
16:19:38 <hyc> most casual miners will be, if they get anything at all
16:27:51 <nioc> if small enough then it might make little difference 
16:28:29 <hyc> right
16:30:11 <hyc> 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?
16:30:25 <hyc> or just send directly to main wallet in tiny pieces
16:30:37 <sech1> it's more efficient to sweep all
16:30:43 <sech1> and wait until you have ~190 inputs
16:31:04 <sech1> then it's only ~519 bytes per input
16:31:32 <sech1> and you can sweep all directly to your main wallet
16:31:58 <sech1> 1 transaction can have 192-193 inputs before it hits the size limit
16:32:29 <sethsimmons> 194 from personal experience 😛
16:32:34 <hyc> heh
16:33:03 <nioc> virtually no savings waiting for that many inputs and txs of that size can be very resource intensive for people's daemons 
16:34:30 <sech1> why no savings? You save ~3x on the fees compared to a 1in/2out transaction
16:35:50 <nioc> savings of 1 194 input vs 2x97 input txs is 0.5kB
16:36:36 <nioc> have not looked at percentages 
16:36:58 <sethsimmons> Yeah I just batch when I have a "good number" of payout outputs instead of maximizing to 194 now
16:37:24 <sech1> it's easy to maximize on p2pool-mini because blocks don't come that often there :P
16:37:30 <sethsimmons> You certainly shouldn't sweep_single, but the scaling isn't necessarily worth waiting for ~194 inputs before being able to spend funds. 
16:38:10 <sech1> yes, 50 inputs or more is already enough to gain most of the possible fee savings
16:54:22 <pauliouk> xmrvsbeast is certainly maximising on mini :) and considering the services he provides around 210 miners, hell, well deserved :)