00:00:01 Does "aggregation interval" mean "the number of hours used to determine each datapoint"? 00:00:43 If so, why does the 24 hour setting have only three datapoints? 00:00:52 CountBleck: Yes 00:01:02 I see the 6 hour one starts at August 8 but not the 24 hour one 00:02:06 I would expect graphs with higher aggregation intervals to display a wider range of time, to maintain a similar number of data points 00:03:50 The data starts August 8 at 12:00 UTC because that's when data with the most number of mining pools started to be collected, thanks to updates by DataHoarder: https://git.gammaspectra.live/WeebDataHoarder/monero-blocks 00:03:54 because right now the 24 hour one looks pretty flat 00:04:05 ah, understood 00:04:38 Thanks for the feedback. I will clarify in the `` 02:42:15 [@elongated:matrix.org](https://matrix.to/#/@elongated:matrix.org) I'm talking about poisoned outputs... Thought I was in the right room... https://youtu.be/iABIcsDJKyM?si=HitNoNYrn2JRD6V1 02:44:05 Well it's on me for not using the correct term I guess, anyways has anyone done that? No tradeogre wallets have moved but we don't know about XMR ones 02:45:37 [@elongated:matrix.org](https://matrix.to/#/@elongated:matrix.org) I'm talking about poisoned outputs... https://youtu.be/iABIcsDJKyM?si=HitNoNYrn2JRD6V1 02:49:17 And TO guys don’t know about it ? A few hops and it’s not traceable 02:51:19 Yep but just knowing that they did 1 hop after being offline is enough 02:51:38 If they move any of the funds it pretty much confirms an exit scam 02:52:11 You don’t know if they moved it or it’s a decoy 02:52:54 Using the method I linked you can guess with a high probability 02:59:06 Go watch it again 04:45:37 I've been trying to think through some of the downsides associated with moving to Proof of Work plus Proof of Stake consensus. I saw kayab mention that if 34% of validator stake goes offline or doesn't come to consensus to finalize blocks, then it is effectively similar to a denial of service attack on the network. No transactions get through with finality, so it is similar to an empty block attack. If PoW + PoS gets implemented what measures could be put in place to reduce the likelihood of a bad actor or motivated attacker from getting 34% of the stake early on right when this change is deployed? Seems like if a motivated attacker wanted to, they would just need to be one of the first to stake a lot of Monero to validate. Maybe slashing would get around this? I'm not very familiar with how Proof of Stake works, so I'm just thinking through the weak points with that possible idea. 04:47:31 I know ofrnxm mentioned that his proposal would be that only coinbase (freshly mined) monero could be staked. That would require a motivated attacker to first mine a bunch of Monero, then stake it, so I guess that would be one barrier of entry. Whereas without that barrier they could just buy a bunch of Monero and submit themselves and their Monero as a large portion of initial st ake to validate transactions. 04:50:57 Mentally I'm trying to grasp in as clear and simple terms as possible what are the largest risks associated with shifting to PoW + PoS, as well as what the clear benefits are. It appears that two main benefits would be greater protection against deep reorgs and hence double-spends. But perhaps a finality layer by itself wouldn't protect against empty blocks being proposed by PoW m iners. It also appears that moving to a PoW + PoS system with a finality layer would enable to the removal of the 10-block lock. Just curious if people who better understand the proposals, and Proof of Stake, could clearly explain some of the risks and benefits? I'm not entirely sure what to make of it yet. 12:29:43 What about triple pow ? Randomx/mergeminewith-ltc/sha3 12:29:45 40:30:30 13:37:01 https://www.openssh.com/pq.html 13:37:27 OpenSSH Post-Quantum Cryptography 13:37:29 >More recently, in OpenSSH 9.9, we have added a second post-quantum key agreement mlkem768x25519-sha256 and it was made the default scheme in OpenSSH 10.0. 13:38:29 >all the post-quantum algorithms implemented by OpenSSH are "hybrids" that combine a post-quantum algorithm with a classical algorithm. For example mlkem768x25519-sha256 combines ML-KEM, a post-quantum key agreement scheme, with ECDH/x25519, a classical key agreement algorithm that was formerly OpenSSH's preferred default. This ensures that the combined, hybrid algorithm is no wor 13:38:31 se than the previous best classical algorithm, even if the post-quantum algorithm turns out to be completely broken by future cryptanalysis. 13:38:51 most important point 14:19:13 Here's the Qubic full restore key for that view key earlier: https://xcancel.com/c___f___b/status/1954837460686414187 14:19:15 `hold threaten vector point lawsuit vein nestle much scrub bowling smash pizza howls strained afoot vary elapse nimbly trying sugar bubble jazz sailor soggy afoot` 14:19:30 The wallet's been swept of all coins, of course. 14:21:19 To the "Blocks mined by mining pools" tab of https://moneroconsensus.info/ , I added text about what a malicious party can do with majority hashpower share. 14:21:21 Tell me if you disagree with anything I say there. 15:09:44 are we super unlucky right now? 15:12:19 seems like it 15:12:37 imagine not having zeroconf and waiting 15 minutes on a block twice in a row 15:13:31 uhm 15:13:35 was that the biggest reorg ever just now 15:15:03 Looks like 4? 15:15:43 3 15:16:19 we had 3 before 15:16:35 makes sense that they can do 3 with 30% of hash 15:16:54 Oh yeah 3 15:17:04 ok so no smoking gun 15:17:36 Ruck, your site is very cool 15:27:36 17:09:44 are we super unlucky right now? 15:27:40 unlucky + lucky 15:30:12 See my "Table: Duration of meta attack to achieve attack success probability of 50 percent" https://github.com/monero-project/research-lab/issues/102#issuecomment-2402750881 15:30:13 If they have 30% of hashpower and they are continuously trying to re-org 3 blocks, we would expected that it takes 45 minutes of pursing that strategy to achieve a 3-block re-org with 50% probability. 15:30:48 Of the last 21 orphans, they have won 20 of them. 15:31:25 They don't broadcast chains that they lose. 15:39:15 It looks like they are not mining empty blocks now? 15:44:49 https://xcancel.com/c___f___b/status/1954926476958028186 15:45:12 that includes fails that don't seem to be on https://moneroconsensus.info ? 15:45:27 self hosting ig 15:52:53 Interesting. Yes, possibly self-hosting it on a node that gets their failed attacking chains. I licensed it AGPL, by the way. 15:53:34 In the repo I haven't included instructions of how to add the `monero-blocks` info, but it should be obvious enough. 15:55:12 I would encourage people to self-host because moneroconsensus.info could start refusing connections or becoming very slow if a lot of users connect simultaneously. 15:56:35 I will write some more deployment instructions soon. 16:06:40 I want to share my thoughts here before posting on the github issue, but I think tevador's proposal 98 to bolster p2pool will primarily harm small miners more than it will harm pools. That's potentially fine depending on the tradeoffs considered, but I figured this would be useful to write up for discussion: https://gist.github.com/SamsungGalaxyPlayer/892472b28fa2ed92db47f51678637f87 16:10:44 I zoomed in on the image: the top block says `Pool: QUBIC` 👀 16:11:32 hmm good spot 16:12:10 wonder why the others are not flagged as qubic 16:13:13 the person could have edited the html 16:14:09 you would think they would do at least the other 3 in the main chain tho lol 16:14:50 half arsed the marketing material 16:17:58 If they are secret chains, their infrastructure might not communicate fully. 16:18:41 It's a PNG file, not HTML. If you self-host you could easily edit the CSV file that the Shiny app pulls data from, of course. 16:21:13 https://github.com/tevador/bc_selector 16:37:10 Hi tevador, it's good to see you're back 16:47:07 Hi 16:54:38 tevador: did you consider every RandomX hash sampling RingCT outs, and their SHA hash being the hash used for pow? 16:55:11 (Instead of cache building off blockchain data once every 64 blocks) 16:56:14 (So IO scales with hash power) 16:56:35 Also, of course, great to see you again :) 17:28:56 The current proposal minimizes changes in RandomX and mining software. It basically boils down to replacing calls to randomx_init_cache by a daemon RPC call. Doing online disk IO would be much trickier. 17:59:12 https://x.com/c___f___b/status/1954823638022037733 which monero team is working with cubic ? 18:04:41 Fair re: minimizing changes. 18:05:46 elongated: Probably none? They've made a lot of definitive posts with authority they (or even no one) has. 18:06:08 Unless they're arguing they themselves are now 'Monero team'? 18:10:55 can official twitter account please say "no we aren't" 18:24:02 i wish merge mining with tar woulda worked out better 18:24:05 tari 18:26:27 someones just gotta launch a monero merge mined NGU crypto. use the standard scamcoin playbook for it - pay to get into exchanges, market makers, marketers, influencers, etc etc 18:28:43 or use the same resources to buy up the books on exchanges. 18:30:26 in essence i feel this is an economics problem. 18:37:19 I wonder if doubling the blocktime to 4 minutes would do anything useful 18:38:48 i mean, its like, 51% attacks are inevitable in a permissionless PoW network, so how can you make them more tolerable and survivable. 18:39:48 staking finality != permissionless, afaiui . 18:40:17 Well there is dark.fi ... Maybe not the NGU scamcoin you are hoping for but maybe it works out better than tari 19:04:39 when Is darkfi launching? :) 19:05:37 never 19:05:54 i mean, when middle east become stable 19:05:56 which means never 19:06:13 i swear this is relevant to darkfi 19:11:18 Why Monero don't use a selfz 19:11:27 a selfz? 19:12:56 Why Monero don't have a self-hosted repo in Gitea or GitLab with a .onion link? Github sucks* 19:13:24 My wifi sucks too :3 19:13:25 https://www.theverge.com/news/757461/microsoft-github-thomas-dohmke-resignation-coreai-team-transition 19:14:07 I should really get librejo.monerodevs.org up and running gosh 19:14:16 postgresql was the biggest mistake of humankind 19:15:11 Yeah IDK what's wrong with it at the moment, but it's throwing a bunch of 500 internal server errors 19:15:51 postgresql is corrupted 19:15:57 and i haven't find the time to investigate 19:16:17 one thing im sure is that once its restored im gonna migrate to sqlite 19:42:57 <321bob321:monero.social> Better then mariadb 19:53:00 I think the only software I ever used that used mariadb was metasploit 19:53:12 and everything make sense 20:50:00 I had no idea librejo existed, it's a really important tool, thank you. 20:50:01 By the way, the other day I was asked about the progress of the new official Monero website (getmonero.org). 20:50:03 I even tagged you there. 20:50:05 https://www.reddit.com/r/Monero/comments/1mk9kg5/any_update_on_the_new_monero_website/ 20:50:53 I had no idea librejo existed, it's a really important tool, thank you. 20:50:55 By the way, the other day I see a post was asked about the progress of the new official Monero website (getmonero.org). 20:50:57 I even tagged you there. 20:50:59 https://www.reddit.com/r/Monero/comments/1mk9kg5/any_update_on_the_new_monero_website/ 20:56:31 If you need help with the rewrite, then I might be up for it 20:56:45 You are the fourth then 20:57:00 progress have stalled because designer got extremely busy 20:57:01 the fourth person to offer? 20:57:06 but there should be room for a meeting 20:57:19 to offer their help for the rewrite yeah 20:57:46 I *might* get busy too (I'm a high schooler and college app season is approaching) 20:57:59 but I *might* be able to offer some help 20:58:06 everyone is dw 20:59:57 I just joined https://matrix.to/#/#monero-site:monero.social; is that the right place for me to lurk? 22:30:32 https://www.reddit.com/r/Monero/comments/1mnjmpb/some_exchanges_are_following_traditions/ 22:30:33 Well, CEXs don't have much influence on Monero, and that also means that they won't have much influence if Monero has a hybrid PoW+PoS system. 22:30:35 Honestly, so far Monero seems to be the only cryptocurrency that would have a fair PoS system, because there are no big companies with a large centralized Monero stock, I think Qubic is being great to see where Monero can improve, sometimes something bad comes to make things better. 22:55:37 Did we just have a 7 block reorg? 22:56:27 https://moneroconsensus.info/ just loaded and yes we did 22:57:53 Impressive 22:58:45 yeah I think that is a new record 23:03:22 I had a tx with like 3 confs lol. Seems to have returned to my wallet 23:03:53 goddamn 23:04:02 Dayum 23:05:22 Lets see if i can respend 23:05:52 i wonder if its back in my txpook. I didnt make note of the txid 23:06:41 ofrnxmr: I think they are doing what you said and disconnecting their node, the last 4 blocks had no txs which makes me think they emptied their pool with the first 4 23:08:23 anyone running a public node and has logs of an IP connecting right before sending you 8 blocks that caused a reorg? 23:08:55 Im runnin on level 0 :/ 23:09:02 I'll switch to lvl 1 23:09:14 I see 6 blocks with no txs 88-93 23:09:14 https://explorer.jetskipool.ai/xmr-tracker is looking a bit interesting 23:09:48 I got a lot of 23:09:49 ``` 23:09:51 2025-08-11 22:52:42.977 E Transaction spends at least one output which is too young 23:09:53 ``` 23:09:55 Right before the reorg 23:09:57 ruidx I only counted the blocks that caused the reorg, but yes 23:10:28 Hold on, looks like back to back reorgs 23:11:32 Nvm, same reorg (alt blocks -> spends too young spam -> reorg) 23:11:37 yeah this probably happens because your node pops blocks off the top of the chain to do the reorg so new txs will look like they are spending outputs that are less than 10 blocks old 23:12:57 Breh, my logs look like shit 23:13:14 Reorgs every 10 mins all day 23:13:39 Nakamura was a fucking genius 23:21:40 My tx reappeared in my wallet, and has 1 confirmation now 23:22:13 Another reorg 23:22:33 https://matrix.monero.social/_matrix/media/v1/download/matrix.org/wBAUfjbIpEwvdKPMZMDRSlud 23:22:38 we got some eyes on gupax 23:23:36 It’s in 9 days actually 23:23:45 is this where centralized pools start peering to each other? 23:23:48 August 20th 1200 UT 23:24:12 is part of the strategy with the empty (or under-filled) blocks that they propagate faster and so have a higehr chance of becoming canonical compared to full blocks? 23:24:24 Tbh yeah, this is the part of the story where they decide to 51% the network in order to keep Qubic out 23:24:31 This is what i meant about increasing fees doesnt help, if all of blocks on the left get reorgd out 23:24:51 Yeah 23:24:52 it was they don't do that anymore tho 23:25:21 some are still empty and others are only like 40 kB even when the mempool is full 23:25:24 And yeah that’s the idea; looking at that deep reorg I wonder if they manually “cut off” transactions at the end 23:25:54 Lyza ^ 23:26:07 Tbh I think they were hoping for a 10 block reorg. 23:26:20 I dont. I think they got 7 and broadcast it before they lost it 23:26:30 probably wouldn't even use a full node jsut to generate empty block templates but yeah still 23:26:32 I think theyll get their 10 though 23:27:00 Hoping; once they saw the rest of the chain catching up they gave up and just accepted the easy 4.2 XMR 23:27:56 Ofrn wishes his node would reject empty blocks if local txpool doesnt agree that the blocks being emoty 23:27:59 Another reorg 23:28:22 Theyre not getting 10 straiggt, but now are about to do 801-810 in pieces 23:28:32 Theyre at 801-801 now 23:28:36 801-808 23:29:07 I guessed yesterday that they have over 50% hashrate and are likely hiding some on centralized pools. 23:29:22 I was wondering about empty (or under-filled) blocks getting a relay rule to delay broadcast but thinking it through, it would just make it harder for other miners to build on those blocks 23:30:23 My idea would be to delay building on them and accept a "better" block as the canonical one ESPECIALLT if the better block was received first 23:31:40 if i wait for you to submit your good block, then i can win with a late subsission of half-assed work, just based on quantity of garbage that i submit, that seems a bit flawed to me 23:32:10 the point of the blockchain and if miners isnt just to build blocks and take emission, its to mine transactions 23:35:33 so the rule would be something like, in the event of a chain split, weigh number of transactions (or fullness of blocks) as well as total PoW? 23:36:24 I was thinking of something like a PoW penalty for underfilled blocks, but the mempool is ephemeral and non-canonical so nodes that aren't online when the chain split happens won't have that info when syncing 23:36:31 Txpool 1mb due to reorgs 23:37:55 Rule would be: if i have a block that has 300tx in it, and some dumbass sends me an empty block to reorg the one im building on, reject the empty chain 23:38:44 A semi-joking, semi-serious proposition: what if we only allowed mining from the major pools *temporarily, until August 22nd or a few days after*. 23:38:53 haha 23:39:32 Wait for their halving to screw over their plans, keep them from earning *anything* in the meantime, and then see where things are at 23:39:33 Downside is, well, I don’t think I need to explain it lol 23:39:53 honestly the easiest solution rn would be "my txpool has 1mb of txs in it. Reject blocks that dont mine blocks that match the scaling, aka 290kb or less atm" 23:40:03 I think this site tells you when they are mining an alt chain: https://explorer.jetskipool.ai/xmr-tracker 23:40:13 there was no block 1 min ago ... 23:40:30