00:30:13 If I was a single miner, I would not create hundred of addresses though. What a pain to manage. >>> im not sure if th stats are per address or per connection 00:30:17 i think its honestly a mix 00:30:27 but i don't know 00:36:03 it was discussed in pools but I don't remember clearly, I believe for most pools it was by address but that still means numbers could be inflated by the minority of pools that don't 06:19:37 Most of the number increase comes from minexmr (surprise surprise) and they count by addresses 07:23:07 is this a case of the biggest pool attracting miners by force of gravity? 07:23:19 did minexmr raise their fee? I see it is higher than supportxmr. 07:50:02 It has always been higher 07:58:31 minexmr 986.27 MH/s, 44.7% 08:09:40 Is this the biggest unsolved issue in XMR? 08:18:16 minexmr should just stop accepting new XMR addresses to make noobs choose other pools 08:21:32 or just slowly raise fees 08:34:35 "When will 1 sat/byte clear again?" "Maybe March next year" "Why are you so bearish?" <-- Matt Odell etc discussing bitcoin fees. And recognizing that they are problematically high 08:52:06 but is he really recognizing it ? IMO he is also apologizing it instead of coming to the clue that BTC might be flawed 08:52:51 "is neccessary for the fee market to materialize, and will only climb from here on" 08:54:42 heh. and the conflict between a) consolidating UTXOs for cheaper fees later vs b) privacy 08:58:03 "I've had very expensive lessons - and those lessons where at 5 sats/byte" 09:22:53 <\x> even with a well thought out utxo consolidation, youll never achieve any hint of privacy 09:23:21 <\x> so yeaaah 09:36:14 no wonder people don't understand Moneros value proposition - when even the maxis just stick their heads in the sand. 09:37:04 <\x> it does help though, like proper coin control can help in like if you send someone small amounts, you dont need to use the largest utxo you have 12:03:48 minexmr is 37% if you do 916 mh / 2470 mh (network hashrate). the % of known is frustrating 12:12:23 20% unknown blocks 12:12:32 probably big solo miners 12:47:51 .usd 14:45:16 Miners 107730 15:00:14 I still 15:00:48 Think we need to raise funds via the CCS and pay for smaller pools to lower their fees or pay for larger pools to increase their fees 15:01:04 I would contribute to that 15:01:39 Or get xmrig to have stronger defaults in it that are smaller pools 15:10:32 xmrig defaults to hashvault IIRC 15:10:45 https://github.com/xmrig/xmrig/blob/master/scripts/pool_mine_example.cmd 15:11:50 https://xmrig.com/wizard sorts pools alphabetically and 2 largest pools don't stand out 15:12:07 Miners 108512 15:13:25 Ah interesting thanks. I more meant that it really pushes people harder one some direction or another. There is always potential to emphasize this stronger in the software but if you’ve already done all you can do then never mind :). What a gift that the project devs and the mining software maintainer are on such friendly terms! 15:13:49 I bet a lot of crypto can’t say that 17:00:09 i think we need to develop the pool delegate thing 17:03:25 Miners 109153 17:25:55 Gingeropolous: What pool delegate thing? 17:38:08 its kinda a hybrid between stratum-self-select and the existing stratum 17:38:30 so, you'd have: pool operator <---> bunch of pool delegates <---> miners. 17:38:53 pool delegates craft block templates. pool op just takes care of payments and tallying the delegates shares etc 18:02:47 So is it like delegate runs self-select but pool sends his template to other regular miners? And pool pays some % of the pool fee to the delegate? 18:03:52 I don't quite understand. Pool op still fully controls what normal miners do. 18:04:59 Or miners connect to delegates only? 18:05:00 delegate runs self-select, so they are the ones creating the blocks. The pool delegate is 1 of many delegates. Miners connect to the delegates to get their work. 18:05:25 But delegates create block templates with pool's wallet address, right? 18:05:28 the delegates coordinate with the pool op for payments and accounting of the other pool delegates 18:05:38 yeah 18:06:01 so each delegate gets a share of pool fee, depending how much hashrate he supplies? 18:06:50 yeah 18:06:51 Economic incentive for a delegate would be "run a stable fast node and get pool fee from miners in your geographic region" 18:06:53 interesting 18:07:01 yep 18:07:15 and the pool operator no longer has to pay for 90 thousand nodes to make sure the pool is stable 18:07:23 because the pool delegates are running that infrastructure now 18:07:26 Economic incentive for miners doesn't change 18:07:32 yep 18:07:53 ure just creating a middleman for the sake of decentralization and cost sharing 18:08:06 and leveraging the fact that some n% of miners cares about decentalization and will become delegates 18:08:10 but most don't 18:08:22 and also that pool ops are incentivized to minimize costs 18:08:59 But how do miners know address to connect to? From the pool getting started page? 18:09:19 yep. "Choose your delegate" 18:09:20 Or will pool maintain single connect address and just do geo-DNS? 18:09:27 well whatever 18:09:32 it could be random unless specificied 18:09:39 So pool op still has quite a lot of control 18:09:41 or delegates can compete by offering lower fees 18:09:53 He can just ban some delegates by not paying them 18:10:08 and removing them from all pages 18:10:12 right. 18:10:53 If it was possible to make your node a delegate in a few simple steps and get some $$$, many would do it 18:10:59 yep 18:11:45 so is it like reddit admins and subreddit admins system? 18:11:59 i mean, its kinda like p2p pool, except the nodes report to a master pool instead of using a trustless consensus between them 18:12:45 and this could go trustless somehow, but i think this hybrid approach is an easier first step 18:13:03 what about cheating? If some pool delegate reports higher hashrate than it really has? 18:13:05 i dunno about reddit admin subreddit admin structure, but ... yeah kinda 18:13:23 sech1, i tihnk that can all be taken care of using the existing protocol 18:13:38 or is it simply shared by blocks mined 18:13:39 the delegates submit "shares" to the pool admin 18:13:45 each delegate has their own wallet address 18:14:07 its kinda just a proxy system 18:15:08 ideally the delegates would do no more than provide block templates to miners and relay share information to the pool op 18:15:37 pool op assigns a wallet address to each delegate (which delegate can't control) and just pays out them out of "their" wallets 18:16:07 so cheating doesn't matter if only real mined blocks are counted for each delegate 18:17:58 right. a delegate would have a similar relationship to the pool op as any miner would 18:18:00 they are just special 18:18:31 except delegate's mining wallet (the one block templates are created from) is controlled by pool op 18:19:10 it would work in the same way that stratum-select works 18:19:56 its essentially stratum select between pool op and delegate, and standard stratum between miners <-> delegate <-> pool op, though it sorta passes through the delegate 18:20:38 i.e., the pool op would double check the work being provided to the delegate to confirm validity, in some manner thats more efficient than having 10k independent connections 18:21:43 Who checks shares from miners though? 18:22:10 the delegate and the pool op, or just the delegate 18:22:25 delegate can collude with "his" miners to report more shares 18:22:43 so pool op must check everything 18:23:00 sure, but could use the same trust model that exists today 18:23:12 the pool code checks the first n shares, and then assumes miner is trustworthy 18:23:17 Today's trust model is check 100% shares because accidents happened 18:23:22 ah 18:23:39 And servers that check shares are the bigger part of pool's expenses 18:24:28 checking shares can still be moved to delegates only if they are only paid from their mined blocks 18:24:38 then this problem moves to delegates and their miners 18:24:54 well, the idea was to have the benefits of the larger pool 18:24:57 for more frequent payouts 18:24:58 if some miner cheat, it's a problem only for other miners using this delegate, not everyone 18:25:19 so naturally delegates who check 100% shares will win the competition 18:25:36 i.e., all of the miners in the larger pool get a reward if delegate A finds a block 18:27:22 So pool op has to check all shares 18:27:39 Single EPYC server will probably be enough 18:28:03 50,000 miners, each miners sends a share every 30 seconds = 1667 shares/second 18:28:09 even single Ryzen server should be enough 18:28:36 so not a problem 18:29:18 and perhaps there are optimizations because all the shares come through a single connection 18:30:18 or it could be done where the delegate and the delegates miners get some n% of the reward, and the rest of the pool distrubutes the rest 18:30:39 so that the payout could come from the delegates wallet address, and there's a payout in that address to the pool op for further distribution 18:30:53 eh, maybe thats different 18:33:49 Snipa, how many servers is supportxmr up to? 18:36:33 but yeah. it'd be like changing a pool ops connection count from 11k to 100 18:37:06 or xnbya , how many servers are behind minexmr.com ? 21:17:32 We've been stable for awhile around the 20-30-ish range, I'd have to check how many are support and how many are frontend. 21:19:41 Technically, the delegate system is kind of a mess, we've discussed it in the past, but ran into the same issue sech1 described. You'd need a blind-trust/not-trust system, XNP got close with that, by essentially delegating the hard/small work downwards, but wasn't designed to handle payments on it's own, which is realistically the key, along with identifying something as a delegate so it can be issued a slice of pool fees. 21:23:11 The way sxmr/xmrpool are designed is with a psuedo delegate systgem, where the edge servers authenticate, it'd be perfectly practical to essentially issue an API key and check results, tracking payments as part of the returned data sets from the delegate node. 21:23:42 It's within tehcnical verification, but it's never been a particular goal of anyone to do.