02:36:14 <DanIsnotthemanBr> anyone used allark.io?
02:58:05 <RavFX[m]> <DanIsnotthemanBr> "anyone used allark.io?" <- I did use it one time. It worked but I waited like half a day for the gift card (while other services usually deliver after like 10 confirmations
02:58:48 <RavFX[m]> They might have automated that by now, no idea
08:06:26 <NorrinRadd> RavFX[m] how recent was that?
12:18:33 <mrr[m]> XMR.Directory is now available through i2p https://xmr.directory/anonymity-and-security
12:21:55 <spacekitty420[m]> mrr[m]: would you see fit in a category "personnal shopper" type of thing? like, shopinbit having the concierge service for example then there's things like proxystore and such
12:25:01 <mrr[m]> spacekitty420[m]: Yes, I'll add a category for those kind of merchants. Although idk how I'll name it 
12:46:05 <ofrnxmr[m]> <mrr[m]> "Yes, I'll add a category for..." <- A cat-e-gory spacekitty420 @spacekitty420:matrix.org: 
14:54:46 <plowsof> i have a problem, i made a test proposal on the 'ccs' system assuming it was private and it says it's 'merged' can someone hand me the number for management to get this fixed?? or tell me what ccs even means https://ccs.getmonero.org/funding-required/ . It would be nice to see some ideas posted this week so they can be introduced/discussed this Saturday if needed (i know Siren Stnby have something planned) and some of our developers
14:54:46 <plowsof> are due for renewal too. 
14:56:17 <Siren[m]> Do you mean next Saturday?
14:56:48 <Siren[m]> Sure we can submit our proposal once we're done with the text
15:02:17 <plowsof> Where nearly all of us decided to push GUPAX to funding required.. is something holding it back? ofrnxmr? i know monerobull is a huge fan.. it has the updoots and overwhelmingly positive feedback from the community on Reddit and is linked by the p2pool creator in his repository .. whats going on here? 
15:04:23 <monerobull[m]> I am unable to follow this conversation
15:05:09 <plowsof> Sorry, its this one, the p2pool/xmrig gui : https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/350
15:05:25 <monerobull[m]> What about it? It should be merged yes
15:44:31 <ofrnxmr[m]> monerobull @monerobull:matrix.org:  my issue with gupax is that the stated hastate increase was 50% (7k vs 14k), which us far from the 2-15% of actual 
15:46:15 <monerobull[m]> to be honest, in my opinion this doesnt matter all that much. the main point is making mining as accessible as possible
15:46:25 <ofrnxmr[m]> Gupax is also requesting 14k over 2 months but has made no commitment to maintaining it past that point
15:48:04 <ofrnxmr[m]> My request of gupax was to cut the rate to 50xmr and maintain for 12 months. Why? We all know Hinto will have a ccs for version 2.0 in a few months.
15:48:34 <sech1> 50% is for the case when huge pages are not enabled for the embedded miner
15:49:00 <sech1> but even if  you run xmrig once, it enables huge pages system-wide and then it's 2-15%
15:49:23 <ofrnxmr[m]> And huge pages can ve enabled with a script, right? 
15:50:31 <plowsof> hinto is not lying about what he observed , i asked him to delete the entire % from the proposal as i and monerobull feel it has no effect on the 'creation of a gui for xmring/p2pool' proposal 
15:50:55 <monerobull[m]> ofrnxmr[m]: why, are they known for that?
15:51:20 <ofrnxmr[m]> Thats where bash stands right now monerobull @monerobull:matrix.org: 
15:51:41 <ofrnxmr[m]> First release was 15xmr and is incompatible with 2.0, and there is a ccs for 2.0
15:51:57 <RavFX[m]> <NorrinRadd> "RavFX how recent was that?" <- Early August
15:52:05 <ofrnxmr[m]> plowsof: He must be. 
15:52:24 <ofrnxmr[m]> As sech said, if he ran xmrig of the same device even once, those rates arent possible 
15:52:28 <plowsof> endor00 said he has observed the same jump in hashrate in the wild
15:52:43 <ofrnxmr[m]> hinto @hinto.janaiyo:matrix.org:  hate to talk about ya without an infuriation 
15:52:55 <ofrnxmr[m]> Invitation*
15:53:11 <ofrnxmr[m]> Endor said he observed noons that reported such. Nit that he observed it hinselfn
15:53:19 <ofrnxmr[m]> Noobs
15:53:21 <plowsof> and sech also shows where the 50% would have happened 
15:53:52 <ofrnxmr[m]> And enabling huge pages is a simple scriot.
15:54:13 <ofrnxmr[m]> Why would we pay 15k for a mining interface if the user doesnt know how to mine? 
15:55:08 <ofrnxmr[m]> Or worse, is inflating numbers hoping nobody says anything (nobody did)
15:57:02 <ofrnxmr[m]> Im not against a gui for xmrig, which is what this is. But as Hinto said, most previous ones are dead
15:57:33 <plowsof> there is no gui for xmrig and p2pool 
15:58:23 <ofrnxmr[m]> Again olowsof
15:58:30 <ofrnxmr[m]> The ccs implies the user will run gui
15:58:35 <ofrnxmr[m]> Monero gui*
15:58:44 <plowsof> i didn't even think twice when i seen tha %increase of using xmrig, i assumed 'xmrig is better than the built in miner' and anything over 1% is the reason to use it for people after profits 
15:59:12 <plowsof> the mining groups are all against using the built in miner etc 
15:59:13 <monerobull[m]> ofrnxmr[m]: thats exactly the point 
16:00:00 <ofrnxmr[m]> Those people are already running xmrig
16:00:01 <ofrnxmr[m]> and xmr isnt profitable to mine for people using home computers and guis
16:00:01 <monerobull[m]> people shouldnt need to know how to boostclock their cpu or some shit to get the best results with least effort
16:00:16 <ofrnxmr[m]> monerobull[m]: They dont
16:00:48 <plowsof> gupax will also come with tor.. and download the binaries and such using that... check for updates (automatic is also available)
16:00:48 <ofrnxmr[m]> The best results involve tuning your machine. Gupax gives results in line with using xmrig
16:00:48 <monerobull[m]> this is about decentralization and making p2pool the easiest place to mine to for people who want to mine xmr
16:01:07 <ofrnxmr[m]> Swapping xmrig for gupax at 15k is funny
16:01:07 <monerobull[m]> ok but people are scared of the terminal
16:01:09 <monerobull[m]> and configs
16:01:20 <plowsof> the selling point isnt that 'gupax' is a 'new monero asic miner'
16:01:33 <ofrnxmr[m]> If they already use gui, they already have access to p2pool
16:01:40 <ofrnxmr[m]> And again, im inbfavor of the ccs 
16:01:45 <monerobull[m]> you dont get it do you
16:01:49 <ofrnxmr[m]> But not as a 2 month 15k stint
16:02:13 <plowsof> then someone needs to make a competing proposal 
16:02:21 <monerobull[m]> ofrnxmr[m]: its too complicated. gupax is basically a one-click install and doesnt require local nodes for mining
16:02:43 <ofrnxmr[m]> How does that help decentraliAtion 
16:02:59 <plowsof> if its about rates , lets ask the atomic swap gui devs to put up a competing proposal
16:03:03 <ofrnxmr[m]> Anyway, my point is simple 
16:03:06 <monerobull[m]> because the easier it is to mine the more people will mine?
16:03:08 <plowsof> or haveno devs
16:03:11 <monerobull[m]> kek
16:03:17 <ofrnxmr[m]> Im asking for 12 months of support included in the ccs
16:03:43 <monerobull[m]> ofrnxmr[m]: make p2pool the easiest option for mining and people wont go to centralized pools
16:03:58 <plowsof> if hinto fucks us over , he's done, gone
16:04:23 <plowsof> more to lose than he has to gain
16:04:27 <monerobull[m]> 15k is a great deal for the program imop
16:04:40 <ofrnxmr[m]> Or are we ok with doing a ccs for 200xmr in 6 months for v2.0?
16:04:41 <sech1> 50% can also come from xmrig running better thread configuration/affinity
16:04:43 <ofrnxmr[m]> plowsof: Nobody has that power 
16:04:50 <sech1> of built-in miner running wrong number of threads
16:04:56 <sech1> it's highly dependent on CPU model
16:05:13 <ofrnxmr[m]> 1. 50 xmr for the 2 months
16:05:13 <ofrnxmr[m]> 2. 50 xmr the remaining 12
16:05:36 <ofrnxmr[m]> sech1: 5950x. Spackle tested and confirmed the 15%
16:06:34 <sech1> even if 15%, it's noticeable
16:06:52 <sech1> and the main point of that ccs is easy to use GUI, not speed increase
16:06:56 <plowsof> the maintenance will only be hotfixes/filename changes https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/350#note_19203
16:07:05 <monerobull[m]> there are way less useful proposals that get funded, for example plowsofs /s
16:07:35 <plowsof> why on earth am i the only one on the funding required page?
16:07:50 <sech1> GUI for P2Pool is definitely useful (no comments on asked payment from me, I haven't looked into it)
16:07:56 <ofrnxmr[m]> sech1: It was speed increase 
16:08:03 <monerobull[m]> plowsof: idk arent you supposed to handle that ;)
16:08:11 <plowsof> im trying 😭
16:08:38 <monerobull[m]> its not like we literally had a meeting where we agreed gupax should go to funding 
16:08:40 <ofrnxmr[m]> Bolded and italicised lololool screaming 50% in the first line
16:08:42 <ofrnxmr[m]> plowsof: Because
16:08:54 <sech1> ofrnxmr[m] speed increase shouldn't be the main point. Whatever, as long as it's a bit faster and has nice GUI, it's fine
16:09:16 <monerobull[m]> so arguing about the speed increase detail is kinda moot, especially when its nowhere near the focus of the proposal 
16:09:40 <ofrnxmr[m]> sech1:  I want promise if maintenance 
16:09:40 <ofrnxmr[m]> Not a comment saying maybe I will, maybe i wont  
16:09:56 <plowsof> maintenance = change filenames , so 0xmr for that 
16:10:16 <ofrnxmr[m]> Promise like, in the proposal. Not in the comment section
16:10:51 <plowsof> good point 
16:14:54 <plowsof> without maintenance/updates software is useless 
19:45:16 <DanIsnotthemanBr> Good luck if you become css co ordinator is all i can say
19:52:22 <ofrnxmr[m]> I just noticed Plowsof has moved to funding 🔥 https://ccs.getmonero.org/proposals/plowsof-com-rel.html
19:56:41 <DanIsnotthemanBr> I like the xmr value 😏
20:10:34 <ofrnxmr[m]> 69 🫶 
20:44:11 * gnuteardrops[m] uploaded an image: (262KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/wmvGJhwfSIDgHOqLLZoiYpUo/monero-trick-or-treat-1920x1080.png >
20:51:07 <gnuteardrops[m]> Freshly crafted background for you.
21:05:27 <luigi1112> ah monero moon
21:30:10 <ofrnxmr[m]> jeffro256: 
21:48:51 <k0b13[m]> Hi - I'm looking for a resource explaining how the activation mechanism for XMR's hard forks works. Anyone know of one? (sorry about the trivial question, but I can't seem to search this chat in Element and google isn't being very helpful either)
21:51:31 <ofrnxmr[m]> Two hard forks, 720 blocks apart, 24hr/720block window allows old and new transactions. After this, old tx are no longer supported. First fork enables new functionality, second fork disables old
21:53:01 <ofrnxmr[m]> Thats the eli5. A more technical answer will have to come from someone else
21:53:46 <k0b13[m]> Thanks! I'm specifically wondering how miners agree on the 720 number, and the block height at which the next fork occurs. 
21:54:43 <k0b13[m]> * fork occurs. Is it kind of like Bitcoin where miners signal support for the upgrade, and some threshold % of miners need to signal their support before it's locked in? Or is it some other mechanism.
21:55:11 <ofrnxmr[m]> The 720 number is written into the new daemon code. If you run the hard fork version, you "agree". If you dont, you remain on the old chain
21:57:03 <ofrnxmr[m]> No consensus is met until the hard fork block  
21:59:47 <ofrnxmr[m]> Its possible that 90% of the network does not upgrade and the majority of the network remains on the old chain. But doesnt happen because we all tend to agree or voice our disagreements throughout the development process. Exchanges, wallet makers etc are all contacted to ensure they update to the hard fork versions
22:06:37 <ofrnxmr[m]> Hard forks are necessary to implement some features. Like bp+ or ring size 16
22:06:50 <k0b13[m]> <ofrnxmr[m]> "Its possible that 90% of the..." <- OK, so is this roughly accurate: 1) consensus is reached during the development progress of a good block height for the next hard fork 2) xmr core devs add block height of next hard fork into a new release 3) because consensus is already reached, everyone upgrades to the new version well ahead of this block height 4) everything proceeds as planned i.e. as you described with the 720
22:06:50 <k0b13[m]> window, etc. 
22:07:49 <k0b13[m]> s/progress/process/
22:07:51 <ofrnxmr[m]> Except step 0) would be proposed changed that would force a hard fork
22:08:08 <ofrnxmr[m]> Like bp++ or seraphis
22:09:19 <k0b13[m]> Thanks so much. Quite incredible that something so decentralized can be upgraded so predictably with social consensus. 
22:12:40 <ofrnxmr[m]> Its because we love improvements. This latest hard fork has arguably 0 reason to use the previous version. Much more stable p2p network, much more stable tor nodes, faster wallet scanning, larger rings, network spam protections,
22:13:11 <ofrnxmr[m]> Only drawback: slightly larger 1in:2out tx at 1.42kb vs 1.5kb
22:21:01 <k0b13[m]> makes sense
22:21:02 <k0b13[m]> haven't hard "stable" and "tor" in the same sentence in a long time...
22:23:17 <jimmyt[m]> My conspiracy theory: NYM holders are behind the Tor DDoS so people make the switch to Nym and their token moons
22:24:53 <k0b13[m]> wow another privacy coin... I actually arrived at this question because I was looking into a (source code) fork of monero called Oxen and how they have "mandatory upgrades" for their PoS validators... could also be oxen DDoS'ing TOR :P
22:24:54 <k0b13[m]> * DDoS'ing TOR if you're wearing tinfoil :P
22:25:25 <k0b13[m]> * privacy coin... hadn't heard of NYM... I actually, * DDoS'ing TOR if you're wearing tinfoil :P
22:25:35 <DanIsnotthemanBr> Xmr or gfto 😎
22:35:25 <merope> <k0b13[m]> "Thanks! I'm specifically..." <- The reason behind the 720 blocks between the two forks is because the Monero network generates ~720 blocks in 24h (one block every 2 minutes), and nodes will discard any transaction older than 24h by default
22:36:58 <merope> So before the first fork you have transactions in the "old" format, and any such transaction still waiting to be mined after the first fork will still have a 24h "grace period" to get mined. Meanwhile, any new transaction made after the first fork will typically be in the new format, so they won't have any issues going through the second fork
22:38:37 <k0b13[m]> Must admin, I still have questions, but too many questions get annoying after a while so /shrug
22:38:40 <k0b13[m]> s/admin/admit/
22:39:08 <merope> This is also helps protect users making transactions during the forks: if we only had a single fork, then old transactions would have to be rejected immediately after the fork and users would need to create a new tx; but if they picked a different set of decoys the second time, they would end up revealing their true spend to anyone monitoring the tx pool
22:40:43 <merope> Feel free to ask - otherwise, what's the point of having these groups?
22:41:28 <k0b13[m]> merope: This clairvoyantly answered my remaining question - thanks! 
22:42:18 <merope> You're welcome :)