09:40:20 https://x.com/c___f___b/status/1953366557423235576 09:40:26 Confirmed, all Qubic blocks are empty now 09:40:47 the attack mode is to create a bubble with their token. Lots of PR needed, its a psychological operation. 09:40:47 kek 09:41:13 sech1 https://x.com/c___f___b/status/1953366557423235576 09:41:30 your link is broken bcs it applied formatting on the matrix side :P 09:42:04 How generous of them to leave tx fees to Monero pools :) 09:42:52 they are literally just giving away fees to honest miners 09:43:25 who could have expected that the economic design of PoW actually works 09:55:04 This way they can easily be identified:-) 10:02:32 Came across this (relatively) wacky, US Department of Defence supported/sponsored MIT thesis on cryptocurrency PoW today, if anybody is interested: https://dspace.mit.edu/bitstream/handle/1721.1/153030/lowery-jplowery-sm-sdm-2023-thesis.pdf 15:11:41 Can nodes ignore empty blocks mined if mempool has pending txs ? 15:12:50 you can't see that in consensus in the past 15:13:02 all they have to do is add one tx they control as well 15:13:56 a miner can also get lucky-unlucky and find a block the instant they find another before they get the proper valid set of txs from mempool, so it CAN be empty even in normal conditions 15:14:20 Happens even on btc 15:19:50 Seeing lot of empty blocks today 15:20:34 Consecutive empty blocks too 15:21:42 It will just delay first confirmation of a transaction by a block or two. Much less delay than happened during the black marble flooding, which reached hours for txs paying the lowest fee. 15:23:40 Also before bugfix where pools werent updating block templates/ lol 15:25:32 Yes. That, too: https://rucknium.me/posts/monero-transactions-60-seconds-faster/ 15:54:13 Looks like they've gotten pretty lucky recently. 4 in a row 17:57:29 What rate of orphaned blocks would be a sign for concern 18:06:59 define "sign for concern" 18:07:34 One could say 10%, one could say 50%, one could say 80+% 18:08:47 Depends what you define as success. If able to orphan 100% of blocks, particularly if they decide to censor transactions or mine empty blocks, then that would definitely be concerning 18:11:13 Does that mean 50% of other ppls blocks becoming orphans is OK? No. But not as bad at 100%. What about 10%? Same, not as bad as 50, but still not good. 18:11:15 Also, defining concern. Does this mean "when we have to make major changes to the protocol to protect honest mining"? Or does it mean "when we have to start paying attention"? Because we're already paying attention 18:12:08 a tangible impact on user experience or network stability 18:13:08 Right now it's barely at half a percent, so I'd assume that has very little impact 18:13:48 that is so low because they withhold orphans that they arent winning 18:14:31 If they have 51% of the global hash, they will win more often than not, and can orphan everyones blocks (if they have average luck) 18:24:40 @countbleck:matrix.org and quite some of those come from known pools orphaning each other 18:24:43 33% of them 18:25:58 so they're hurting their own profitability? 18:26:20 That's miserable 18:28:26 oh new toys to play with on 18:28:41 moneroconsensus (sorry I pressed Enter too early) 18:31:10 anyway, i think some discussions should continue about changing the protocol to lower combat such attacks. 18:31:11 Couple things that have been suggested 18:31:13 a) rolling (10 block) reorg depth — to prevent reorgs beyond lock period outputs 18:31:15 b) hybrid POW+POS (pow favored emission 10:1) "proof of staking pow coinbases" — to eliminate a 51% attack on either side of the network 18:31:17 c) miner signed coinbases, with 10% going to miner and 90% to whereever you want (pool payouts etc) — i'm not sure how this would effect an adversary. might hurt unattended botnets, but afaict would actually put us in a worse position _today_, since typical botnets are one of the main reasons cutebitc doesnt have 50% 18:31:19 d) delaying part of the payout on pow emission — incentivizes hodling, but if the coins eventually unlock, i dont think this makes any difference? 18:31:21 e) tee block producers 18:31:23 d) firo and dash have "chainlocks" but iiuc, require masternodes 18:33:52 its not just orphan blocks, you should see some small reorgs (as opposed to just two competing blocks) 18:34:10 `typical botnets are one of the main reasons cutebitc doesnt have 50%` < botnets can sell hashrate on MRR too 18:34:46 if the conditions aren’t correct, then yes they are just wasting energy 18:37:53 Qubic hashrate jumped to 2.5 GH 18:38:05 Qubic doesn't seem entirely profit-motivated...does this help prevent attackers who want to take down Monero? (is that a likely threat?) 18:38:52 lol why wouldn’t they be profit motivated? 18:38:59 > d) delaying part of the payout on pow emission — incentivizes hodling, but if the coins eventually unlock, i dont think this makes any difference? 18:39:01 Qubic doesn't seem entirely profit-motivated...does this help prevent attackers who want to take down Monero? (are such attackers even a likely threat?) 18:39:03 where did you get this information? 18:39:37 I meant right now wrt XMR, since they're sacrificing XMR rewards in the short-term for long-term marketing/PR 18:39:58 long term it's profit by trying to become 51% so they are the only profitable pool 18:40:02 mind you the argument for the selfish mining attack is that they are able to squeeze out slightly more revenue than their peers, creating a downward spiral where more people move to that chain 18:40:12 Problem with a) is that a new node syncing, encountering a chainsplit >10 blocks deep, wouldnt know which side of the chain to follow. I dont know if i see this as an issue, as this is already an issue with sybils and can be worked around by using trusted peers (or seeds) to pull get on the correct chain 18:40:13 b) people don't like POS, but i think this is less POS and more Proof of POW, since you cant "buy-in", and cant stake coins that have been spent. 18:40:15 c) explained above 18:40:16 short term they are effectively wasting waaay more 18:40:17 d) explained above 18:40:19 e) no comment 18:40:21 d) no comment 18:40:23 *that chain -> that pool 18:40:39 Vtnerd: https://explorer.jetskipool.ai/xmr-tracker.html 18:40:57 vtnerd: not what is seen according to tracked data 18:40:59 the othe problem we have today, is that wirh orice falling, monero "profit" falls, and likely the hashrate will too 18:42:35 Yeah, it doesnt look like any miners are migrating. similarily though, zephyr has more randomx hashrate than monero, and miners didnt migrate. but botnets came online to mined it for profit 18:42:43 Had* more 18:43:21 Is this dashboard accurate? 18:43:37 I thought >33% of the network hashrate spells trouble 18:43:51 no 18:44:26 I think the 2 GH figure seems accurate that has been reported so far today 18:44:30 the global hash is greater than 5.57+2.27 18:44:40 Based on the blocks they are finding 18:44:45 the red line should be at 5.57 right 18:45:43 33%+ means (assuming the selfish mining paper is correct), they can get slightly higher returns than the “standard” model predicts. the reorgs are small so they don’t hurt exchanges, etc. 18:46:25 theres some variability on the rate of return, because the propagation of the network comes into play 18:46:40 The non-qubic hashrate is 5.57gh. Adding qubic is 5.57+2.27 18:46:41 Oh wait, maybe those #s are correct then :P lol 2.27/7.84=28.9 18:48:42 the confusing part is that this qubic operator publicly announced it in such a way that it (likely) had an effect on price. the selfish mining attack/paper still kind of expects a return to be made on this time 18:49:46 i think some of the price falling comes from the loss of buy pressure from moneroocean. Even if not a lot, it was 24/7, sustained buy pressure 18:51:12 But also i think there are likely multipke entities taking advantage of the opportunity to "strike while the iron is hot", using "opening" from qubic to pile on 18:51:28 me being the pessimist, given the wild claims about qubic ai and “proof of useful work”, this person had some other motives … 18:52:00 and actually now that I think about it, if you are bold you short the coin and just keep “buying” at the lower price whether its through mining or straight exchange coins 18:52:29 could you spell those motives out for me, I don't follow 18:52:34 no one really pushed back on the claims of ai+useful proof of work from what I saw, so this just keeps going on and on 18:53:05 also the bot armies 18:53:09 push qubic up, monero down. I don’t know much about this person to say anything further 18:53:11 Their code isn't even open-source, it's under the "Anti-Military License" 18:53:53 rumor is they are from bytecoin, or at least one of the relaunches of it 18:53:58 The Aigarth thing *looks* to be a bunch of hype that's trained away from public view, but idk for sure 18:54:22 They probably use it to post twitter comments lol 18:54:57 I wouldn’t give them that much credit, the bytecoin authors figured out how to use linkable ring signatures and ECDH (stealth addresses) in a novel way 18:55:26 I guess merge-mining to attack another coin is somewhat novel, but less so than bytecoin imo 18:56:23 a lot of it looks like a way to (1) generate hype from the AI and crypto bubbles and (2) establish a moral high ground with "ethical AI" and misleading claims about energy consumption 18:58:44 google ai is telling me that aigarth is attempting agi, which is big news because llm _probably_ wont achieve it 18:59:43 lol how did you go from ai hype to trying to dump on monero, what a world 19:00:03 I guess the latter got way more press 19:00:11 if, as an investor i expect a 100x bubble to form, i am willing to take some losses mid term... the dynamics are well known and carried out by professionals who design meme coin crazes 19:00:13 As if this random token is going to outsmart the billions invested in both US and Chinese tech giants 19:00:26 and the numerous academic institutions out there 19:02:00 in hyc's logs (https://github.com/monero-project/research-lab/issues/102#issuecomment-1528812041), the period that covers the current protocol version (2022-08-13--2023-04-20) has an average ~0.1% orphan rate. people are overreacting at the current 0.4% as if things are okay only if there are no orphans. 19:02:58 reorgs or orphans 19:03:09 I thought GPUs where best for AI stuff anyway, don't know why they are targeting RandomX which is for CPUs 19:03:11 he seems to be talking about reorgs in that comment 19:03:23 I thought GPUs were best for AI stuff anyway, don't know why they are targeting RandomX which is for CPUs 19:03:59 https://docs.qubic.org/learn/aigarth/ 19:04:31 basically, they are claiming technology which has yet to be explained 19:05:41 they do have some strange decisions...the licensing is non-standard (explicitly anti-military), nodes are EFI executables and don't run on an OS, 2 TB of RAM is needed, contracts are apparently made with a limited subset of C++...some amount of thought was put into Qubic, albeit very strange thoughts? 19:05:49 Because everything on the internet is true 19:06:54 I summed up what monerod reported as the "alternative blockchain size", almost always 2. maybe I was wrong and that means only 1 orphan per event? 19:06:55 after further thought, an orphan is reorg’ed from the perspective of the “other side” of the network 19:06:57 "truth: we just mine monero, and produce qubic out of thin air" probably "also, the only ai we use, is for the bots that we use to generate 98% of the dicussion. Even my pfp is ai" 19:07:52 2 means 19:07:53 001 orphaned 19:07:55 001 002 replaced it 19:08:16 001a 19:08:17 001b 002 * 19:09:17 I just looked into his post. he’s talking about reorgs from his perspective. there may have been more, its just that he was on the winning side of the reorg 19:10:20 as in, hyc reported 0.1%, but that was 0.1% reorg from his perspective, not necessarily the total number of reorgs during that period 19:11:11 and [chaser](https://matrix.to/#/@chaser:monero.social)people thing there should be 0? yeah with 2min block time the probability goes way up (dont know how much, but certainly higher than btc) 19:13:00 does that mean that, to have a realistic measurement, you'd need to collect data from have multiple nodes in diverse locations, and merge the registered reorg events? 19:13:48 A rough estimate would be to double that 0.1%, assuing no deliberate bock withholding during that time, right? My web app is showing what the `get_alternate_chains` RPC provides. That gets alt chains and orphans that did not necessarily cause a "re-org" according to my node. In other words, when my node sees a block that eventually wins the contested chain, the log won't say "re-o rg", it will just say an alternative block was received, AFAIK. 19:15:08 [chaser](https://matrix.to/#/@chaser:monero.social) I believe so, for a baseline. because if you happen to direct connect to a pool, you’re going to get those blocks first, whereas someone else may see it from another perspective 19:15:44 and this is just the standard everyone competing scenario. the selfish mining changes things, but propagation is still important (the paper claims so) 19:17:31 Alt blocks are discarded by the node on a restart, but `--keep-alt-blocks` as a startup flag will keep them through a restart: https://docs.getmonero.org/interacting/monerod-reference/#testing-monero-itself 19:19:47 Otherwise you have to be connected to every node 19:21:01 Don't alt blocks still propagate if they achieve the required PoW, regardless of how out of date they are? So the blocks should still be accessible by RPC, if not the log. 19:21:16 If i am solo-mining, and only have 5 peers, and a mining pool with 1000 peers sends their block out to 200 other miners, chances are that nobody is mining on top of my block 19:21:38 And my block will be orphaned, and most of the network wont even know it exists 19:21:52 This PR by jeffro256 would change that behavior AFAIK: "cryptonote_protocol: ignore fluffy blocks past certain depth" https://github.com/monero-project/monero/pull/10023 19:22:12 Only if you see them by connecting to a peer who has it, iiuc 19:23:30 Hmm 19:26:26 it doesn’t get relayed if doesn’t goto “main chain” 19:27:14 so someone would report it, but nodes running standard clients wont propagate it further until confirmed pow to be best 19:37:33 is it safe to accept Monero using selfhosted BTCPay and monerod fullnode? 19:37:35 should any action be performed considering this attack? 19:37:41 hello by the way :) 19:39:47 we are first telecom that accepts Monero and huge XMR holders. 19:39:49 we have two networks and some servers, but they are not free to mine Monero. 19:39:51 can we help Monero team some other way except buying above 200$? 19:40:11 You'll want to inspect your confirmations amount, the suggested numbers haven't really changed 19:42:06 10 confirmations is enough? 19:42:07 how safe is mainnet now? 19:42:09 I see less than 0.5% orphans and having thoughs that all habbwning today is all about media shitspam and not actual takeover, but what’s Monero team standpoint? 19:43:05 mainnet remains safe. 10 confs remains safe 19:43:51 any countermeasures ongoing? and maybe some bounties by core team? 19:43:59 For this to change, the attackers would have to obrain 51% of network hash and roll back the chain by over 10 blocks, as well as replace them wirh empty blocks (or refuse to mine your transactions) 19:44:22 https://matrix.to/#/!zxoYuvZdPYtIuWSQnn:monero.social/$FNii6AI92_PclVkezeJIWGhJUNYRcbMBWGhuYuQsUNw?via=xmr.mx&via=matrix.org&via=monero.social 19:44:36 annelinlol: Qubic hasn't really increased its hashpower share in the last one or two weeks. They are doing different annoying things with their current hashpower, but nothing that affects the security of confirmed transactions. 19:46:30 There is no evidence of any successful nor attempted double-spends by qubic or anyone else. 19:46:53 you can only double spend your own spends anyway 19:47:05 And you would be able to see that, contrary to some myths that have appeared. 19:47:42 Some people don't know about key images work? Damn, what a show 19:48:20 they claimed that they succeed 51% attack and voluntarily stopped but it looked like very fake and bait to panicsell over all the media 19:48:24 you can enable dns checkpoibts if that makes you more comfortable 19:48:34 The most number of blocks they have re-orged is 2 so far. And it is (roughty) exponentially harder to re-org more blocks. 19:49:02 They claimed 51%? Do you have a link? 19:49:21 Are they being ddosed or are they actually just dropping off again 19:49:23 theyve claimed 44%+ over and over on twitter 19:49:26 Rucknium: was it them? I guess they'll claim it either way 19:49:33 I thought they stopped after their pool got "ddosed" 19:50:06 The 2 block reorg was "unknown" pool 19:50:35 The 2-block re-org at height 3,472,097? I am pretty sure it was them. 19:50:48 i really think theyre doing what i described the other day. "dark" mining 19:52:25 i think a mitigation for normal pools would be to peer against one another 19:53:00 Where did you describe dark mining, can't find it 19:54:10 Here 19:56:25 it’s strange, but post from shitter about “we are stopping attack at XMR 250$” is either disappeared or i just cant find it 19:56:56 https://x.com/Krash_AK47/status/1953529103908212907 19:57:59 also https://x.com/Qubic1000X/status/1953382905209913491 19:58:09 orig https://x.com/c___f___b/status/1953350025783742513 19:58:31 so all of their shit not affecting mainnet currently as I see 20:00:29 He changed his mind and said that he'd continue the attack id price fell 20:01:01 I think the price is someone else taking advantage of the environment to liquidate some longs and create fear 20:06:57 I see the fear. But is that threat real or its just panicsell? 20:06:59 I have some tasty orders at $200 just for myself. If someone needs to sell $XMR Im here 20:09:30 Now XMR moving out from the weak hands. 20:10:37 I don't think its a panic sell. I think its a "coodinated" effort to create fear, except i dont think cfb is behind the selloff 20:11:13 Both 20:11:16 cfb likely wanted the price to remain high, so he can keep the cost of his attack as low as possible 20:11:38 Nah, i think triggered liquidations are more likely and panic sell 20:11:59 Not much liquidations on binance perp 20:12:03 Likely than* 20:12:33 its all about advertising their another shitcoin by “we took monero network” 20:12:52 Someone dumped around 276 and then panic sell/sl triggered 20:13:03 and the price is clearly shows panicsell in range 260-240 imo 20:13:12 This 20:14:45 if mainnet remains safe and all their fud will be thrown to /dev/null, there is 99% possibilty that we’d restore 300+ levels 20:14:59 We can cont liq talk in markets, i just wanted to mention that i dont think the selloff was intentional by cfb 20:16:25 It may not be cfb, but his actions don’t help xmr price 20:17:10 If he was worried about xmr price he wouldn’t be attacking xmr publicly 20:18:26 Anyways we need a decade to bring price importance into monero ecosystem 20:18:38 Last decade was don’t buy monero 20:19:42 anhdres explained it nicely at monerokon 20:20:18 Ah fuck, sorry didn’t notice this was mrll 20:20:40 Send invite pls 20:21:04 He was referring to Monero Markets 20:48:18 More like "ofrn pretends to rob a bank, and someone else actually starts robbing it" 20:48:23 if it gets us to add significant hashrate, it should 21:01:33 @rbrunner @rucknium one thing i wonder now, is that peering /connectivity of mining nodes can be gamed to get an advantage - or can be worsened by default 21:02:45 with respect to selfish mining? or some other thing? the original paper graphed out different propagation statistics and the reward based on that 21:03:13 meaning, a node that is multiple hops away from a large mining pool (who likely is very well connected), means a higher likelyhood of your block becoming the one that is reorged out 21:03:13 poor connectivity by the selfish miner hurts their chances slightly, etc 21:04:38 that's why p2pool blocks get re-broadcasted by all miners 21:04:47 Poor connectivity by average miner is the problem. I think its worth studying the network topology to try to discover how many proxies qubic is running 21:04:47 yeah I mean ruck may be know some of the stats offhand, but good connectivity is desired for a miner. but typically there arent two blocks mined that close together 21:04:52 block transmission is very quick 21:05:10 yeah p2pool also recommends peering to supportxmr and hashvault 21:05:20 plus seed nodes are also attached to other major pools so they get blocks quick 21:05:51 i imagine qubic also does this 21:07:45 We probably should relay new alt blocks the same as new main chain blocks 21:08:17 but which should we mine on? First come first serve? 21:09:03 Yeah, the same as we currently do but when we get an alt blocks that is new we relay it to peers 21:09:14 why would we do that? that seems detrimental 21:10:21 Because nodes that don't get the alt block need to sync it if that chain wins, slowing down block propagation 21:12:30 what would the parameters be? you can just relay any alt block, as someone could spam the network with super old blocks, etc. I just don’t know, doesn’t seem like its solving any issue 21:12:32 *cant just relay any alt block 21:14:41 In cuprate we accept relayed blocks that are within 10 of our chain height so any alt block out of that range is ignored anyway 21:15:53 Yeah its not solving an issue really but it would speed up block propagation in a reorg to reduce wasted hashes 21:17:16 I would also call for only checking the PoW before relaying and then checking the block is valid 21:18:05 As a block full of unknown txs coupd slow block propagation quite a bit 21:18:45 Bitcoin does this fwiw 21:19:11 relay before checking rest of block? are you sure? 21:20:18 my initial reaction is that I don’t agree with either suggestion 21:21:12 the one altchain thing probably helps selfish miners, as per the graph from the original paper 21:23:26 https://github.com/bitcoin/bitcoin/pull/9026 21:23:38 https://github.com/bitcoin/bitcoin/pull/9375 21:24:45 I think this is going to be more necessary when txs could take like 1s to verify with FCMP 21:24:48 hey, dumb question...does selfish mining require that blocks are transmitted with a delay? 21:25:13 Have a block full of them which we haven't seen before and it could take a while for that block to propagate 21:25:25 There's a private chain being created, yes 21:25:33 (is this the appropriate chat for dumb questions) 21:25:43 The last message was to CountBleck: 21:27:35 For those lurking, the last two boog90mess0: messages were for quicker relaying of mainchain blocks, the alt chain suggestion is separate from this 21:28:10 Could there be a way (in node implementations) to disincentivize keeping blocks private? 21:29:00 (or is that what was being discussed earlier?) 21:35:57 I'm not aware of any counter measures beyond running fairly standard blockchain rules. Maybe someone wrote a response, I can look 21:36:10 I don't know specific numbers about empirical block propagation time off the top of my head. Older numbers for txs were: 21:36:11 > About 50 percent of all transactions arrived at all five Monero nodes within a two-second interval. 95 percent all transactions arrived at all five Monero nodes within a five-second interval. 21:36:15 https://rucknium.me/posts/monero-pool-transaction-delay/ 21:38:30 The disincentive is built in: If you keep blocks private, your private block is not being built upon by other miners, so you are less likely to have your blocks (and their mining rewards) be part of the main consensus chain. This disincentive only reverses if the mining pool has about 33% or greater hashpower share. 21:39:45 didn't bitcoin cash attempt to implement something to protect against this? avalanche? i don't know if it actually works or isn't permissioned, but i remember they put effort into defending against 51% attacks for obvi reasons 21:40:17 so once 33% is exceeded, that disincentive disappears; understood 21:40:25 rucknium 3,472,934 is listed as unknown pool on moneroconsensus, it is pool.xmr.pt which is a small pool 21:41:07 gingeropolous: IIRC, Bitcoin Cash ABC (now eCash) has implemented Avalance. It is "pre-consensus" of blocks based on the mempool, AFAIK. 21:42:24 nioc: Thanks. If I could write Go, I would edit `monero-blocks` to pull from the .pt API. I don't want to burden Data Hoarder. 21:44:01 By the way, my task to estimate unreported hashpower share is stalled. I wrote the suggested algorithm and it doesn't converge. I don't know what the problem is. I will contact the author to see if she has the old code available. The code is probably in R, so no problem there :D 21:45:47 https://www.sciencedirect.com/science/article/pii/S2405959522000443 21:46:36 Someone suggests spying on the selfish miner lol. No other comment so far, just that people have been writing about countermeasures a bit 21:47:32 I'm guessing this event is going to inspire research of some sort 21:48:02 actually sentence is a nothingburger 21:48:09 actually that sentence is a nothingburger 21:49:33 ...so by publicizing blocks the whole selfish thing would fall apart...what's the downside? Doesn't sech1 have access to the blocks 21:53:48 I don't know what sech1 is doing. The selfish pool has to provide a template, which includes the hash of the prior block. So you can observe when a private chain is being used 21:59:09 23:40:25 rucknium 3,472,934 is listed as unknown pool on moneroconsensus, it is pool.xmr.pt which is a small pool 21:59:16 yes, not all pools are added to the script 21:59:41 see https://git.gammaspectra.live/WeebDataHoarder/monero-blocks which ones are tracked 21:59:55 CountBleck: you asked the downside of selfish mining? My best guess (since I've never tried) is making sure you have accurate numbers. If you don't, you are clearly just wasting CPU cycles 22:00:01 That's all correct, but it doesn't make sense to mine on top of an unknown block hash because your own node will not accept your mined block 22:00:04 given it has a standard api should be fairly easy to add 22:00:49 I think I misunderstood you guys 22:01:27 I thought "spying on the selfish miner" was "covertly obtaining the full blocks from the miner due to some oversight", like (what I thought?) sech1 was doing 22:01:29 And relying on what the selfish miner shows (block hashes) is dangerous because they can force you to mine on a complete rubbish hash, removing you from competition entirely 22:02:39 sech1: Would you say that goes double for when the selfish miners does not have >33% hashpower share? In that case, you would be mining on a chain that has a greater probability of being orphaned. 22:03:26 sech1 so they give the entire private blockchain to the pool? 22:03:47 I think I misunderstood you guys (and I expressed myself ambiguously) 22:04:24 Maybe we don't want to give up our info advantage, but certainly some things to think through that the original paper kind of glossed over (including price fluctuations, etc) 22:04:55 they give block templates to pools. There is just one (possibly two, data is unreliable) nodes which run the private blockchain when they're selfish mining 22:05:57 DataHoarder: thx, they only find a couple of blocks a week 22:06:19 given it's nodejs-pool I'll just make that the generic case that MO for example can also use 22:06:22 seems to work fine 22:06:31 no new code, only new entries 22:07:18 nodejs-pool? 22:07:34 oh nvm that was the tiny pool from earlier? 22:08:47 nodejs is the software 22:09:04 implementation 22:09:29 I just didn't know there was Monero pool software written in JavaScript 22:09:54 It looks kinda abandoned 22:15:21 I've considered adding a plot or table to moneroconsensus.info to detected re-orgs that could be double-spend attacks, but qubic could just double-spend transactions to itself to make it look like there was a double-spend victim, but there would be none at all. 22:18:28 Thanks, DataHoarder. I'm running the code with the .pt pool added. 22:18:58 wait, there's more coming 22:19:19 Great :) 22:31:56 Great more ammo for them to fud 22:46:22 update now, added 9 more pools 22:46:35 see https://git.gammaspectra.live/WeebDataHoarder/monero-blocks/src/branch/master/main.go#L34-L76 22:47:04 I'll probably add a field for "miner attribution" to show any partial or full XMR address as found 22:47:15 some pools report this, so it could be interesting 22:48:14 🚀 22:48:48 Awesome. Running it now. 22:49:24 it'll backfill old data probably :) 22:50:35 if you find any issues with this generic fetching poke me, I bundled all nodejs-pool and cryptonote-pool into the same fetcher type 22:51:17 ... except supportxmr which serves the "ts" and "reward" as "numerical strings" (a number inside a quoted string) 22:51:33 so that has a fallback 22:53:34 also, you can probably color code the top 3 pools or so 22:53:43 then bundle all p2pools into one 22:53:49 show ALL the colors! 22:53:55 instead of green/red 23:25:28 On the topic of enforcing solo mining by having miners sign with their private key, many people are convinced it is not a viable approach and that there are workarounds. From what I understand of the method Wownero used, workarounds were possible in their case. That said, I would appreciate some input on what might be a more robust approach. 23:25:35 The objections I have heard are only valid because signing and PoW are easily separable operations. If the signing is thoroughly integrated into the PoW itself, included directly inside RandomX, I think the objections are moot. 23:26:10 After some reflection, this is what I came up with (I imagine something like this has already been discussed elsewhere): The message that is actually signed is a very lengthy product of expanding the RandomX state. An example might be a long concatenation of hashes. So in order to sign, you either need to perform significant work yourself of receive a very lengthy message. 23:27:16 If the length of the signed message is bandwidth prohibitive, and the work of expanding is too much for a dispatcher, I believe the scheme holds. 23:34:19 I guess you could simply perform an expansion on the nonce by itself and get something similar. Will have to think on it a bit more. I did find the general idea compelling, at least I do not see how the objections I have heard would apply to it. 23:35:03 *nonce + block height, etc