06:27:21 552452 KB yesterday, now 567816 KB. p2pool has a nunmber of preallocated buffers that can grow with time, so it's not 100% conclusive that there are leaks 07:22:38 hey 07:23:05 i'm pretty excited about the p2pool launch 07:23:47 I was just talking to a friend the other day about ways to make it so solo mining is actually worth it and then he found the reddit thread a couple days later 07:24:06 What was the reason this has not happened on BTC? 07:26:31 i'm not really sure 07:27:07 I think I saw some explanation for it, but can't remember what it was. 07:27:20 as it seems to be an excellent way to decentralize mining 07:28:12 it does, and there is a ton of potential for real-time web monetization if we can cut out the middle man (pools) now 07:28:58 like you could make users generate X number of hash per bytes of data transferred 07:29:13 and mine it directly to your p2pool 07:29:19 node 07:35:51 i don't think a lot of people realize how game changing this can be, especially if we find something to replace javascript miners and make it so hashpower can be used to replace payments 07:40:59 I think the short of it is that p2pool is best suited for coins that are not already dominated by ASICs… since any big ASIC miner will run their own pool anyway 07:41:56 that's a good point, I figured it had something to do with ASIC resistance 07:42:04 speaking of ASICs, remember Linzhi 1400 MH/s ETH miner? They promoted it a lot and went silent. Now it turns out, they decided to not sell it and are mining themselves... 07:42:32 This is the essence of ASIC mining. 07:43:11 yes, p2pool is best suited for small miners, so only CPU/GPU mined coins benefit from it 07:43:32 lol market started heating up so they decided to ride the wave 07:44:18 I updated the code to reduce log spam. Moved some most useless messages to log level 6 (log level 5 is default) 07:55:19 "BlockCache couldn't open p2pool.cache, error 5", the file is there 07:56:17 Windows? 07:56:28 yes 07:56:36 error 5 = access denied 07:56:45 do you have write access in that folder? 07:57:22 or maybe you're already running p2pool instance that opened this file 07:58:12 it was running fine, i just updated and ran it again 07:58:27 kill task 07:59:30 it's not a critical error, it can run without cache 08:00:10 My Windows node doesn't have this problem and I restart it a lot 08:03:30 seems good now, after a closed the terminal, maybe it was still running 08:24:33 Hey! If I understand this correctly - p2pool is a separate thing from monero, right? Like it doesn't affect the network as it is now? And I'm curious about one thing - if there will be a malicious p2pool binary, what's the worst thing it can do? Can it skip payment to all the miners and just take everything for themselves, while still mining in p2pool? 08:26:04 And what will happen if I won't reach `0.0005` XMR in the payout window? Because I'm quite sure that it will happen in case when everybody abandon pool mining and switch to p2pool 08:27:27 p2pool is separate, it doesn't require hardfork to work, but it will require point release of Monero 08:27:53 no, it can't skip payment to other miners because other nodes will not accept such block 08:28:42 if you don't have shares in the payout window, you will not be paid when p2pool finds a block. But when you eventually find 1 share and p2pool finds a block after that, you'll get paid 0.0005 XMR 08:29:17 so low hashrate miners will have payouts every few days, but it will be the "whole" 0.0005 XMR at once 08:29:30 assuming that p2pool grows to 30 MH/s or more 08:31:48 if p2pool is 100 MH/s with 10 seconds block time and you're a 500 h/s laptop miner, you'll be finding pool share every ~23 days and then get a 0.0005 XMR payout (maybe more than 1 if the pool is lucky) 08:32:15 this is like the worst case for a small miner, still much better than solo mining 08:36:56 the worst thing a malicious miner could do? Probably withholding mined Monero blocks (attacker still can't take the reward, only withhold it from everyone). This will hurt pool profitability, but it won't gain the attacker any profit 08:37:15 Monero blocks mined by attacker I mean 08:37:31 but the same attack can be done with regular pools 08:38:52 Ah cool, so that sounds like solo mining v2 to me 10:25:58 solo mining with closer to "pool like" payouts 10:56:11 Would it be accurate or inaccurate to say that RandomX uses less energy than ASICs? (Apart from the silicon waste) 10:56:20 Context: https://github.com/monero-project/monero-site/pull/1772#discussion_r693960265 10:56:37 in some sense yes 10:56:52 many of PCs mining Monero would otherwise be just idling and consuming power doing that 11:00:29 But similarly ASICs are more efficient in regards to hashes / watt. 11:00:50 hashes/watt is completely irrelevant 11:01:07 Why? 11:01:33 because it isn't interesting how many hashes you producs. What is interesting is how much energy is used to secure the chain 11:01:42 producs = produce 11:02:38 Yes, that's what I wrote in the linked comment. 11:02:56 But inside the same algorithm hashes / watt is relevant for energy efficiency. 11:03:39 except that it doesn't really matter, as the spent energy will increase until a new quilibrium of power cost vs block reward is reached 11:03:47 equilibrium* 11:06:29 I might have found what's leaking: P2PServer failed to initiate tcp connection, error EMFILE 11:06:46 Also: P2PServer failed to save peer list 11:06:56 And it's not EIO/ENOSPC. 11:08:08 Loads of shite in /proc/PID/fd, they're sockets. netstat does not show anything out of the ordinary. 11:08:40 good catch 11:08:59 I'm still on the commit hash where you added the build documentation. 11:09:07 so you hit max open descriptors limit? 11:09:16 That's what EMFILE says. 11:09:58 ls /proc/PID|fd | wc -l says 1025, ulimit -n says 1024. 11:12:07 ls /proc/47710/fd | wc -l says 181 for me and it's been running non-stop for more than 24 hours 11:12:12 still, 181 is a bit high 11:12:54 I'll keep an eye on this number 11:13:21 For the record, I have these changes too: https://paste.debian.net/hidden/bce87af9/ 11:13:44 I'll pull latest now and run with that, alright ? 11:14:01 it's better to get latest and run with --light-mode 11:14:03 Unless you want me to run stats/commands ? 11:14:12 I am also running with --light-mode. 11:14:15 I fixed a few thread races in latest 11:14:21 maybe leaks were because of them 11:16:17 https://paste.debian.net/hidden/12f5f14e/ is a good fix for the libs. 11:27:31 updated and restarted my node, now ls /proc/PID|fd | wc -l says 45 11:31:37 yes, it looks like this number grows every time I disconnect and reconnect to my node 11:47:30 so it's accumulating p2p sockets? 12:01:57 looks like it 12:02:11 I call uv_close() on them, not sure what's wrong 12:05:43 if I kill local xmrig, stratum disconnects it and I see the fd number go down by 1 12:06:15 stratum and p2p both use the same code 12:10:04 every time you see "peer ... disconnected" in the log, it's from uv_close() callback so it was successfull 12:10:14 It's going up and I've not killed xmrig yet. It was 59 shortly after startup (started less than an hour ago), now at 97. 12:34:11 I think I found a workaround, but it's ugly 12:34:48 libuv doesn't close the socket in uv_close() callback for some reason, so I just kill it with https://linux.die.net/man/3/close 12:35:21 Maybe waiting for shutdown first. 12:36:19 doesn't work, p2pool crashes with this force close 12:40:21 so maybe it close it much later, after TCP timeout or something 12:40:25 *closes 12:51:00 moneromoooo can you try https://paste.debian.net/hidden/b943586c/ ? It helped me 12:54:10 definitely works here, so I committed it 12:56:06 Restarting still gets me the "not enough data to verify" spam. 12:56:27 (I was running the version with the cache before the restart too) 12:56:30 I should probably rephrase that message 12:56:49 it means it can't verify the block right away and needs to download its parent/uncles 12:57:21 cache works through the same "download block from remote peer" code path, so you still get it 13:02:15 pushed it, now you'll have less spam at startup 13:12:01 running latest on my server now. For the reference: RES = 374456 KB, fd = 49 13:12:13 we'll see in a few hours 13:13:22 Still slowly increasing. 13:13:44 From 40 right after staring to 55 now. 13:23:18 51 here 13:23:27 these are probably legit sockets 13:26:18 64 13:29:29 still 51 13:29:36 not sure what else can be done there 13:29:48 I see the number go down when I disconnect from the server 14:05:02 I just restarted with latest too, res 556M 14:05:24 I have fd = 62, went up a bit 14:05:54 lsof -p PID | grep TCP shows a few dangling sockets, not sure how they appeared 14:07:58 ugh I've got over 100 dangling sockets 14:08:05 lemme do another pull 14:09:48 your connection has been flaky the whole time 14:10:03 I still get lots of ECONNRESET from you 14:10:36 after restart right now I have just a bunch of ESTABLISHED conns, so nothing looks bad at the moment 14:11:30 so I got 3 more dangling sockets and the latest in the list is an established connection from your IP 14:11:51 number of open descriptors growing is probably related to it 14:12:27 this is what \I have right now https://paste.debian.net/1209022/ 14:13:09 ok, I think I know the reason. It leaks after ECONNRESET 14:13:14 Now how to fix it... 14:14:16 btw, where is the block cache? I don't see a file/fd for it 14:14:35 p2pool 61235 monero mem REG 9,2 503316480 2493300 /home/monero/test/p2pool.cache 14:14:42 just do lsof -p PID 14:14:47 it's in the beginning 14:14:52 oh, you're on Mac 14:14:56 not implemented for Mac 14:15:00 ah ok 14:15:04 you can try mmap code for Linux to see if it works 14:15:17 will take a look, shouldn't be much different 14:23:08 pushed one more commit that will hopefully fix leaks after ECONNRESET 14:23:27 although I have no idea what I'm doing :D 14:23:33 ok, cache code built with no trouble 14:23:53 nice, so you can just adjust #ifdef there 14:24:13 yes 14:24:14 -#if defined(__linux__) || defined(__unix__) || defined(_POSIX_VERSION) 14:24:14 +#if defined(__linux__) || defined(__unix__) || defined(_POSIX_VERSION) || defined(__MACH__) 14:24:22 in block_cache.cpp and common.h 14:24:45 got a few dangling sockets, but now I see it's p2pool trying to connect to peers 14:24:56 want me to PR it or you want to toss it in yourself? 14:25:07 p2pool 63157 monero 38u IPv4 897611 0t0 TCP ... (SYN_SENT) 14:25:16 and then just p2pool 63157 monero 38u sock 0,9 0t0 897611 protocol: TCP 14:25:23 hyc I'll update myself, thanks! 14:25:44 cool 14:26:52 7 peers now. yay ;) 14:27:11 so dangling sockets are just SYN_SENT packets, it means they shouldn't grow in number 14:27:27 it depends on how long the system keeps such sockets. It might be very long 14:28:02 typical TCP timeot, 2*MSL 14:28:21 should be 2 minutes by default 14:28:45 so |I have one dangling now 14:28:45 p2pool 30072 hyc 53u IPv4 0x692d8611815b6841 0t0 TCP 192.168.1.214:51725->31.208.56.53:37888 (CLOSED) 14:30:21 I changed the code to send TCP RST packet instead of normal close when node shuts down 14:30:34 basically and TCPClient::close() call will send TCP RST 14:30:43 so you might get dangling socket after it 14:37:43 ahhh I think I know where it leaks. Socket that was in SYN_SENT state is not removed, which means failed connections (for whatever reason) are not cleared. Now I know where to fix 14:41:23 hmm, not always. Just saw SYN_SENT socket that later disappeared from the list, so it wasn't left dangling 14:42:42 and not all SYN_SENT are failures, some of them will eventually successfully open 14:43:24 I just need to try calling uv_close() when connect fails and check if sockets keep leaking or not 15:19:55 hyc moneromoooo found the leak: https://github.com/SChernykh/p2pool/commit/230d3e47808c0bd686d83dc151fcda7f8bde8d22 15:20:06 running it on both the server and my dev pc 15:20:17 all good so far, no dangling sockets 15:23:06 RES = 369604 KB, fd = 45 15:25:09 it was leaking handles on Windows too, now the handle count in Process Exporer doesn't increase too 15:31:31 hyc it's better to get latest, because I see a lot of ECONNRESET form you in the log. I reverted "force TCP close" hack because it's not needed anymore 15:49:00 Testnet height 1796161 will be RandomX epoch change, nodes should regenerate cache/dataset and check shares using cache in the meantime 15:49:12 in ~30 minutes 16:03:46 PPLNS window = 2160 blocks (+111 uncles, 0 orphans) 16:03:46 Your shares = 0 blocks (+0 uncles, 0 orphans) 16:03:46 Next payout = 0.000919829079 XMR 16:03:58 Is that expected to have a payout with no blocks on the share chain ? 16:04:13 (I had xmrig down for a while) 16:04:49 I did find a few shares since. Might be why. 16:04:51 nvm. 16:05:09 next payout assumes that you will mine 1 share 16:06:08 maybe it's a bug if you're not mining at all, I need to fix that calculation 16:06:31 I had started mining again a couple minutes before checking status. 16:06:39 ok, next block should be RandomX epoch change, watch your nodes 16:07:37 looks like it went smooth, dataset updated and it was checking shares all the time 16:08:50 i have a ECONNRESET error in the log every 2 seconds now 16:09:06 WARNING 2021-08-25 16:09:00.8806 P2PServer client: failed to read response, err = ECONNRESET 16:09:22 bad peer ? 16:09:41 it's hyc's node 16:09:43 he needs to update 16:10:14 doesn't p2pool give up after a number of tries ? 16:10:50 no, it's your node connecting to his and his node just force resets connection every time 16:11:14 is there a way i can ban his node on my end ? 16:13:36 ok will update 16:14:31 The fd leak seems fixed here too. 16:15:00 sech1: this commit is broken. d246ee155231ac85337faa4d32fb71e03df10828 16:15:09 as I said above you also need to fix the ifdef in common.h 16:15:24 oh right 16:16:35 fixed 16:16:51 fd = 45, rock solid with latest code 16:16:56 leak is fixed 16:18:49 I thought my miner was paused but it was running the whole time. oh well, p2pool is caught up now\ 16:19:14 RandomX epoch change, running nodes handled it fine 16:19:30 good 16:19:35 I restarted my node right after the change, and it failed to sync - "can't calculate PoW" or something 16:19:42 it worked after several restarts 16:19:56 that sounds annoying 16:20:06 It synced to the previous epoch block faster than it could calculate 2 RandomX caches 16:21:21 It's probably safer to let RandomX initialize fully before starting sync 16:21:48 yeah 16:22:56 actually the problem is only with "old" RandomX cache which doesn't have time to initialize. I run it asynchronously and p2pserver starts syncing before it finishes 16:23:07 I can just run in synchronously and that's it 16:32:13 yes, it was an easy fix 16:36:15 fd = 45 still, 0 leaks so far 17:02:40 The p2pool splits the blockreward into multiple outputs? Am I reading this correctly? I thought only one output was allowed per coinbase 17:03:58 no, outputs are unlimited in coinbase 17:04:07 https://testnet.xmrchain.net/tx/b8010568b97e411052c016b02c5a0a7cf81b3c4929e01a02adfbb841fcac50ae 17:55:46 So does this mean you can build massive blocks by having amazing reward distributed among 100,000 people? 17:56:10 *mining reward, not amazing reward 17:57:09 Also, that blockreward has a tx_extra. Does p2pool rely on tx_extra? 17:57:33 Or have we simply standardized tx_extra so that it is always on? 17:57:42 If you go over the median block size, you start decreasing the miner reward. 17:58:11 Right forgot thanks mooo 17:58:21 Monero also rejects a block that's more than twice the median block size. 17:59:11 Right, yes, didn’t mean to get this into a discussion about blocksize. 18:00:10 tx_extra is used to store p2pool block hash 18:00:32 Oh interesting. So this may also end the discussion about removing tx_extra then 18:00:38 Or at least affect it 18:00:53 the discussion was about regular transactions, not coinbase 18:01:23 I can help see if p2pool successfully builds on an intel MacBook, Debian, or Fedora later today if that would be of help 18:02:01 Sech1 oh right fair enough 18:05:02 What block hash in "tx_extra is used to store p2pool block hash" ? 18:08:24 sidechain block hash, it's stored in merge mining tag 18:08:39 for example, https://testnet.xmrchain.net/tx/90f305003090c51058cfb7687fe4e947ce6ad866ccfe6a73edbeb9261012d99b 18:08:49 block hash stored is 40cdf18a1fe322530c393a41c338ad3ac767bababd01700d81df02d1b5aeb85d 18:08:53 you can grep it in the log 18:09:08 Oh, the hash of the *previous* block on the share chain ? 18:10:31 no, it's the hash of the side chain block that was merge mined with this Monero block 18:11:13 you can read the big comment in pool_block.h, I don't know how to explain better 18:12:00 sidechain block's keccak hash is used as this block id, this keccak hash is just stored in the "Monero" part of the block 18:12:07 this is how it ends up on Monero blockchain 18:13:16 changing any byte in Monero block template or in sidechain data will change the hash and also Monero PoW hash because it's part of the coinbase tx 18:14:38 I didn't know how to better solve this problem - it must be impossible to change sidechain data without changing PoW hash, and PoW hash by definition must be Monero's PoW 18:25:45 OK, the nonce being zeroed makes this make more sense : 18:26:08 So does this make it incompatible with merge mining ? 18:26:33 (I actually use merge mining) 18:32:10 incompatible how? It is merge mining 18:34:42 Hmm, OK. I guess it must be since it has an extra chain... 19:49:18 does this mean p2pool plus towforget merge mining will override each other? 19:49:28 townforge& 19:50:14 they shouldn't 19:51:02 as long as hashes both chains that hashes in the merge mining tag belong to them 19:51:10 *as long as both chains that hashes in the merge mining tag belong to them 19:51:21 damn, I need to take a break :D 19:51:28 heh 19:52:05 when you see merge mining tag, don't just assume it's your chain, check that the hash belongs to it first 19:53:44 btw, submitting external p2pool blocks with enough PoW to monerod works fine 19:54:14 It reduces latency between p2pool and Monero block ZMQ update from 0.1 to 0.03 seconds on my machine 19:54:27 yeah, didn't think it'd be a problem. would've been too obvious as a DDOS 19:58:54 even better, only 13 ms latency: https://paste.debian.net/hidden/e798ce2c/ 19:59:03 probably because of slow PoW check on monerod side 19:59:44 btw the last line in this paste is exactly what I was talking about. p2pool checks the hash and tries to search for it 20:01:02 is there any way to make monerod use dataset to check new block PoW? 20:01:36 yes, but it only allocates dataset if you activate its miner 20:01:52 hmm, and then it uses also to check new blocks? 20:01:58 yes 20:02:01 nice 20:02:40 1 solo mining thread won't hurt 20:14:37 doubles hugepage requirement 20:14:58 add xmrig to that :D 20:17:09 My server has been running without tcp socket leaks for several hours, I guess it's really fixed 20:19:28 mine looks fine too 20:20:20 If p2pool just puts the hash of its block template/data in the MM tag, it'll conflict. If it puts the merkle root of the MM hashes, it should be compatible. 20:20:49 I don't see tre_branch/tree_path used in the source, so it's likely it doesn't put the merkle root. 20:21:02 what merkle root? There are not transactions on sidechain 20:21:08 *no transactions 20:21:18 Merkle root of merge mined blocks. 20:21:42 I need a bit more detailed description 20:22:44 You have two chains A and B merge mining with Monero. A creates a block template with hash HA, B another with HB. The MM tag doesn't get HA nor HB, but the merkle root of the merkle tree with HA and HB in it. 20:23:13 But I have 1 chain 20:23:14 My MM proxy in TF does this automagically (I made this to be compatible with tari). 20:23:29 Yes, that's the point :) 20:24:04 I think I get what you mean 20:24:15 I'm not nearly as technical as you guys, but I'm kindof curious what kind of replacements are feasible for javascript mining? Would it be possible to mine to a p2pool node via a firefox/chrome plugin? 20:24:24 1 Monero block can be on a block on 2 different merge mined chains? 20:24:40 If you use the merkle tree system, yes. 20:24:58 If you don't, the two chains are incompatible for merge mining. 20:25:14 But then p2pool will need to be aware of those other chains 20:25:18 tbh the details are... a bit complicated. 20:25:41 It would have to be aware of multiple chain-icity, not any particlar chain. 20:25:53 Like, my MM proxy *should* work with Tari, but doesn't know tari at all. 20:25:57 Mysterion p2pool node is the same as a regular pool to the regular miners (xmrig) 20:26:06 But I've only tested it with two TF chains. 20:26:44 yeah I just know javascript mining has pretty much been kneecapped over the last couple years, I'm just wondering if there are any alternative solutions to make it viable again via in browser mining 20:26:56 Not with RandomX 20:27:41 i've been out of the mining scene for a couple years, I don't really know much about RandomX 20:27:49 There is https://repo.getmonero.org/selene/primo, which can be used to mine with a browser. 20:28:09 The actual mining's done by a non-js process though, just controlled by a browser plugin. 20:28:28 I actually did see primo, it looks promising 20:28:31 This fixes the "website stuffs js without hte user's knowledge" problem too. 20:28:44 Because screw running any random site's code. 20:28:45 I still don't get why would 2 different merge mined chains care about each other 20:29:13 p2pool expects its block template hash in the MM tag, right ? 20:29:36 yes 20:29:42 There is one MM tag. I guess it might work if there's one MM tag per chain... Though it would increase the Monero block size. 20:29:50 yeah I like a more transparent solution, I don't necessarily want site ops to have to be shady about mining, best to be up front about it as if you were requiring a payment to get behind a paywall 20:30:11 If there's several, I guess they don't need to. But if there's a single MM tag, one chain is not going to find its block hash in there. 20:30:53 why? It will find its hash because it was mined by it 20:31:16 What is "it" in this sentence ? p2pool ? 20:31:20 something like client generates X number of shares and then they get an access token that's available for X amount of seconds/minutes/hours/days or maybe it could be valid for X amount of bytes, just depends on how the site operator wants to configure it 20:31:22 p2pool 20:31:31 only one subchain will find any given block\ 20:31:35 p2pool will find the hash in blocks mined by p2pool 20:31:38 Then yes, p2pool will find its block hash. The other chain will not. 20:31:40 so they don't have to care about the existence of other mergers 20:31:58 If you place a merle root, both chains will find theirs. 20:32:05 Or all three etc. 20:32:37 If I place merkle root, I need to somehow find other chains' hashes before looking for my own 20:32:44 that's more unnecessary complexity 20:32:46 Primo does that. You mine ahead of time to generate N credits, then you spend them to access various pages/features/etc. 20:33:54 For my particular case (and AFAIK tari's similar), you don't point xmrig to monerod, but to the MM proxy, whch does the magic. 20:34:07 Similar for you actually, you mine to the p2pool proxy. 20:34:08 there's gonna be some really cool stuff possible when you combine p2pool and primo 20:34:24 So you'd have a chain of proxies. There's a new RPC in monerod I added a while bakc to help with that. 20:35:19 Anyway, I'm not asking you to do that. I hope you might consider doing it but I certainly won't push :D 20:35:31 It'd also be possible to integrate it into the ZeroNet protocol so peers could automatically pay eachother in shares to seed sites to eachother 20:35:33 I need to first understand it :D 20:35:58 Let me try to remember how it actually wors... 20:36:48 sooo my wild speculation: you mine with xmrig and point it to MM proxy, you put merkle hash into the block template and proxy can submit found shares to multiple chains, right? 20:36:54 depending on the difficulty of share 20:36:56 The proxy receives a getblocktemplate notification. It forwards it monerod (or the next proxy). It gets it. It adds its block template hash to the response and forwards the response back. 20:37:09 Yes. 20:37:16 so you main with xmrig to all the chains at the same time 20:37:19 hmm, interesting 20:37:50 well, the easiest thing would be to not use merge mining tag (for now) 20:37:52 If the getblocktemplate comes back with a MM tag in its response already, the MM proxy adds its tag and does merkle magic and reutrns that instead. 20:38:18 * moneromoooo clearly doesn't remember all details, goes to check the source 20:38:55 p2pool would use some different tag in tx_extra for own block hashes and some time later would also put merge mining tag, right? 20:39:50 Well, ideally it'd be better if you played along with the others, so all hash rate could accumulate. 20:40:20 Without adding more data in the monero block. I guess 33 bytes isn't that large but still. 20:40:55 "more hash rate would accumulate" that would probably break p2pool reward calculation... 20:41:20 if other chains don't know about p2pool, they wouldn't notify p2pool nodes about their hashrate 20:42:08 that's right, looking at the Primo page I remembered what my concern was with it...it requires Apache. I guess everything has to start somewhere, but that'll be a problem eventually 20:42:51 Any server can use primo. Only apache has a plugin, but you could have one for tor, bittorrent, whatever else. 20:43:19 I see 20:43:22 The only problem being "is it a good idea". 20:43:34 I think so 20:43:52 Any service that requires payment for service can be patched to squawk primo. 20:47:00 it may not be the proper implementation but the concept is definitely something worth trying to perfect IMO 20:47:07 https://github.com/vinced/namecoin/blob/master/doc/README_merged-mining.md 20:47:23 I can't find the namecoin doc I used, but this has the rough idea. 20:47:28 we're essentially creating a way for people to use electricity as currency 20:47:55 kinda crazy when you think about it 20:53:39 Otherwise, there's the MM proxy source: https://git.townforge.net/townforge/townforge/src/branch/cc/src/merge_mining_proxy/merge_mining_proxy.cc 20:53:56 It's a big chunk to swallow, but the interesting parts are: 20:54:34 add_add_aux_pow, on_get_block_template 20:55:04 Those will alter the block template to place the merkle root of all MM chains so far in the MM tag. 20:55:44 I feel like I forgot how this works -_-