00:03:24 You don't need to use the proxy 00:03:30 p2pool can handle multiple connections 00:03:36 ah 00:03:39 i guessed that 00:04:05 like it seemed useless to have xmrig-proxy and p2pool on the same server 00:04:13 thank you sech1! 04:13:47 Is the quibic-li client not open source? https://github.com/qubic-li/client 04:13:49 I see binaries but I do not see any source code. 04:13:51 (Trying to figure out if they are doing dynamic code execution or just shipping with xmrig) 04:16:21 it looks proprietary 04:16:53 you could do a strings on the exe file and see if they're using xmrig 04:17:14 i mean, if they are, it would be a violation of xmrig's license since they're not shipping the source code anywhere 04:24:14 Yeah. I got the bins. The alienminer seems to be another proprietary one. They have a hiveos config as well that is just doing another random bin install. I can setup a vm and tear it apart but I am pretty sure that they are just shipping xmrig with it 04:24:36 If they are not. Then the program is basically a RAT and just updates dynamic shellcode 04:25:18 Which I doubt they implemented. They probably just had xmrig hardcoded on there and then the parent pool can basically send the command to run the program 04:30:20 if they are shipping a modded version of xmrig 04:30:26 it is grounds for GPL violation 04:30:40 unless they uploaded the source code 04:31:29 There is no mention of it on the docs or anything like that 04:31:56 I am trying to follow the logic of the ai training part. But the xmr stuff seems to be hardcoded since there is no reference for the ai training stuff yet 04:33:14 It’s a scam coin, they are mining xmr and paying in worthless tokens 04:33:16 just finding mentions of xmrig inside the binaries are suspicious 04:33:32 you should go dig deeper in the binaries (after extracting them) to see 04:36:37 elongated: exactly, the miner program being proprietary is already a red flag 04:36:47 I was trying to figure out the mechanics of their xmr mining. They claim it is all done via their chain communication. which means you could bypass their greedy mining by snooping into their mempool basically. 04:36:48 and also tied to a centralized platform 04:36:49 Also if they are going with full dynamic exeuction then that means that pools basically have full RCE over miners. 04:36:51 Just trying to figure out the mechanics since they promise the sky and back but I don't see any source code. 04:36:53 Looks like a marketing stunt betting on not everyone cashing out the new tokens. Basically funding via rehypothecation with xmr as the payout currency 04:37:16 the client is proprietary and tied to their site 04:37:21 so it's not decentralized 04:37:39 btw, "full dynamic execution" is vague 04:38:06 for example, xmrig does full dynamic execution, it has a JIT engine that allocates a big code buffer to recompile RandomX code into the native CPU instruction set 04:38:35 of course, if they wanted to do RCE, they could tweak xmrig's JIT to have a little.. something special to it 04:38:55 without arousing suspicion 04:40:19 Yeah but xmrig is basically a vm. Their execution is basically done so as virtualization. This would be like they run xmrig in memory but I doubt it 04:40:44 xmrig is not a VM as i can see it 04:40:51 it's more closer to a video game console emulator 04:41:05 Based on their docs, the full computation would mean you run actual executable bins via in memory. 04:41:11 but for some CISC set 04:41:44 i mean, it'll be recompiled to instructions for the native CPU and executed 04:41:51 (nobody would mine in interpreter mode) 04:42:33 and so i'd think that they could make a modification to xmrig's JIT engine, to have an opportunity to sneak in custom x86 code 04:42:42 but not actually include it directly in xmrig's code 04:43:25 so virtual machine right? Not trying to split hairs but basically close to what something like the eth EVM would be. You just run itterations to then figure out the next inputs. But the actual binary that runs is native code. But the "virtual" code inside the calculations is running inside of that. It is not just executing into its own process. (Long day so language skills declin 04:43:27 ing. if it does not make sense) 04:43:50 yes 04:43:59 but xmrig likes to recompile the "virtual" code into native code 04:44:11 for a ton of extra performance 04:44:22 (also i realized i was retarded, so yeah randomX is kinda like a virtual machine) 04:44:49 xmrig actually executes the native code within its own process 04:44:52 I don't think they modified. They are just having their bins dump it as either a bundled embdedded exe or later on curl to get their version. But from their docs for them to have a full execution of ai training programs then that means their miners would be capable of executing new in memory shellcode right? 04:45:15 yes 04:45:39 they could allocate a big code buffer and download shit for their program straight into that 04:45:42 and execute off of the buffer 04:45:52 of that buffer* 04:46:04 Yeah xmrig is self contained. It is a really simple instruction set too so not really something with a huge attack surface for busting out of the thread. (Especially since you are just hashing at the end of the day). 04:46:22 yes, but i'm referring to the case if they modified xmrig 04:46:27 since the client is proprietary 04:46:34 Yeah so at best they are just including xmrig and at worse they are adding a shellcode loader into their miner 04:46:53 it's also important to note, xmrig is most commonly ran as root 04:47:07 because of its one-time init code (tbh xmrig should descalate after that) 04:47:41 I downloaded the bins I could find. I'll spin up some vms next week and then reverse them. I was curious what they did for them. Was late to the 51% drama 04:47:58 huge pages support too 04:48:12 all of those are done one-time 04:48:18 like setting up kernel parameters and MSR registers 04:48:31 xmrig can be ran as non-root if you do all of that yourself 04:50:04 they are not gonna reach 51% and push people to run their literal virus lol 04:50:07 to mine XMR 04:50:10 Ok yeah I see they give instructions for huge pages an non root since their docs mention that the miner can download and exec runners which are apps 04:51:50 i like how cfb is saying their crappy shitcoin is decentralized 04:51:59 a decentralized shitcoin where you have to register for an account on their site 04:52:06 and mine with a proprietary executable 04:52:12 "decentralized" 05:02:32 Yeah I'll dig through these bins next week 10:34:17 https://matrix.monero.social/_matrix/media/v1/download/monero.social/suMbDNRevgRqVGDUoXlagfTV 10:34:20 Yo, check out the new Monfluo wallet design. 11:01:45 I like 11:35:30 anyone knows if this qubic shit is resolved or are they still trying to sabotage xmr? 11:45:04 resolved? why is there a problem? 11:48:16 okey well maybe "problem" isn't the right term here. but is this something serious? i see conflicting information everywhere (some lose their mind, some say it's just propaganda) and cannot make up my mind about whether this is legit or some made up bs 11:49:21 qubic is a paper tiger 11:49:24 it's mostly FUD 11:49:41 they're trying to pretend they'll get 51% but they won't get shit 11:54:29 Have an eye on this, as somebody said so spot-on recently "blocks don't lie": https://moneroconsensus.info/ 11:55:04 In a few minutes they will switch from mining Monero 50% of the time to mine 100%, for 24 hours. 11:56:57 Also check the red "piece of cacke" labelled "unknown" here, scroll a bit down beyond the list of pools: https://miningpoolstats.stream/monero 11:57:04 *piece of cake 11:57:48 "unknown" is, give or take a few percents, most probably the Qubic "miners" 11:58:20 but it probably includes some not-yet-listed pools or solo miners 11:59:13 rbrunner: on miningpoolstats are you referencing qubic dot org? 11:59:18 api error 11:59:31 No, the round graph just below that 11:59:50 Over the last 1000 blocks 12:00:06 Cindy: Well, yes, that's why it's called "unknown". 12:00:14 A year ago it was 2%: https://web.archive.org/web/20240607022708/https://miningpoolstats.stream/monero 12:01:04 Who is mining empty blocks ? What was % of empty blocks before cubic shit 12:01:17 for moneroconsensus , they added ~9 pools yesterday 12:01:30 The assumption is that's Qubic 12:01:36 with the empty blocks 12:02:06 unless there are 2 blocks very close together it is qubeic 12:02:12 So only 9 blocks mined by them 🤡 12:02:25 Over which time? 12:02:45 yesterday they had 3 or 4 in a row sometimes 12:02:49 Over say a month before cubic started mining empty blocks ? 12:03:43 Make of it what you like, but the Qubic fans, on their discord server, trust the "pool hashrate" display on the left side here: https://explorer.jetskipool.ai/xmr-tracker.html 12:03:48 I was thinking, we should not publicly react to it anymore, just ignore those fools, the twitter beef is half the fun for them 12:04:35 tweeter? IRC is my social media lol 12:04:46 this will be a nothingburger 12:04:51 I don't see any problem in studying them like we would any other technical or operational problem regarding Monero, calmly and reasonably 12:05:00 yes 12:05:08 but the problem is interesting 12:05:20 rbunner, I agree 12:05:27 rbrunner, I agree 12:05:52 Just ignore them. They need hype, they need publicity. Don't give it to them. 12:05:57 With 2 GH/s they would be the biggest Monero pool right now. 12:06:15 They don't have enough hashrate, and don't worry, we are working behind the scenes. Just can't go public with anything right now. 12:06:21 qubic fans will throw the biggest fit when they realize that it was just a pyramid scheme 12:06:32 and cfb will run away with the mined XMR lol 12:07:25 What do we think of tevadors solution to make centralised pools (prohibitively?) expensive by increasing the bandwidth requirements from 1MB to 3GB a day per miner (pls confirm actual figures) https://github.com/monero-project/research-lab/issues/136#issuecomment-3170565603 12:07:57 Essentially pushing people toward p2pool mining 12:08:17 3GB a day per miner would DDoS the biggest pools 12:08:29 so that sounds like a pretty good idea 12:08:43 I do not have a problem with centralised mining pools per se, but it is worrying that most miners flock to the biggest pools 12:09:33 you need to be able to attract miners that are technically unskilled, as to increase the potential pool of miners, imho 12:10:17 thx plowsof , I hadn't seen that b4 12:10:27 I just fell off my chair. tevador posted 2 hours ago. Wow, quite a relief. 12:14:33 i wonder how the 3GB will affect small mining pools (LAN-only with a bunch of computers) 12:16:38 would it be possible to devise a mechanism where it gets more difficult for centralized pools only when they reach 5 or 10 % of the total hashrate? 12:18:29 p2pool is great except for the many small payouts you get which will then need to be consolidated 12:18:30 i wonder about modifying RandomX to include ed25519 signatures in the algorithm 12:18:48 of course this is "miners signing their own block" which i don't know works 12:19:03 but a local mining pool could just provide all of its own computers with the key 12:19:21 while a centralized online pool would have to devise a mechanism to sign data for miners 12:21:28 how would this affect p2pool? 13:55:05 btw, does xmrig support mTLS auth in its API service? 13:56:07 i mean if the service only supports tokens then i'm fine with locking it behind a HTTP forwarder that provides mTLS auth 14:40:06 Huh, 17 hours mining Nano on P2Pool at 9kH/s, and no Monero... 14:40:23 That sucks dude. 14:40:47 try mini 14:40:49 Maybe I should switch to Main? 14:41:02 i mined mini with my crappy laptop at 4KH/s 14:41:07 and i got atleast some payouts 14:42:59 28 shares accepted... whatever that means. 14:43:17 shares in p2pool or xmrig?? 14:45:12 xmrig. 14:45:29 12 in p2pool. 14:45:51 p2pool likes to break challenges up into pieces for xmrig 14:46:01 so i shouldn't rely on xmrig's "shares accepted" thing only 14:46:09 I see. 14:46:12 into easier-to-solve pieces* 14:47:40 "Payouts 0.0000000/month" 14:48:16 Eh, 'thank you'. 14:48:17 p2pool-nano needs to find a block to pay you. It's all in the README 14:48:35 switch to p2pool-mini to get payouts more often 14:49:06 How about Main? I don't mind waiting for larger payouts. 14:49:25 24/7 14:49:27 main, you'll get crushed by other computers with 1000x more hashrate 14:49:34 mini is a equlibrum 14:49:46 Ah 14:52:02 9KH/s is more than enough for mini 14:52:08 i don't know why you're mining in nano 14:52:53 It's the default for Gupaxx. 14:53:34 ... but I've stopped p2pool in Gupaxx, and the ability to choose which sidechain is still grayed-out. 14:54:26 Oh, I've cleared the Options and now can choose. 14:55:13 i thought the default was mini 14:56:27 I haven't messed with that 'till now. 14:57:29 I've hit Clear on Options, whereas before I used Advanced. Now I have settable Options. 15:04:02 ... except p2pool and xvb are now staying orange, not going to green. 15:07:57 does xmrig have mTLS auth for its API? 15:09:10 In Gupaxx there's a TLS checkbox in xmrig. 15:09:30 that's for the pool server 15:09:39 i meant if xmrig is hosting a HTTP API server 17:29:04 Cindy, do you know whether anything writes to the blockchain, other than monerod? 17:30:02 IOW I want to run two VMs and have them share one disk with the bc. 17:30:03 i think its just monerod? 17:30:20 run monerod in a seperate server 17:31:03 I wasgoing to run monerod in one VM and not in the other, but they both need the ports it has. 17:31:20 why are you running two VMs 17:31:45 I could forward those ports as long as they're TCP and not UDP. 17:31:55 like why two VMs in the same PC 17:32:16 Cuz he's quantum computing 17:32:24 all you're doing is adding additional overhead 17:32:30 and killing your overall hashrate more :P 17:32:40 I'm pinning CPUs separately. I've found that when I run 55 threads in one VM hashrate crashes. 17:33:02 why are you running 55 threads 17:33:05 Throttle it back to 24 CPUs or so and I max around 9200. 17:33:18 why are you RUNNING 9200 THREADS?!?! 17:33:30 So I'm splitting those threads into two VMs. 17:33:45 Nah, 9200H/s 17:33:51 ah 17:33:57 ... 2ith 24 CPUs 17:34:30 i doubt you're gonna get any performance with this 17:34:35 Are you usong cpus and threads onterchangeably 17:34:38 you're just adding more burden with the VM engine 17:34:53 Cindy, he's not looking for performance, he's looking for a long-term hobby 17:34:56 55 threads in 24 CPUs would obviously kill your hashrate 17:35:00 because like 17:35:04 I'm using cpus and threads onterchangeably 17:35:08 at some point, the kernel scheduler kicks in 17:35:17 ofrnxmr: oh really? 17:35:57 Well 9200H/s is the best I've ever done. In testing as I increase threads H/s drops off. It's the algo. 17:36:03 Seems like it. Lol. This seems like what happens when someone has too much time on their hands. Its not this (weeks) difficulty to mine monero 17:36:15 when you increase threads beyond the cores 17:36:25 your kernel has to juggle threads around the cores 17:36:46 which will be more overhead 17:36:51 Sure, this is why I'm matching threads to CPU threads. 17:37:27 ... and testing shows that over a certain number of CPU threads performance drops dramatically. 17:37:42 also seriously, move the blockchain outside the VM 17:37:55 So I am splitting CPU threads between VMs. Problem is sharing the blockchai and monerod ports. 17:38:05 remember that even if the CPU is being passed through, the hard drive is obviously emulated 17:38:13 so youll gain a little by moving it outside the VMs 17:39:05 The bc drive is in my file server, and is pulled in to the VM. But I can't have two monerod's writing to one BC. 17:39:14 wait 17:39:23 you're remotely mounting the blockchain on some file server 17:39:29 and monerod is using it like that? 17:39:30 Yep 17:40:00 honestly that would be even worse performance than a physical HDD 17:40:02 KVM VMs. 17:40:16 It is a rotating drive. 17:40:32 oh wow, a combo :P 17:41:05 sorry for dunking on you a lot lol 17:41:12 but this setup seems way too overcomplicated 17:41:19 Yay. Is 9,200H/s bad for28 CPU threads? 17:41:24 and adding more burden to your miner 17:41:31 Best I've ever done. 17:42:02 28 threads in one VM and 28 in t'other. 17:42:19 I just have to share monerod somehow. 17:42:51 host monerod outside this mess? 17:42:54 This would double my performance over one VM. 17:43:09 And forward ports? 17:43:16 yes 17:43:20 also lol "double my performance" 17:43:28 bro discovered infinite CPU power glitch 17:43:34 just host more VMs 17:43:49 9 kh/s for 28 CPU is really bad 17:44:00 Well I'm out of CPU threads to pin now, with 2 VMs. 17:44:15 yes 17:44:18 eddie is right 17:44:21 You should be able to do 25 or more 17:44:27 even my crappy laptop with 4 cores and 4 GB of RAM 17:44:27 O 17:44:32 can still get more than half of that 17:44:46 Huh... 17:44:51 the problem is the amount of overhead you're adding on this 17:44:53 I do 4 on 8 cores 17:45:00 It hardly hits my disk. 17:45:13 And that's just for giggles 17:45:40 but i discovered today that like 17:45:45 i can get unlimited hashrate if i host more VMs 17:46:06 (You're welcome) 17:46:21 yay 17:46:29 CPU cores are passed directly through. 17:47:06 Need to check my host load, before and after.. 17:47:14 what about your blockchain 17:48:59 That disk is hardly hit while hashing. 17:49:11 I guess monerod updating. 17:51:03 Hm, if I run monerod in one VM, I don't need the disk in the other VM. Just monerod's ports. Hope they're all TCP. 17:52:56 ... but on the host I can't differentiat between the qemu-system-86' between my herd of VMs... 17:53:22 is this all for security? :P 17:54:37 Yes 17:54:54 if i were you, i'd host monerod on a seperate machine 17:55:01 Ok monerod is indeed all TCP, 18080-3 17:55:04 flash linux and put xmrig on a flash drive 17:55:15 disconnect the hard drive off the computer and boot off of the flash drive 17:55:39 and i'd get 4x the hashrate with the same amount of security 17:55:45 This is my Big Bad Server wih copious cores. 17:57:14 I do have an ODroid I could host monerod on, but I don't see the point. The disk is hardly hit. 17:57:55 are you mining off of a remote node? 17:58:01 It's the raw horsepower I bought this server for, specifically monero. 17:58:02 you should check what node you're mining off of 17:58:23 like "hardly hit disk" is suspicious 17:58:31 Running Gupaxx. Should be p2pool. 17:58:41 iotop 17:58:44 check the p2pool tab 17:58:46 in gupaxx 17:59:51 Ok the VM's been down a bit so needs to sync up. 18:00:08 iotop shows the bc disk is hardly hit. 18:00:44 Had to copy the qcow2 for the second VM. 18:01:01 (and pin diff CPU cores) 18:01:35 I am doing New Science, you see. 18:04:51 Maybe 'burntcorpse' will pop in. (Hopefully someone will open a window if he does) 18:05:31 Ok p2pool is syncing now. 18:08:05 " I do 4 on 8 cores" That's freakin' 500H/s per core. Unbelievable. 18:09:55 the most amount of security i'd be doing is doing all the configuration myself, running xmrig as non-root 18:10:04 maybe even running xmrig in a seperate linux namespace 18:13:20 You're suspicious that KVM is a ottleneck. It's now clear which qemu-system-x86 on the host is altcoin1 VM. 2,797% CPU for 28 cores. 99.8928571429% util. 18:14:04 I seem to be maxing my CPUs. 18:14:23 Idk where else a problem could be. 18:14:55 even if you're passing through the CPU, a system is a lot more than just the CPU 18:15:02 so KVM is emulating the other stuff 18:15:34 and it does that through software traps, stuff that cuts into the CPU performance 18:16:15 Those numbers on the host. On the guest 2,780% usage. Maybe the diff is overhead. 18:17:07 I don't believe 500H/s per CPU. 18:19:05 Just running top on host and guest cuts to 5,500H/s. 18:22:08 Well, stopping top on both I'm still at 5,600H/s. Must be the difficulty. 18:23:24 lol 18:26:47 I was at 9,200+ 18:49:45 My daemon reorganized 5 times in the last 1.5 hours. 18:54:59 Just did No 6 :) 18:56:45 yep 6 here 18:58:34 last one was one of 6 consecutive empty blocks 19:01:24 I am sure that the "paper tiger" Cindy wrote about this morning UTC :) 19:01:38 oh wow! 19:01:50 6 empty blocks? :o 19:03:32 6 reorgs in 1.5 hours and 6 empty blocks happens every other week, right? :) 19:04:02 rbrunner you don't have to call me out like this :P 19:06:38 are they really mining empty blocks right now? 19:06:38 I looked at renting hashpower, only $500 for enough power to on avg find a block 19:07:02 all the blocks they mine for several days now are empty 19:08:08 what are they trying to achieve with that :P 19:08:12 slowing down transactions? 19:08:25 publicity 19:09:01 i see 19:09:38 made me turn on my rigs in the summer lol 19:09:49 i mean, honestly 19:09:57 weather has been ok so 19:10:11 CFB is just trying to do this for clout, but i wonder if the EU or other governments that are trying to ban monero will jump in on this too 19:10:30 like harness tons of computers for the purpose of attempting to sabotage monero 19:11:42 * nioc powers up a shitbox 19:12:15 isn't that just a litterbox? 19:12:28 there are many types lol 19:12:36 including my car 19:12:45 Your IoT litterbox can mine Monero, too :D 19:13:08 automated litterboxs are a bad idea 19:13:24 you need to observe the output 19:13:31 wasn't there that uhh 19:13:35 automated cat box from china 19:13:43 that literally killed cats 19:14:00 like crushed their necks with the (very powerful) window motors 19:20:50 hey guys 19:20:59 i doubt this is the first 51% attack attempt on monero btw 19:21:17 is there an amazon like shop to buy stuff for xmr? 19:21:39 hello Cind 19:22:12 hi Guess65 19:22:17 Guess65: There have been multiple outfits setup for that, but they closed probably because not enough customers. Check out xmrbazaar.com 19:30:52 how come there arent enough customers? 19:30:55 wonders 19:45:51 Ok I have one monerod and blockchain present in two VMs. 19:51:17 SB #1 online 20:04:06 And she laughs because I am trying something new... 20:32:14 ofrnAI: Check my DM thx 20:57:10 shitbox #2 online 23:14:49 Are these reorgs actually happening? And if so, should I start thinking about how I can do a 0 conf scam on someone? 23:20:32 midipoet: you can't do that because: 23:20:33 1) You would have to send a contradictory tx that spends to yourself to the Qubic pool, which doesn't accept direct tx submission AFAIK. 23:20:35 2) Qubic is mining blocks devoid of any txs anyway, so it would not mine any contradictory txs. 23:20:56 But yes a few orphans are happening: https://moneroconsensus.info/ 23:21:16 You would see this in the default log level of a Monero node, too. 23:32:27 Your first tx to the victim would stay in the txpool, waiting to be mined by honest miners. You would still be sending them the money, just maybe a few minutes later.