07:44:53 <fredrikk[m]> Hey all,... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/e7f0c6e2603bb533ef789a4ec6537c0ed78d0a44>)
07:50:20 <merope> It would definitely be a great contribution
07:51:48 <merope> Might want to ask the people in #monero-outreach:monero.social for some tips/material/logistical support before creating pages and stuff, but this kind of outreach is very important 
07:54:52 <fredrikk[m]> Ok, thank you! I will head over to Outreach.
07:57:54 <merope> (It's not a very active channel, but people are still in there so I'm hoping they will still come back to you)
08:09:29 <sech1> Hej Fredrik! That would definitely be helpful. I keep seeing Monero stickers all over Stockholm, but people have no clue here
08:16:33 <fredrikk[m]> Hej! Cool. Yeah I've seen in Gothenburg also. But exactly, people do not seem to have a clue. But can't really blame people either, this is 'pretty far out there' at the moment. I'm so sick and tired of the old system I feel i have to do something.
14:34:36 <ofrnxmr[m]> jtgrassie: spamming the code?
14:35:48 <ofrnxmr[m]> You set the block template refresh to 120s. Please correct me in my assumption that was confirmed when I asked in my opening comment
14:36:10 <ofrnxmr[m]> The pool grabs the block template when a new block is mined, and then again in 120s
14:37:18 <ofrnxmr[m]> > it's NOT a terrible option. the pool has been set to 2 mins since launch and works absolutely fine as 2 mins. xmrig is a miner not a pool. You clearly have minimal understanding of the effect of this option. Please stop spamming the code.
14:37:18 <ofrnxmr[m]> https://libera.monerologs.net/monero-research-lab/20221216#c178125
14:38:04 <ofrnxmr[m]> Context:
14:38:04 <ofrnxmr[m]> https://github.com/jtgrassie/monero-pool/commit/e8ce65a074ae45662ab3ccb4c111a9eb6f50d7b5#r100431525
14:40:08 <ofrnxmr[m]> here is what 2mins looks like: block 2821003
14:41:08 <ofrnxmr[m]> * here is what 2mins looks like: block 2821003
14:41:08 <ofrnxmr[m]> https://xmrchain.net/block/d1d9445c698c43ea04ec2ce62b512ef9718fbd39ac54806a9b90a65903b21069)
14:43:23 <ofrnxmr[m]> > xmrig is a miner not a pool. You clearly have minimal understanding of the effect of this option.
14:43:23 <ofrnxmr[m]> Did you forget xmrig and xmrig proxy connect to the daemon when solominjng? Its the same functionality. Man i hate liars 
14:44:19 <ofrnxmr[m]> Meanwhile nanopool is updating every10s while jtgrassie makes false claims about load to excuse putting out an update that is roughly the same bullshit behavior as prior 
14:44:53 <ofrnxmr[m]> (But user configurable).. lol, why in the world would some ship asshole defaults? Probably because theirs an asshole
14:44:56 <ofrnxmr[m]> They're*
15:05:02 <jtgrassie> ofrnxmr[m]: the profit difference between 2 mins and 20 secs is negligle. The load difference is significant.
15:06:26 <jtgrassie> so you might think you know what you're talking about but you clearly have never ran a high load pool and ran the numbers
15:08:17 <jtgrassie> you being bitchy with me for adding this as an option is bizarre, as before it was fixed at 2 minutes and now I've added the option for a pool op to lower via conf
15:09:18 <ofrnxmr[m]> https://www.reddit.com/r/Monero/comments/10gapp9/centralized_mining_pools_are_delaying_monero/j53hi92/
15:09:46 <plowsof11> unrelated: for matrix users (or if your app has this feature) - please disable thumbnail / image previews. this can be done via all settings -> preferences and finding the relevant options and disabling them. now back to mining discussion thank you 
15:10:08 <ofrnxmr[m]> jtgrassie: Bitching because while everyone else runs 30 or better, youre releasing bullshit software 
15:10:23 <ofrnxmr[m]> And its not about  the fees, your defaults bloat the tx pool
15:10:36 <ofrnxmr[m]> I repeat: Terrible defaults 
15:10:46 <jtgrassie> ofrnxmr[m]: "youre releasing bullshit software" <- I've made it a USER CONFIG OPTION
15:11:03 <jtgrassie> You are free to use or not, change or not.
15:11:29 <ofrnxmr[m]> I dont pool mine, im bust contacting people using tour software 
15:11:30 <jtgrassie> don't like? don't use. Fuck off
15:11:36 <ofrnxmr[m]> Wondering why they are mining 0 tx
15:11:53 <ofrnxmr[m]> I dont use it lol
15:12:21 <jtgrassie> Good.
15:12:48 <ofrnxmr[m]> Good what? That your software leads to ddosing the tx pool?
15:13:32 <jtgrassie> Lol you have no fucking idea what you are on about. It doesn't ddos anything.
15:13:53 <ofrnxmr[m]> You're an idiot 
15:14:14 <ofrnxmr[m]> If there are 100tx in the pool and you mine 0, you leave those to continue to pile up above the 300kb limit, dumbass
15:14:31 <ofrnxmr[m]> Dont act so smart when you dont know what youre talking about 
15:15:05 <jtgrassie> and someone else get's them then
15:15:24 <jtgrassie> you talk a lot, but don't contribute
15:15:43 <ofrnxmr[m]> 🥳
15:16:24 <jtgrassie> you don't have to use the pool, you don't have to use the default settings
15:16:34 <jtgrassie> you can set to whatever you want
15:17:55 <jtgrassie> trolling people that actually contribute something is not a good look
15:18:11 <ofrnxmr[m]> I dont have a mirror
15:18:25 <ofrnxmr[m]> Not concerned with how I look to liars
15:18:35 <ofrnxmr[m]> Anyway, thanks for the user config option 
15:18:47 <ofrnxmr[m]> No thanks for leaving the default retarded 
15:19:06 <ofrnxmr[m]> Sincerely - the person wasting Hus time cleaning up your mess
15:19:57 <plowsof11> p2pool has a nice feature of including high fee transactions immediately in the block if seen in mempool. it cares about UX because it updates the template often also 
15:21:13 <jtgrassie> yep, and p2pool works completely differently to a centralized pool
15:21:41 <ofrnxmr[m]> So kill your pool software 
15:21:46 <ofrnxmr[m]> It really shouldn't be used with those settings, at all, by anyone 
15:22:03 <jtgrassie> says the person who doesn't run a pool...
15:22:36 <plowsof11> neither does jtgrassie unless you want to prove it 
15:22:53 <ofrnxmr[m]> jtgrassie: Lol says the person who's pool is configs to mine 0 tx by default ^^
15:23:32 <jtgrassie> ofrnxmr[m]: except it doesn't work how you insinuate
15:23:47 <jtgrassie> plowsof11: monerop.com the public ref pool
15:24:02 <jtgrassie> plowsof11: also run 2 private pools
15:24:22 <dsmlegend[m]> <jtgrassie> "trolling people that actually..." <- I think he means well but just wasn't properly socialised as a child and now has trouble expressing his concerns in a helpful way. Is there any possibility he may be misunderstanding you and the reasons for your defaults?
15:24:34 <ofrnxmr[m]> https://libera.monerologs.net/monero-research-lab/20221216#c178124
15:24:34 <ofrnxmr[m]> So you are talking shit here?
15:24:53 <ofrnxmr[m]> It works exactly the way I insinuate 
15:24:56 <plowsof11> thanks jtgrassie 
15:25:33 <ofrnxmr[m]> Are you running the defaults on those pools? 
15:25:42 <ofrnxmr[m]> Actually, I can probably just check
15:27:37 <jtgrassie> dsmlegend[m]: "I think he means well" <- I don't. 
15:28:08 <ofrnxmr[m]> Answer DSM question then
15:28:33 <jtgrassie> dsmlegend[m]: "Is there any possibility he may be misunderstanding you the reasons for your defaults?" possibly, but it's not my job to educate
15:29:48 <ofrnxmr[m]> Thanks everyone for attending 
15:33:51 <jtgrassie> guess I should make future updates privately and not release??
15:34:08 <ofrnxmr[m]> Sure
15:34:18 <ofrnxmr[m]> If thats how you feel
15:36:19 <jtgrassie> Luckily there are very few entitled idiots like you.
15:36:27 <ofrnxmr[m]> Personally, 👍 from me on that
15:36:38 <ofrnxmr[m]> Who's entitled? LMAO youre batty
15:36:55 <ofrnxmr[m]> You ask a q, I answer "do what you want" and you claim im entitled 
15:37:35 <ofrnxmr[m]> Anyone can fork your repo and adjust the line properly. I commented directly because I figured you made a mistake
15:38:08 <jtgrassie> you have been trolling me all morning. calling me a liar etc etc. all for developing someing and releasing a FEATURE that one can use (or not) and change (or not).
15:38:29 <ofrnxmr[m]> I asked a question and you gave a false answer 
15:38:43 <jtgrassie> "I figured you made a mistake" no mistake.
15:38:50 <ofrnxmr[m]> Claiming 2mins is perfectly acceptable lol.
15:38:56 <ofrnxmr[m]> jtgrassie: Yeah, I noticed 
15:39:03 <jtgrassie> "you gave a false answer" in your opinion as you don't know the answer
15:39:15 <ofrnxmr[m]> Anyway, its your software and I made my comments 
15:39:18 <jtgrassie> it is perfectly acceptable!
15:39:43 <ofrnxmr[m]> No it isnt 🤣
15:39:44 <ofrnxmr[m]> Ill agree to disagree
15:40:44 <jtgrassie> the *choice* is lower load vs small increase in reward
15:41:22 <ofrnxmr[m]> Wen taking repo offline?
15:41:41 <ofrnxmr[m]> So I can tell people to use the fork that has proper defaults 
15:41:42 <jtgrassie> and it's a *choice*, and it causes no harm
15:42:00 <sech1> how nanopool is able to handle 10-second template updates, and the "high load" pool defaults to 120 seconds?
15:42:18 <sech1> is nanopool not high-load?
15:42:30 <jtgrassie> maybe their pool isn't running on a rasp pi
15:43:26 <ofrnxmr[m]> My android node has no serving templates every 5 secs 
15:43:38 <ofrnxmr[m]> NP*
15:44:10 <jtgrassie> ofrnxmr[m]: so you're running a high load pool on an android phone? BS
15:44:30 <ofrnxmr[m]> You're runnign a high load pool on a rasp? Bs
15:44:36 <ofrnxmr[m]> Or stupid
15:45:06 <jtgrassie> I can't know what every user of monero-pool is running. Idiot
15:45:46 <ofrnxmr[m]> What kind of idiot assumes nanopool is going to run your shit on a pi?
15:46:05 <ofrnxmr[m]> Sub Nanopool for high load pool
15:46:29 <jtgrassie> I'm not assuming anything, that's the point!
15:46:46 <selsta> Why not set the default to 30s and if someone is having load issues they can still increase it? I assume a Raspberry isn't the usual choice for a pool.
15:47:15 <jtgrassie> that's why I made it a user configtion option
15:47:21 <ofrnxmr[m]> I suggested 45 (1-2 times per block on avg)
15:47:43 <ofrnxmr[m]> "120s is perfectly acceptable" and im trolling 🐒
15:48:01 <selsta> I know that it's user configurable but setting a sane default would be nice. Running a pool on a Raspberry is clearly an edge case.
15:48:12 <plowsof11> perfectly acceptable to miners who only care about the coinbase reward* but the ecosystem suffer 
15:48:13 <selsta> but your choice in the end so whatever
15:50:11 <jtgrassie> it's a USER choice now, that's why I made the change (which nobody else bothered to do)
15:50:48 <jtgrassie> having you all moan about a choice I added is super weird
15:51:00 <selsta> no one claims that it's not a user choice lol the discussion is about the default value which is your choice obviously
15:51:00 <plowsof11> boycott pools that update less than every 45 seconds 
15:51:58 <BusyBoredom[m]> Nobody is upset about there being a choice. People are upset that the default harms UX, and I think that's a very fair concern. 
15:52:00 <jtgrassie> selsta: every option in the config file could be questioned 
15:52:39 <jtgrassie> BusyBoredom[m]: "the default harms UX" every default has the ability to harm UX
15:53:37 <BusyBoredom[m]> Yep of course, and that's why we should be careful when decide on defaults. 
15:55:06 <jtgrassie> the default was always 120s (and not changable without recompiling), I added a change to make it user configurable
15:55:53 <BusyBoredom[m]> Nobody's upset with your change to make it configurable. That was a great change, thank you for making it. 
15:55:54 <jtgrassie> yet I get trolled and called a liar for contributing
15:56:58 <ofrnxmr[m]> Trolled lol
15:57:43 <ofrnxmr[m]> I only called you a liar after you tried to justify what is either a lie or a lack of knowledge. But then you claimed I didnt know what I was talking about
15:57:53 <ofrnxmr[m]> Thats a liar right there LOL
15:58:57 <ofrnxmr[m]> Not about about my approach though, its about the setting and understanding the justification for it - not that youre obligated to justify anything
15:59:37 <ofrnxmr[m]> But its nice when good people do good things, instead of deflecting while doing questionable things  
16:03:15 <jtgrassie> ofrnxmr[m]: you call this a lie "the *choice* is lower load vs small increase in reward"
16:03:28 <jtgrassie> because that is factual
16:04:44 <jtgrassie> you might not like the fact (or agree with it), but it's still a fact
16:04:56 <ofrnxmr[m]> 🍿 still claiming that load like are we
16:05:08 <ofrnxmr[m]> Line*
16:05:25 <ofrnxmr[m]> And talking about tx fees, ayye.  Lol
16:05:42 <sech1> pools auto-adjust difficulty to get shares from miners every 30 seconds, so why the default can't be set to 30 seconds? Is generating new miner job harder than checking a share? I don't think so
16:06:56 <jtgrassie> set it to whatever you like
16:09:38 <jtgrassie> (fwiw I have it set to 45s on the reference pool)
16:09:51 <sech1> rookie numbers
16:09:55 <sech1> all major pools are below 30 now
16:10:16 <jtgrassie> again, set it to whatever you like
16:10:25 <sech1> I like 30 or less
16:11:16 <ofrnxmr[m]> 45sec in theory averages out with 30 secs, with the last update before an expected block being 30 secs before
16:11:16 <ofrnxmr[m]> But 120secs is asshole numbers 
16:12:23 <plowsof11> linking https://rucknium.me/posts/monero-pool-transaction-delay/ if anyone has not seen the data 
16:13:05 <plowsof11> monero fees are so low, miners could probably get away with "mining empty blocks" but it would hurt UX
16:13:33 <ofrnxmr[m]> Ive seen 0.7 blocks
16:13:46 <ofrnxmr[m]> Usually because someone left 100tx on the table 
16:14:09 <jtgrassie> ofrnxmr[m]: again, set it to whatever you like
16:14:31 <ofrnxmr[m]> Do us a favor and set to 45sec, pretty please?
16:15:34 <jtgrassie> you can run a pool and set to whatever you like
16:15:36 <plowsof11> updating blocks every 120s allowed "in September 2021 [..] an estimated 72 XMR additional revenue for P2Pool miners."
16:15:59 <plowsof11> so the p2pool miners shld thank you
16:16:09 <plowsof11> that advantage is now gone 
16:16:24 <jtgrassie> ^^
16:16:41 <ofrnxmr[m]> But the people using monero shouldn't 
16:17:12 <plowsof11> i would also like to note that the monero pool on jtgrassies github has no built in donation fee
16:17:42 <ofrnxmr[m]> Its not gone 
16:17:48 <ofrnxmr[m]> https://xmrchain.net/block/d1d9445c698c43ea04ec2ce62b512ef9718fbd39ac54806a9b90a65903b21069)
16:18:36 <ofrnxmr[m]> Heres s block from today where c3pool mined 0 tx while there were 30+ people waiting for the bus
16:18:39 <ofrnxmr[m]> Which had to wait 5+ more mins 
16:19:23 <jtgrassie> plowsof11: thank you for reminding them
16:19:23 <xfedex[m]> jtgrassie: why template-timeout = 60?
16:19:38 <xfedex[m]> wouldnt something like 10 or 20 be better?
16:19:51 <jtgrassie> xfedex[m]: because that's what the reference pool is running
16:20:33 <xfedex[m]> the cost of getting a new template is very low, much lower than the transaction fees you'd earn, at least on a coin like XMR
16:20:49 <jtgrassie> "i would also like to note that the monero pool on jtgrassies github has no built in donation fee" <- unlike node-js pool and xmrig miner
16:21:48 <jtgrassie> xfedex[m]: it's a user config option, change to you hearts content
16:22:03 <ofrnxmr[m]> P2pooler doesnt either (centralized pool on p2pool)
16:22:07 <xfedex[m]> whats the reason for such a high default value tho?
16:22:23 <xfedex[m]> p2pool has 10 seconds if i am correct
16:22:47 <jtgrassie> "whats the reason for such a high default value tho?" it used to be 120s and not changable
16:22:53 <ofrnxmr[m]> And xmrig is one of the lowest fee miners, one of the only open source, and advertised disabling it 
16:22:55 <ofrnxmr[m]> Xmrig also GPU mines many different algos
16:23:09 <ofrnxmr[m]> xfedex[m]: Because someone might run a High load pool on a pi, or smth
16:23:27 <ofrnxmr[m]> Thats not an answer ^ lol
16:24:37 <jtgrassie> ofrnxmr[m]: I seriously hoe you don't talk like this to all Monero contributors
16:24:51 <ofrnxmr[m]> :( I do though 
16:25:10 <jtgrassie> we've lost other developers because of being hounded by twats like you
16:25:43 <jtgrassie> if you want to put off peole from contributing, carry on
16:25:53 <ofrnxmr[m]> Tell me I hurt your feelings without telling me your feelings are hurt 
16:26:06 <ofrnxmr[m]> Itd a quick change s/120/45
16:26:15 <jtgrassie> I'm pissed at even having this conv
16:26:21 <ofrnxmr[m]> Stop being a crybaby 
16:26:27 <plowsof11> i think it is now 45s and configurable* 
16:26:29 <ofrnxmr[m]> You should be 
16:26:48 <jtgrassie> I developed something, keep it updated, added a feature, and you bitch and moan
16:27:24 <ofrnxmr[m]> Its 60 now 
16:27:37 <ofrnxmr[m]> Better than 120, but what a guy
16:27:44 <xfedex[m]> i think it should be 20
16:27:49 <xfedex[m]> or 30
16:27:53 <jtgrassie> ofrnxmr[m]: "You should be" < you should be ashamed of yourself
16:28:07 <plowsof11> pls remember the extra 72 moneros p2poolers got and be thankfulfortoday
16:28:28 <ofrnxmr[m]> Why would I be? Im nit too prideful to make a change from 120-45
16:28:31 <jtgrassie> xfedex[m]: 20s would be lower than the vardif target of 30s, so pointless
16:28:33 <ofrnxmr[m]> You should be ashamed 
16:29:05 <xfedex[m]> jtgrassie, what's vardif?
16:29:16 <jtgrassie> ofrnxmr[m]: "You should be ashamed" < what for? developing open source code???
16:29:27 <ofrnxmr[m]> Variable difficulty adjustment when sending out jibs to miners 
16:29:55 <ofrnxmr[m]> jtgrassie: For having too much pride to make a simple change 
16:30:08 <BusyBoredom[m]> Man this is painful to watch. This whole conversation should have just been:
16:30:08 <BusyBoredom[m]> "Hey man, 120s is bad for UX, could you consider a lower default?" 
16:30:08 <BusyBoredom[m]> "Oh damn you're right, no problem I'll check that out next weekend"
16:30:44 <ofrnxmr[m]> Alright. Though, I apologize for being mean lol. But I am how I am. Thanks for the change 👍
16:30:55 <ofrnxmr[m]> > <@busyboredom:monero.social> Man this is painful to watch. This whole conversation should have just been:... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/453a00e6b8b91d2a9598217de33d18bb1ff0ee71>)
16:31:39 <ofrnxmr[m]> I commented on GitHub to confirm it was the update to the template time, then I suggested it should be set to lower, 45sec etc. Then was told no, its perfectly fineb
16:32:12 <jtgrassie> I do not *have* to make any changes, or engage with you.
16:32:22 <ofrnxmr[m]> And after some back and forth, told to stop spamming his git, so I brought the convo here.
16:32:22 <ofrnxmr[m]> Anyway.
16:32:22 <ofrnxmr[m]> All is ok now. 60 is better than 120 so ill shutup 
16:32:23 <jtgrassie> I owe you nothing
16:32:38 <ofrnxmr[m]> Right, i know 
16:33:13 <jtgrassie> I changed to 60s as that's what I run on the reference pool. 
16:33:27 <jtgrassie> and should shut you up
16:33:56 <ofrnxmr[m]> Well, id still ask you to try 45 seconds for yourself and consider changing from 69-45
16:34:17 <ofrnxmr[m]> 60-45. Not because I want you to, but because it works.
16:34:44 <jtgrassie> what I run is none of your busness or concern
16:35:08 <jtgrassie> you can set to whatever you like
16:35:22 <jtgrassie> now please, go away
16:36:08 <ofrnxmr[m]> So, how about the Superbowl? 
16:36:55 <ofrnxmr[m]> Anyone watch or notice anything monero happen?
16:38:56 <plowsof11> brb im setting my pool to 44 seconds (or 24.. maybe 25 .. none of you're business tbh)
16:39:25 <ofrnxmr[m]> Im going to try 24/25 seconds. Probably the best, right Sir?
16:39:56 <plowsof11> sounds good to me 😡
16:40:19 <ofrnxmr[m]> Sir, it says error when enter 24/25
16:41:38 <xfedex[m]> ofrnxmr[m]: Yes
16:41:39 <xfedex[m]> breaking news: the Big Botnet has switched back to hashvault.pro
16:42:39 <xfedex[m]> They are currently mining with ~1.0 GH/s to address 49ixgZU6cafjMkM6RjmR9UA3qhmRL5NrfQAyxR7BBcEjL2VQUSMbTs81scaTd6R7REaNFkbrebRruXQRP5sZHEjtRTKPyQC
16:43:41 <xfedex[m]> they are using 9 different xmrig-proxies
16:44:01 <xfedex[m]> so far the botnet has earned ~20k $
16:44:44 <merope> xfedex[m]: Actual proxies, or just bundling workers under the same names?
16:45:08 <cockliuser[m]> <jtgrassie> "plowsof: thank you for reminding..." <- Wait what lol, that piece of information implies that a 120s update time implies less revenue for miners on your pool
16:45:16 <xfedex[m]> merope: oh sorry they have many workers with different names
16:45:35 <cockliuser[m]> s/time implies/time means/
16:46:48 <plowsof11> out of context - his miner has no built in donation 
16:46:51 <sech1> They're using xmrig-proxy
16:47:26 <merope> A thoughtful botnet, how nice
16:47:27 <bridgerton[m]> <᷾s> Wait, matrix replies don't show up on IRC either!?!?
16:47:27 <xfedex[m]> sech1 since you have xmrig fees, can't you get the hacked IP addresses and then call the hosting?
16:49:17 <ofrnxmr[m]> I dont know if donation mined to a different address or to a different pool but
16:49:17 <plowsof11> not his problem 
16:49:17 <ofrnxmr[m]> Why tf would he do that 
16:49:37 <merope> GDPR complaint from the botnet owner incoming
16:58:39 <nioc> w0w
16:59:40 <nioc> drama was somehow unsatisfying 
17:00:11 <ofrnxmr[m]> Slow Monday 
17:03:38 <Siren[m]> We're selling MoneroKon tickets and exchanges are devaluing Monero price wtf
17:05:08 <ofrnxmr[m]> Trocador.app allows exchanging to localmonero
17:14:46 <Lovera[m]> Hi everyone 😅 thanks for the debate!... (full message at <https://libera.ems.host/_matrix/media/v3/download/libera.chat/ea7b0816870b5572b180d0b20bcb283d835c7f3e>)
17:22:21 <jtgrassie> Lovera[m]: "I think it’s proven that 30 seconds helps the network." has someone proven that 30s updates are meaningfully more helpful than 60s?
17:25:16 <rbrunner> "Man this is painful to watch." +1
17:25:45 <Lovera[m]> I’m not sure. It’s twice as long.
17:25:45 <Lovera[m]> If I didn’t miss anything in the conversation, wasn’t the default value 120?
17:26:59 <jtgrassie> Lovera[m]: yes it used to *default* to 120s, I made a change so it could be easily changed by the pool op and then changed the default in the conf file to try and end this conv.
17:27:09 <Lovera[m]> <jtgrassie> "I changed to 60s as that's..." <- Oh I see 
17:27:19 <jtgrassie> the default is now 60s
17:27:59 <jtgrassie> there are a load of other settings that have to be changed in the pool conf which is why this whole conv is ridiculus
17:29:04 <jtgrassie> but instead, the "community" likes to harass people
17:29:21 <jtgrassie> it's a wonder anyone contributes to monero
17:33:43 <Lovera[m]> Thanks for the change 👍🏼 it’s much better than 120 I guess.
17:33:43 <Lovera[m]> It is also true that if you have the file. CONF should modify this parameter. The only drawback I see is that the user does not have much knowledge about that value and does not touch it.
17:33:43 <Lovera[m]> Btw, A few years ago I used Monero pool to run my own pool in my neighborhood 😅 it helped me learn some things! I couldn’t find anything public, just monero-pool
17:35:33 <jtgrassie> glad it helped
17:36:22 <jtgrassie> "the user does not have much knowledge" <- yes, this is true of all the parameters
17:39:22 <jtgrassie> the reality is that even at 120s as the default setting, those that don't have the knowledge to change this won't be running a serious pool
17:39:42 <jtgrassie> same goes for all the other default settings!
17:41:55 <jtgrassie> Hence the impact to the "community" / network of leaving the default at 120s, is essentially zero 
17:43:35 <ofrnxmr[m]> The #5 pool is still misconfigured. Until I contacted them, the #1 pool was as well. Size of pool =/= understanding of the settings
17:44:30 <jtgrassie> ofrnxmr[m]: "Size of pool =/= understanding of the settings" < that is fair
17:45:48 <jtgrassie> "The #5 pool is still misconfigured" it's not misconfigured though, that's their choice or ignorance
17:46:27 <ofrnxmr[m]> Its misconfigured. They will update
17:47:07 <ofrnxmr[m]> 0 pools have decided to not update to as fast as reasonable. And I think the ones that went with 30s will likely change to 10s soon enough
17:47:11 <jtgrassie> it's configured as the set it
17:47:28 <jtgrassie> *they
17:47:50 <ofrnxmr[m]> C3pool uses monerooceans software. Moneroocean was configured badly, has been updated, c3 is running old version for now. Different language, so hard to communicate
17:48:17 <ofrnxmr[m]> All of them had defaults set (aka dont update or 2mins )
17:48:30 <ofrnxmr[m]> P2pool was the sole outlier 
17:48:53 <ofrnxmr[m]> (In top 10) 
17:48:53 <Rucknium[m]> Almost every pool I studied in https://rucknium.me/posts/monero-pool-transaction-delay/ never updated their block templates except when a block had been found. HashVault seemed to update every 120 seconds. xmrpool sometimes updated randomly. This set of histograms tells the story: https://rucknium.me/img/mining-pool-behavior-histogram.png
17:49:16 <Rucknium[m]> Thanks for making the update frequency configurable, jtgrassie 
17:49:42 <jtgrassie> "configured badly" is not the same as "misconfigured"
17:49:58 <jtgrassie> Rucknium[m]: most welcome
17:52:47 <Lovera[m]> Rucknium[m]: I’m curious what type of hardware do you need to run a pool like hashvault with 60 sec for example.  I think they get enough rewards to update their hardware if it is the problem 
17:52:50 <ofrnxmr[m]> Nano is 10s right now Lovera @btclovera:matrix.org: 
17:53:38 <ofrnxmr[m]> And the majority of the hashrate is 10-30s. Solo mining with daemon is 1s, xmrig is 15s (configurable)
17:53:42 <Rucknium[m]> The cost of having infrequent block template updates is pretty clear at this point. The cost is measured in lost pool revenue and worse Monero user experience. The computational cost (hardware infrastructure cost) of frequent updates is less clear. ideally, we would know the tradeoff to pick good defaults.
17:53:50 <Rucknium[m]> Anyone want to run some benchmarks?
17:56:18 <ofrnxmr[m]> I can probably run on mobile hardware - what do you need me to do?
17:57:58 <jtgrassie> the difference in mining revenue is negligable ~0.01 XMR per block
17:58:40 <Lovera[m]> <ofrnxmr[m]> "Nano is 10s right now Lovera @..." <- Good one 
17:59:23 <jtgrassie> empty block 0.6 XMR, block with 57 txs 0.613 XMR
17:59:32 <ofrnxmr[m]> The difference in time to confirmation is not
17:59:40 <Rucknium[m]> ...under current tx volume and exchange rate conditions.
18:00:24 <jtgrassie> "The difference in time to confirmation is not" agreed
18:00:29 <Lovera[m]> <Rucknium[m]> "Anyone want to run some benchmar..." <- If it’s easy to do, I can try it 😅
18:00:37 <Rucknium[m]> ofrnxmr: I don't know what a reasonable benchmark test would look like.
18:03:32 <plowsof11> if the big pools complain / switch back to 60 ~ 120 seconds , we'll know i guess
18:04:32 <jtgrassie> If the concern is UX (confirmation time), I'd prefer to see numbers of average confirmation time vs template referesh time
18:05:08 <jtgrassie> as I expect the difference between 60s updates and 10s updates is not that significant 
18:05:38 <jtgrassie> pool revenue difference almost certainly insignificant
18:05:46 <sech1> "empty block 0.6 XMR, block with 57 txs 0.613 XMR" <- that's 2% difference, a significant number if you compare to a typical pool fee
18:06:00 <jtgrassie> fair
18:06:36 <ofrnxmr[m]> 10s updates mean any tx that show up within 10s before the block are mined.
18:06:48 <sech1> pool that updates frequently and has 2% fee is better than a pool that mines empty blocks and has 1% fee (better for miners)
18:07:01 <ofrnxmr[m]> There is a 90+% difference between being mined by 120s vs 10s, in roughly 59% if cases 
18:07:10 <ofrnxmr[m]> 50%
18:07:29 <Rucknium[m]> I can try to run the numbers on what average time to first confirmation would look like for 10 sec update frequency vs 60 sec.
18:08:36 <ofrnxmr[m]> See if you can synthesize consistent incoming tx
18:08:36 <ofrnxmr[m]> spackle_xmr:  might be able to do this 
18:08:47 <Rucknium[m]> In my blog/Reddit post I did it for the actual observed confirmation times compared to a scenario when all pools had the average block update frequency as P2Pool
18:09:21 <jtgrassie> "that's 2% difference" <- not for every block, that's assuming the pool always mines empty blocks, which is not the case
18:10:19 <Rucknium[m]> I think I would just take the empirical arrival times of txs into the mempool and the empirical time of found blocks and then just "simulate" when txs would be confirmed if there was a 10 sec vs 60 sec lag.
18:13:59 <ofrnxmr[m]> Easy way to see the difference? 
18:14:27 <Rucknium[m]> ofrnxmr: Can you rephrase?
18:14:46 <ofrnxmr[m]> Run 2 instances of xmrig-proxy
18:14:46 <ofrnxmr[m]> One with 10s, one with 60s.
18:14:46 <ofrnxmr[m]> Keep track of the number of tx in the last update for each before a block is mined 
18:15:03 <jtgrassie> monte carlo simulation
18:15:14 <jtgrassie> would be quicker and easier
18:16:18 <Rucknium[m]> Yes. Monte Carlo would be easiest. Even easier than using the empirical data I collected over a month.
18:17:18 <Rucknium[m]> You would need to have the average tx volume to set the probability parameters on tx arrival. Besides that, no real external data needed.
18:18:11 <ofrnxmr[m]> Would Monte be as accurate as using real data in realtime 
18:18:50 <ofrnxmr[m]> I mean, things are always changing.
18:19:08 <ofrnxmr[m]> Historical data must be from after nano did the switch 
18:19:23 <ofrnxmr[m]> And tx volume and hashrate is all over the place 
18:19:26 <Rucknium[m]> Depends what you mean by "accurate". You'd need a large enough sample size with realtime data. I have a large sample of 1 month already, but I didn't literally run xmrig-proxy
18:19:48 <plowsof11> spamming testnet solves every problem
18:20:16 <ofrnxmr[m]> Oh
18:20:21 <ofrnxmr[m]> #no-wallet-left-behind:monero.social meeting
20:52:57 <Rucknium[m]> Preliminary results. I have not double-checked them. With the empirical data from December/January, if all pools were updating the block template every 10 seconds, then the average time between a tx entering the txpool and receiving 1 confirmation is 135.8 seconds (median is 98 seconds). If updating every 60 seconds, then the average confirmation delay is 208.5 seconds (median is 172 seconds).
20:55:01 <ofrnxmr[m]> What was the average blocktime during this period?
20:55:03 <Rucknium[m]> The Monte Carlo results are very similar. 10 second update frequency: 136.1 seconds average, 99.5 seconds median. 60 second update frequency: 208.2 seconds average, 172.6 seconds median.
20:56:08 <Rucknium[m]> ofrnxmr: 120.4 seconds
21:09:38 <xfedex[m]> i wonder why average time to get 1 confirmations with pools updating template every 10 seconds isn't (120+10)/2 = 65 seconds
21:12:17 <Rucknium[m]> xfedex: It's because hashing is a memoryless process. The average time to the next block is _always_ 120 seconds regardless of how long we have already waited. (Assuming no major changes in hashrate)
21:14:58 <Rucknium[m]> The PoW protocol for finding blocks can be modeled as a Poisson process. The time interval between blocks is a random exponential distribution. The number of blocks found within any particular time interval will have a Poisson distribution. 
21:15:53 <Rucknium[m]> This is a deep dive: https://arxiv.org/abs/1801.07447
21:16:01 <Rucknium[m]> "In the original Bitcoin paper, it was suggested that the blockchain arrivals occur according to a homogeneous Poisson process. Based on blockchain block arrival data and stochastic analysis of the block arrival process, we demonstrate that this is not the case."
21:16:31 <Rucknium[m]> When the paper says "this is not the case", they mean that it is not _exact_. But it's really pretty close.
21:18:10 <Rucknium[m]> To run the Monte Carlo simulation I calculated the average arrival rate of txs (this is just the transaction volume over a period of time) from the empirical data to get the rate parameter for an exponential distribution. Then I draw random exponential numbers to get the time between each simulated tx arriving.
21:18:53 <Rucknium[m]> I did something similar for blocks except I just set the mean arrival time to the target: 120 seconds.
21:20:36 <xfedex[m]> ahh, statistics
21:22:38 <Rucknium[m]> If one minute has passed since the last block was found, does that mean that the next block will be found sooner? No. The same is true if I roll the dice and don't get a royal flush (mixing metaphors). The fact that I didn't roll a royal flush before does not affect whether I get a royal flush on next roll. That's the same idea as with hashing. The hashing attempts are independent.
21:22:51 <Rucknium[m]> It's counter-intuitive, but true.
21:23:46 <Rucknium[m]> https://en.wikipedia.org/wiki/Poisson_point_process#Memoryless_property
21:27:17 <Rucknium[m]> Mean is not the same as median. Median time to next block with an exponential distribution is ln(2)/lambda. So ln(2)/(1/120) = 83 seconds
21:27:27 <xfedex[m]> my brain keeps telling me that when you submit a transaction at a random moment you will be in average halfway from the next block
21:28:13 <xfedex[m]> i might run a simulated blockchain to prove i'm wrong
21:29:31 <Rucknium[m]> Do it.
21:31:35 <Rucknium[m]> https://en.wikipedia.org/wiki/Gambler%27s_fallacy "The gambler's fallacy, also known as the Monte Carlo fallacy or the fallacy of the maturity of chances, is the incorrect belief that, if a particular event occurs more frequently than normal during the past, it is less likely to happen in the future (or vice versa), when it has otherwise been established that the probability of such events does not depend on what has happened in
21:31:35 <Rucknium[m]> the past."
21:33:31 <ofrnxmr[m]> ^ tip of my tongue. I thought Monte sounded familiar
21:35:48 <Rucknium[m]> So, when you are looking at mempool.space and see that the most recent BTC block was mined 25 minutes ago, do not think "Any second now, my BTC tx will be confirmed."
21:36:10 <Rucknium[m]> Think "Damn, still have to wait 10 minutes on average."
21:38:30 * chesterfield[m] uploaded an image: (141KiB) < https://libera.ems.host/_matrix/media/v3/download/faelix.im/GpeGJtXntHBwFgOACoXhJBRI/ima_5adf3ff.jpeg >
21:38:31 <chesterfield[m]> You’re wrong Rucknium 
21:49:10 <xfedex[m]> rucknium, simulations prove something very important
21:50:05 <xfedex[m]> you were right, after a tx is submitted it takes in average 120 seconds for it to be added in a block
21:50:44 <Rucknium[m]> That was a quick coding job. Nicely done.
21:52:59 <xfedex[m]> source code: https://paste.debian.net/1270624/
21:53:06 <xfedex[m]> plain javascript
22:54:42 <Lovera[m]> <Rucknium[m]> "So, when you are looking at..." <- This reminds me a little of Pieter Wuille’s pool about the average time of one block and the next picking a random point in time Everyone thought 10 minutes but the correct answer is 20. the expected  time between the previous and the next block is 20 minutes
22:54:49 * Lovera[m] uploaded an image: (278KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/HmGQQOCbTOlyiEenWXLWbKnt/ima_5f45cf5.jpeg >
22:55:08 <Lovera[m]> http://r6.ca/blog/20180225T160548Z.html