00:10:20 P2pool brings no incentive against large ops, it just allows miners (any miners) who use it to pool their effort without having to trust anyone 00:11:23 A large mining farm could just as easily move to p2pool - hell, it would even be safer, because they would be fully in control of all their mining infrastructure 00:12:30 As for the cost of the hardware, that comes into view only after profitability 00:13:28 If your profitability is < 0, it doesn't matter if you're running a 10$ cpu you bought at the flea market or a 10k$ asic - you're still losing money 00:20:44 Although the low "barrier of entry" cost of cpu mining is definitely a contributing factor to the low profitability 01:51:53 merope: P2Pool to some degree should disincentivize those who would otherwise seek majority control through centralized pools, and eventually make it easier for those who are not large operations to mine profitably which reduces the benefits gained by larger operations, thus shifting their incentives toward mining on other blockchains. 01:53:14 (easier to mine profitably for small-time miners because P2Pool will likely become more standardized and have a clearer, more automated start-up process, and because it's more likely to be predictably profitable than solo mining) 01:53:50 17:12 < merope> As for the cost of the hardware, that comes into view only after profitability 01:54:29 Profitability is always the same, regardless of the pool size 01:54:33 The point of my comment about hardware cost is that more *small miners can actually afford the hardware*, which already means more competition against potential large operations. 01:54:49 And once you own a significant chunk of hashrate, solo mining is reliable enough 01:54:59 I think you've got some hyperfocus on the wrong parts of what I'm saying. 01:55:03 18:54 < merope> Profitability is always the same, regardless of the pool size 01:55:07 This doesn't dispute anything I said. 01:55:34 18:54 < merope> And once you own a significant chunk of hashrate, solo mining is reliable enough 01:55:46 This doesn't address why I mentioned reliable profits for *small miners*. 01:56:01 Never mind. 03:09:18 hi.. im trying to bench my hashrate on xmrig. the bench works in cpu mode, however, when trying to bench with CUDA enabled, i get this error "[127.0.0.1:18081] error: "Core is busy", code: -9" (this is my local node launched).. does anyone know why? using this command (or some variants): sudo ./xmrig --bench --no-cpu --cuda 03:09:18 --cuda-loader=/home/mmellow/Downloads/xmrig-6.16.4/libxmrig-cuda.so 03:30:50 marshmellow[m]: is your node synced? 05:14:02 "marshmellow: is your node synced..." <- no it's in progress. Is that why? I figured the CUDA benchmark would work because the cpu benchmark worked even though it's not synced 05:14:44 I don't know, but I would try to sync up first. 16:40:42 what is wrong with this monero. Its totaly useless. Why i say that i will describe. Think you have 1 wallet for all your users. These all users are using sub-addresses. Then! If one of user withdraw then all other users must wait 10 blocks for get unlocked their money. Second option: create a new wallet for all users. Then second problem occurs: 1 wallet file = 16MB !! Then what? 16:48:03 If users have a balance they can withdraw, then maybe use an account per user. If that matches what you want, hten what's wrong is just you not using the right tool for the job. 16:49:57 Now, if users can transfer value between each other off chain, that won't work well. 16:50:29 Then your best bet is probably a single wallet, subaddresses, and setting up min-outputs-* to not merge if it does not need to. 16:51:09 And not having a single tx per withdraw if your users withdraw at the same time. 16:51:51 NakedKing, once you understand what's going on it's pretty easy. 16:52:47 I've seperated wallet with accounts. Nothing changed. It's still in interacting.. 16:53:03 If someone get withdraw, others needs to wait? How can it be correct way 16:55:25 moneromooo, what is mean of "setting up min-outputs-*" and "not having a single tx per withdraw" . Will these solve my problem? Can you describe more with examples if possible, please 17:25:12 For an extreme to test, set min-outputs-value to 0.00000000001 and min-outputs-count to 100000. 17:25:40 And if more than one person wants to withdraw, send to them in a single tx (up to 15 recipients). 17:26:10 Though that'll work only if you're using a single account. 17:42:41 Why is this concept so hard to grasp? 17:43:11 Maybe because there's nothing easy to find explaining it. 21:59:42 Is this all to avoid the 10 block lock time? Might be worth making an Outreach article about it if it’s a common issue