00:27:01 they have another +5 ahead 00:33:33 Its not easy to get these leads 00:36:16 depth 6, monero couple behind 00:36:30 > monero heights 3489459 to 3489462 could be orphaned by qubic (possible 5 blocks, current 3 blocks) 00:36:52 from what I saw they wait until the actual max possible amount, or 9 00:37:09 sometimes they are too slow pushing their alt chain and monero overtakes them and they lose it 00:38:45 I cant help but think that they have >51% hashpower 00:39:06 they have been able to spot higher bursts 00:39:24 They are likely doing bursts, as discussed earlier 00:39:42 22-02 UTC is when we tend to see it, coinciding with lowest monero power 00:39:47 ginger gave them the idea 00:39:58 :P 00:40:16 It's somewhat obvious if the goal is max pr effort too 00:40:19 someone also gave them the idea about putting their own txs in :) 00:40:36 and about mining offline 00:41:30 really all the github PRs is about discussing not hypothetical anymore but having an active incident discussed in the open and giving attacker countermeasures 00:41:39 ok monero got there 00:41:45 5=5 00:41:47 reorg? 00:41:49 yep, reorg 00:42:03 aaand they are instantly +1 00:42:35 +2 00:43:11 https://mrelay.p2pool.observer/p/ipbNuLAKVHFtODZW/1.txt (code snippet, 18 lines) 00:43:11 how it looked just before reorg, if anyone wants to consider where checkpoints would have been nice 00:43:16 this is making 144 look defeatable 00:43:50 they don't care about profit 00:44:03 they care about the idea of showing profit 00:44:08 Since they are able to get 3 blocks ahead 00:44:13 but they are just burning xmr for PR, not giving to miners 00:44:53 They had a poll about doing 29 block reorgs lol 00:44:57 we have seen them get +11 ahead not just deep 00:45:31 yeah, maybe September as they say. they need more fresh PR as their doge and AGI training one is not really going much further 00:45:39 for the dns checkpoints, the dns is probably the weakest link 00:45:45 indeed 00:46:07 +3 ahead/deep 00:46:36 My node and your node might not see the same records, and definelty arent checking at the same time 00:47:26 yep, that's why I mentioned with rolling checkpoints at least the last N will coincide 00:47:30 maybe not exactly the tip 00:47:31 The main problem is if mining pools split, even temporarily, then start competing with one another 00:48:01 there’s also the small amount of solo miners that will get split off. not sure what percentage that is though 00:48:01 DataHoarder: The problem is if any of the checkpoints are created from a reorg 00:48:03 I was writing a shim for the DNS updaters so they can point to each other and agree ahead of time what they see 00:48:23 and share alt blocks they see (which is why I was adding ZMQ for alt blocks)\ 00:48:37 We had issue where 520 was good, 533 good, 525 reorged chain, 527 good, = broken 00:48:46 that way they are always aware of alts, and can select the chain 00:48:59 I don't see hashrate increase from their solution network 00:49:18 but this is defeatable, all they need is xmrig set with a custom higher difficulty 00:49:27 then it won't report shares that don't find blocks 00:49:33 so it will never be seen :) 00:50:39 @vtnerd: Was ~2-5% 00:52:02 need a consensus network for the DNS checkpoint nodes :') 00:52:57 monerod also has been veery sluggish the last hour 00:53:00 monero* 00:53:07 Or a patch for the checkpointing node to reject all reorgs 💀 00:53:08 it all adds up 00:54:14 @ofrnxmr:xmr.mx: this wont work 00:54:54 Reorgs can come at different times indeed 00:54:56 there's gotta be a better way 00:55:14 Something I noticed is that alt blocks don't really get broadcasted or travel around 00:55:17 even if close to tip 00:55:44 I have a few custom patches to push these 00:56:25 checkpointing nodes should be all aware of the same alt chains as each other to be able to make good selections 00:56:42 given they are selecting from a bit behind, as well, not just the tip 00:57:51 if they are aware of the existence of two for a height they have to stamp a checkpoint for, that's when they need a deterministic way (given equal states at that point) to select this and publish the dns records 00:58:44 that brings more issues, that monero alone currently doesn't sync this up (you need helpers/patches to push blocks via rpc, monitor alts and make these available to others) 01:41:28 Question about mining and timestamps. Do hashers in a pool update the header timestamp in real-time as they hash? Or do pools push a timestamp, and the hashers never change it? 01:46:10 Pools push a blob, the blob has the timestamp 01:46:39 The miners just change the nonce field 01:46:55 usually pools push new tasks every few seconds 01:49:37 Why not make the dns checkpoints using .oinion addresses? So there is no worry about issue keys and seized domains 02:40:02 @rucknium:monero.social: , dunno if its easy to do, but might be cool for the moneroconsensus thing to show the timestamps of the blocks 09:46:01 TriggerCoder: not everyone has tor on their nodes 09:46:23 Onion address is effectively just one Ed25519 key 10:08:35 morning, seems qubic is having issues https://irc.gammaspectra.live/4fef6fbad228100a/7_deep_qubic_orphan.png 10:10:20 ^ this happens when blocks are found in quick succession close to their tip 10:11:57 they tried to reorg but monero found rest of blocks faster than they could 10:12:16 they are really getting hit by their slow block propagation 10:27:35 DNS checkpointing is giving to many the impression the devs are just centralizing the coin to themselves at this point. Doesn't all DNS checkpointing effectively do is let reputable miners collaborate? So why not have this as a separate project among legit miners to collaborate among themselves instead. Nothing to do with devs [... too long, see https://mrelay.p2pool.observer/e/7KOpybAKajZHR1pX ] 10:28:22 miners and big merchants 10:29:35 @unt0ld:matrix.org: we can also phone up supportxmr and the other big pools and tell them to 51% attack against qubic, same effect, simpler to do than developing anything new 10:33:34 well miners can do a lot of things. for example if i was a big miner, to protest the low mining reward, i would create a cartel to not mine low fee tx lol 10:36:01 Maybe it doesn't matter though. This collaboration feature can be included in monerod I guess. It doesn't have to be DNS records. Just give node addresses for your node to collaborate with and the nodes do it through zmq or something fast like that 10:36:55 reorg incoming 10:37:23 "and they keep coming and the won't stop coming" 10:41:09 ok no reorg just a normal block 10:45:12 they lost it :) > reorg incoming 10:45:43 https://irc.gammaspectra.live/2cb6f98c8e4be398/image.png 10:46:05 this current one, they are depth +2 so they can at least take one out 13:10:08 though dunno if timestamp of the block itself or when it is seen by the node would be more relevant 14:23:13 @gingeropolous:monero.social: Done https://moneroconsensus.info/ 14:24:46 Only have timestamps on main chain blocks because get_alternate_chains RPC calls gives limited info about alt blocks. I think I would have to query for each alt block header individually by block hash to get timestamp data. 14:25:22 It's the same reason the app assumes alt blocks have nonzero txs. 14:49:23 that timestamp is quite verbose :D 14:50:41 I could reduce it to Unix epoch seconds :P 14:51:07 It won't collide with its height block at the same height since alt blocks don't have timestamps displayed. 14:57:54 There are several papers on checkpointing PoW blockchains. This looks like a good one: Karakostas & Kiayias (2020) "Securing Proof-of-Work Ledgers via Checkpointing" https://eprint.iacr.org/2020/173 14:59:39 I don't think there's time to read, evaluate, and implement one of these papers' proposals. 15:16:38 could assume utc and do like 28-11-25 11:25:56 17:24:54 Karakostas & Kiayias recommend appending a random nonce to each checkpointed block. That prevents the adversarial chain to mine ahead of the checkpoint. 17:26:27 a random nonce? in the block itself/pow? 17:26:42 but if checkpoints are delayed (set N heights from tip) how does that work 17:29:22 In their model, checkpoints are issued immediately and not delayed. 17:29:46 If there are multiple candidate blocks, the checkpointing nodes vote. 17:31:50 like, manually? user intervention? 17:32:45 yup, every 2 min. 17:33:12 i don't really know, every one here is much smarter than i. disregard. 17:43:25 The voting process is modeled with an abstract function in the paper. It's some blackbox that gets a list of blocks and nonces and spits out the selected block and a nonce. 17:44:09 yeah, that'd require changes to block emission, so for later than the bandaid 17:44:34 I think the nonce idea could simply use tx_extra. 17:45:04 If the checkpointing service outputs a nonce, the miner has to include it in tx_extra. 17:45:28 It proves that the block was mined after the checkpoint was issued. 17:51:08 (trying to dig through that paper ...) so could the checkpointing service just be grabbing a blockhash from bitcoin? 17:52:54 so with publish or perish, im curious if we could make the k dynamic. so like, in a rolling window of n blocks, if the node hasn't observed much orphaning, then the default of k=3 is used. 17:53:22 but if during the same window, the rate of orphans (or depth of orphans?) increases, then k is increased 17:53:59 because as someone mentioned, qubic seems quite capable of producing 3 blocks 17:54:23 I think a paper I read recently has this dynamic k. 17:54:30 19:44:35 I think the nonce idea could simply use tx_extra. 17:54:45 yeah, I guess if it's something only the checkpoint servers need to see that could work 17:54:53 just not the rest of the network that mines on its own 17:55:14 gingeropolous: this one https://arxiv.org/abs/2307.00529 17:55:39 noice, thanks 17:56:03 Just ignore their block weight function, which is useless, and imagine PoP instead. 17:56:18 huh tevador for some reason my bridge can't see your messages 17:56:29 I'll debug in a second 17:56:32 yeah i noticed that too DataHoarder 17:57:06 for @rucknium:monero.social / @ofrnxmr:xmr.mx here's currently a DNS server for the sole purpose of serving DNS checkpoints. Can be setup just on a subdomain of any domain with your own keys https://git.gammaspectra.live/P2Pool/monero-highway 17:57:48 seeing this conversation on checkpoints, it seems like we have another bifurcation of mitigations (perhaps). There's 1) preventing selfish mining attacks, and 2) preventing deep devastating reorgs. 17:58:07 Also allows AXFR zone transfers so it can be setup as master DNS with other servers being able to serve records but not produce them, as they have no keys. So you can keep master server "secret". 17:58:22 DataHoarder: miners would verify that blocks mine on top of valid checkpoints *and* include the checkpointing hash in tx_extra. 17:58:25 because an adversary hellbent on #2 could easily overwhelm the PoP defense k-failsafe 17:58:49 It has a simple api to update all txt records at once - any amount of them 17:59:11 I have added a small README for setting it up somewhere, if you need help feel free to ping 17:59:12 tevador: ofc, that'd mean changing how miners mine 17:59:24 it's what I mean that not all could change *now* 17:59:38 Yes, that would require a change in the getblocktemplate function. 18:00:21 So probably not something we can roll out now. 18:00:34 >err="failed to invite in ensure joined: M_FORBIDDEN (HTTP 403): You don't have permission to invite users" 18:01:03 whoever is admin on #monero-research-lounge needs to add invite privileges to the @appservice-irc:monero.social account afaik 18:01:24 that's why it's currently failing to show tevador's messages 18:01:30 Qubic will start 20+ deep reorgs from tomorrow AFAIK. 18:02:39 even manual DNS checkpoints might help there 18:02:54 (in reply to "20:01:30 Qubic will start 20+ deep reorgs from tomorrow AFAIK." for Matrix side) 18:13:59 They haven't proved they can reorg that deep though... the biggest reorg pulled off by them was what? 8 or 9 blocks? they haven't gotten over 10 iirc 18:14:21 they have stopped there. they have been able to be 14 depth 18:14:56 or 16, can't remember. then once monero reached "9" orphans they released their own chain, even when they were further ahead 18:15:00 i mustve been out of town or not watching my node i didn't noticed it. 18:15:16 that was a few days ago 18:15:23 tonight they had depth of 12 18:17:12 when are they going to focus on Doge or was that just another lie? 18:17:21 01:36:43 they could have done 11 on this one 18:17:24 ^ depth of 12 18:17:40 months from now. don't read too much into their marketing 18:18:47 also @rucknium:monero.social / @ofrnxmr:xmr.mx this brings TTL times to the minimum you want to support, ofc, pending middlemen DNS Resolvers / Forwarders users might be using via system DNS 18:19:08 looks like they done a 9 in the last 720 blocks 18:19:10 https://chill.mycotrip.tech/uploads/4814bc54ba29488d/image.png 18:19:15 With my examples and a TTL of 300s (5m) it's all fine, but the records tend to update within 10s via mainstream dns servers 18:19:23 mycotrip: you are looking at the wrong thing. look when they pushed the blocks 18:19:27 not the chain they orphaned 18:19:38 when they orphaned those 9 blocks, they had 12 blocks 18:19:56 so they wasted a "couple" and could have waited longer for monero to catch up, and orphan 11 18:21:07 ahhh that makes sense! i am still learning. so please excuse my stupid questions / ignorance 18:21:16 thanks for the for clearing that up for me! 18:21:43 I believe it was this one https://irc.gammaspectra.live/d8ecb9bfd77f96bf/image.png 18:21:56 when they pushed the chain they had up to 3489628 mined 18:23:08 With 10+ deep reorgs, we will start seeing invalidated transactions. 18:23:41 what would the impact of that be? just a delay in the transaction or it being totally lost? 18:23:55 Totally lost. 18:24:44 global output indices get invalidated - meaning they are no longer valid and are lost 18:25:16 Once the tx get invalidated with the deep reorg, the sender needs to open their wallet again and make a new transaction. 18:25:23 txs refer to mined outputs via the 64-bit output index :) 18:27:33 @plowsof:matrix.org > whoever is admin on #monero-research-lounge:monero.social needs to add invite privileges to the @appservice-irc:monero.social account afaik 18:33:56 With FCMP, the situation will get even worse. Once the anchor block gets invalidated with a 10+ deep reorg, *all* transactions constructed with that anchor become invalid, i.e. all transactions made in the last 20 minutes or so. 18:35:53 datahoarder, it might be because the room is invite-only 18:36:17 yes, as mentioned :). This was fixed on other channels when there were raids last night 18:36:55 So people that didn't disconnect overnight kept the invite in, people that reconnected or dropped from IRC can't get their nicks to rejoin 18:36:55 Other channels have invite user = default? 18:37:14 well, #monero:monero.social got invite-only enabled 18:37:15 Or does the room have to he set back to public 18:37:58 I can't remember. But bot is able to invite users that need inviting as long as the rights are set (unless the rights need to be set on the user) 18:38:51 Then the easy solution is to allow existing users to send invites 18:39:41 Else can set invite to pwr lvl 1, and set the bot to lvl 1 18:51:05 now moneromooo is out of the room too, :D 18:52:25 * moneromooo feels pinged 18:52:44 Do I need to read the scrollback ? 18:53:08 tl;dr room is invite only and bridge can't bring your user into matrix side 18:53:25 nick change or quit/join does that 18:53:35 @xmrscott:monero.social @plowsof:matrix.org 18:58:31 Btw, is there a github issue on the checkpointing solution? Are the checkpointing nodes going to blindly checkpoint any block they see? 19:03:04 "reposting" 20:58:31 Btw, is there a github issue on the checkpointing solution? Are the checkpointing nodes going to blindly checkpoint any block they see? 19:03:18 or the ones working on that on the other side won't see it :) 19:06:38 Ack, Invite only just needs to be removed , it was enabled temp last night 19:14:11 test 19:14:40 works, the next time they speak they should get autojoined 19:20:27 should still change the invite power level so that the next time we have to close the room due to noise, the bridge doesnt go on life support 19:21:51 let's revisit that if the new bridge gets deployed further 19:31:35 tevador: My outline for the issue I'm writing is: 19:31:35 1. Brief on situation. 19:31:35 2. What rolling checkpoints will do and will not do 19:31:35 3. Pros[... more lines follow, see https://mrelay.p2pool.observer/e/xsbx2LAKWGJSOExR ] 19:50:38 I think the checkpointing solution will need to somehow ignore qubic's blocks. Otherwise qubic with >50% hashpower can just trickle-release blocks and still orphan everyone. 19:56:31 They would be able to selfish mine and mine empty blocks, but not perform deep chain re-orgs if they have majority hashpower, right? 19:57:28 The checkpointing code identifying Qubic blocks and ignoring them would definitely sharpen the defense. 19:57:50 Yes, they could just mine 100% of empty blocks, which is not a good outcome of checkpointing. 19:57:59 another idea I think kinda similar to tevador's that a friend shared with me https://hackmd.io/@Forgetmemd/SkM8x5l5xx 19:58:33 but expand beyond coinbase tx 19:59:17 This can't work. Qubic can just create full blocks of their own transactions. 19:59:24 doesn't that seem kind of short sighted? just identifying qubic? what if some other actor tries this? 20:00:17 Well, the whole point of DNS checkpoints is that they are short-sighted. 20:00:44 Temporary, until better countermeasures can be analyzed, implemented, and deployed. 20:00:52 i guess if we view the DNS checkpoints as a band-aid it makes sense. 20:01:32 For rising fees: An idea for being able to more frequently adjust transaction fees with node upgrades and not network upgrades: 1. Change the tx anonymity pools to be infinitely scalable, with consistent limited selections to be offered by wallets. Essentially the min relay fee will become the base level fee pool. This needs t [... too long, see https://mrelay.p2pool.observer/e/tZDf2bAKVHB5cXdE ] 20:01:33 i'm pretty ignorant around all of this so if i don't make sense or miss something super obvious let me knw. 20:01:47 Obviously, we'd have to whitelist blocks rather than blacklist. 20:02:22 tevador: but the txs would use tx_extra to reference previous block(s), right? 20:03:04 I don't think it is completely fleshed out idea, but they asked me to share 20:03:15 Qubic would fake their own secret transactions that would reference their secret blocks. 20:06:37 tevador: sure, but all "economic" transactions would reference the legitimate chain, so...I guess economic nodes would be incentivized to stay on the chain with their pool payouts, exchange deposits, etc. I think is the idea, doesn't require hardfork and allows users making txs to help signal which chain is "legit" 20:07:56 There is no decentralized way to identify "real" transactions. 20:08:42 I tend to agree, but here we are discussing checkpoints...so just thought I'd share 20:36:34 Hi. I'm wondering about Luke's proposal - Local PoW. It only got mentioned briefly in one MRL github issue and somehow got swept under the rug. To me it looks like an elegant solution without the downsides of PoS and not being a half-measure like Publish or Perish: mining remains CPU-centric while (presumably) cheap ASICs elim [... too long, see https://mrelay.p2pool.observer/e/_Zzf2rAKV1pFNXZr 20:38:11 I can only speak for myself: thats a no from me 21:24:22 Local PoW, which doesn't actually have a good proposal on how to achieve it, and merge-mining have arguably been underdiscussed 21:25:25 Wouldn't requiring ASICs mean there'd be higher friction to mine Monero? 21:35:21 Problems with requiring ASICs: 21:35:21 * Makes it hard to mine in countries where there are no ASICs supplies or mining is illegal 21:35:21 * Adds additional friction to mining 21:35:21 * Adds a dependency on ASIC manufacturers, who might be pressured by governments[... more lines follow, see https://mrelay.p2pool.observer/e/gdS23LAKdHEyZ2Ni ] 21:37:15 Advantages of requiring ASICs: 21:37:15 * Kills botnet mining (this may be a disadvantage depending on who you ask) 21:37:15 * May makes attacks more costly since ASICs are a limited resource 21:38:00 In my opinion ASICs might lead to centralization of ASIC production. We'll end up with one or two manufacturers, unless we somehow create an ASIC design that can be made at home. 21:38:03 if asics, which algo? 21:39:12 @torir:matrix.org: using existing ASICs (user above mentioned bitaxe) eliminates this issue, there are already many more than two manufacturers of bitaxes and knockoffs, let alone sha256 bitcoin asics in general 21:41:44 https://github.com/bitaxeorg/bitaxegamma >At the heart of the bitaxeGamma is a BM1370 Bitcoin mining ASIC from the Antminer S21 Pro from Bitmain. It's not open source. 21:42:08 Bitaxe appears to be everything but the actual ASIC. 21:45:00 right, but there are more than a couple makers of double sha256 asics now 21:46:04 there is apparently open source hw on the horizon to compete with big three existing chip makers also https://www.cryptotimes.io/2025/05/03/jack-dorseys-block-to-launch-open-source-bitcoin-mining-chip/ 21:48:12 I saw that... kind of interesting but I don't think it will pop off and really be worth anything. 21:48:19 I will agree that using a SHA256 ASIC for Local PoW is more likely to increase availability of mining hardware for users mining Monero than other algorithms. Still, the supply chain for ASICs is absolutely something governments can crack down on. Microchip production requires specialized equipment; we can't just have users make their own chips. 21:49:06 Countries that ban crypto mining might already be on the lookup for ASIC orders. 21:50:50 man i just wanna know what the soft fork PoP needs to be ... ready 21:51:22 The good news for Local PoW is we don't need the latest and greatest ASIC chip. We just tune the algorithm such that it requires double SHA at a faster rate than CPU or GPU can produce so that you need an ASIC, but it doesn't need to be the best ASIC available. 21:54:35 I think checkpointing will not achieve much without at least PoP. We could do PoP with k=∞. 21:54:56 In regards to merge mining, I don't understand merge mining all that well but I believe it would require running both a Monero node and a node for the other coin? 21:55:46 Isn't Tari already merge mined? 21:56:05 hard to outcompete standart hw with niche-specific hardware (FPGAs). True, we may face a situation where an adversary owns too much CPU for longer, not only in bursts. PoP is a good option imho 21:56:53 There is synergy between PoP(k=∞) and checkpointing. Checkpointing will remove the chain splitting weakness of PoP(k=∞) and PoP will ensure the checkpointing node won't checkpoint the selfish chain. 21:57:24 Tevador, qubic has been able to get like 11 blocks ahead though 21:57:34 Try infinity blocks. 21:57:47 mycotrip: Tari mined 20% empty blocks. MM is a gamble: btc or ltc may have +51% instantly 21:57:50 yeah with a k of infinity that would be addressed @ofrnxmr:xmr.mx 21:58:03 we just lose network recovery from netsplits 21:58:09 Duh, i have a short memory, sorry 21:58:36 I read that infinity, went to reread proposal, and forgot about infinity 🥲 21:58:39 Cross-posting from #monero-research-lab:monero.social : I created an issue for Temporary rolling DNS checkpoints to thwart deep blockchain re-orgs: https://github.com/monero-project/monero/issues/10064 21:59:02 ^ A good place for more organized discussion 21:59:12 the hard truth is that selfish mining is what an economically driven miner would do with a certain % of hashrate 21:59:18 why drive up the diff when you don't have to 22:00:11 > <@torir:matrix.org> I will agree that using a SHA256 ASIC for Local PoW is more likely to increase availability of mining hardware for users mining Monero than other algorithms. Still, the supply chain for ASICs is absolutely something governments can crack down on. Microchip production requires specialized equipment; we can't just have users make their own chips. 22:00:11 That concern about governments strangling the supply is something to look into for sure. I don't know how realistic it is, but anyway: since we're basically looking for some unusual piece of hardware that doesn't automatically ships with a PC to enable Local PoW, I guess theoretically we're not even limited by ASICs 22:01:13 imo asics are just another level of permission, but its our permissionless nature that got us here so .shrug_guy 22:01:58 Is the merge mining idea that Monero becomes a coin that is merge mined from/with some other larger coin (LTC/BTC)? 22:02:33 Instead of an ASIC, we should use a closed source tamper resistant device produced by the Monero dev team that reads computer memory to confirm the computation was done locally then signs the blocks. The Monero dev team can promise that proceeds from sales of the device will go into reinvesting into Monero development and definitely won't be used to purchase expensive automobiles. /s 22:05:37 midipoet: Midi, yes 22:06:08 Ltc isnt always larger, its doge or doge+ltc that is 22:09:43 Then, yeah, I think that deserves more discussion. It's as valid as any other of the ideas I have heard. I think we all have to admit that any solution to this is pretty much going to be antithetical to "Monero's original ideology". Admitting that, would allow us to just pick the most secure mitigation/fix, without getting lost in all the other philosophy. 22:12:56 I view merge mining as a potential medium term solution, but not a long term one. It could be long term, but I think with research we can probably find an acceptable solution that better fits with Monero's values. 22:14:11 The first mining pool to adopt merge mining of Monero could easily gain majority hashpower alone. You could have multiple algorithms to try to avoid that (50% block RandomX, 50% Scrypt merged mined with LTC/DOGE). Most projects that have or planned to merge mine with Monero do not have merged mined RandomX as the sole algorithm AFAIK, for this reason. 22:16:05 e.g. https://townforge.net/proof-of-settlement 22:18:41 could we make a merge mining chain that is just used for mining, so like 5 to 10 second block times with monerod following whatever the top block in the merge mining chain references as the previous. 22:18:41 After a certain amount of time the blocks from the side chain could be removed so short term we have fast blocks which makes large reorgs harder but we don't have the negatives of fast blocks for the whole network? 22:18:57 midipoet: I kinda like this one too, but I think it's offputting to people because it at least partly means that the big-brains over at dogecoin made a better decision a decade ago while xmr has kind of muddled along and mucked things up 22:19:31 Well, the way it is now, a lot of people have made better decisions than Monero 22:19:33