01:05:14 99% of miners stop right before the winning hash 💰 💴 🔥 🤑💲💵💷💶 02:42:12 https://matrix.monero.social/_matrix/media/v1/download/monero.social/hWCRHKuwwfPpvfRZvQteeiTW 02:42:19 don't mean to brag but... 02:43:18 Thats not braggin 02:43:32 heh 02:43:39 Go check your "blocks mined" 02:44:09 Monero blocks 02:44:41 hey I got a couple 02:44:43 Most recent shares 02:44:44 Most recent monero blocks 02:44:46 Most recent likely sweeps 02:45:06 At the bottom of your miner page, check the second one. Have you found any blocks? 02:45:33 3 blocks with my 5950 02:45:46 shown on the p2pool page? 02:46:00 yeah 02:46:14 Thats 1.8xmr 02:46:16 now clock "all historical payouts" 02:46:39 Click*. Did were you paid more or less than 1.8xmr 02:46:42 nowhere close 02:47:22 Thank for playing 🍻 02:47:27 this 5950 has probably only mined a third of that over that period 02:47:28 shoulda solo'd it 02:47:33 This is why i recommend solomining 02:48:08 the main thing re solo is just knowing whether its actually doing anything or not 02:48:50 Unless youre mine blocks, youre not doing anything 02:49:18 Just getting participation trophies 02:49:56 If you need to know that your finding "shares", you can use xmrig-proxy and send a custom difficulty to the miner 02:49:58 so you need some live display of the participation trophies... 02:50:00 that would be encouraging 02:51:15 Xmrig-proxy custom diff shows that youve found "shares". Nothing more encouraging than pressing "s" and noticing that you have a new accepted entry though 02:52:05 yeah nobody I gonna do that. 02:52:06 i mean, 02:52:08 *i* might 02:52:10 but 03:56:44 hardhatter: got the complete picture about block timestamps 03:56:46 * a block timestamp must be greater than the average of last 60 blocks 03:56:48 * a new block timestamp may not exceed 2 hrs above the system time (shoutout to strawberry for the info) 03:56:50 blocks violating these rules won't be accepted 03:56:52 couple that with the difficulty adjustment rules, the monero protocol greatly limits how much you can fiddle with the block timestamps 04:21:46 I just discovered Gitea. What a great tool. 04:36:13 What are people using for data hoarding- archiving websites and videos and such? 04:36:30 https://archivebox.io/ I guess 04:36:50 I run a private instance and it holds well with ~30TiB of data, although I'm sure there are people with much more 04:37:17 Are you using a spinny drive? 04:37:25 30T is a lot 04:37:37 I have 288TiB total 04:37:46 I was hoping for something more similar to Pocket 04:37:52 wow 04:38:03 48*6, six each running in raidz2 so two drives are redundant 04:38:18 (48 drives each 6TiB) 04:38:28 what kind of enclosure/hardware supports that many drives 04:38:52 netapp ds4246 holds 24x3.5". Or 2426 (I think) for 2.5" 04:38:59 To clarify, they are all spinning rust, not ssds 04:39:21 Old enterprise SAS drives for dirt cheap on ebay. ~$7/TiB 04:39:26 Wow that thing is huge 04:39:45 and ++ to the cheap rusties. you may have inspired me to dust off my old hdd box 04:40:10 what's the power consumption on all of that 04:40:28 About 600W total? Along with 2 poweredge R620s running at ~80% utilization and a switch 04:41:06 Costs virtually nothing extra for me, luckily, due to my conditions 04:41:35 you live inside a solar panel 04:41:41 Possibly 😃 04:42:16 Been running them for ~3.25 years or so? Had one drive fail so far 04:42:30 Even sometimes with sudden power cuts before I had a UPS. They hold up really well 04:45:15 I have a pretty basic old tower running proxmox 04:45:33 debating how I want to start doing backups 04:45:50 My servers run proxmox but I've been working on something better for the past 9 months or so. Another few months and it will be ready for beta launch 04:47:57 Depending on the importance of your data, I would back up to another small local server and to a cloud provider (encrypted) 04:48:28 Kopia is a good tool. E.g upload to google (encrypted) 04:49:07 Yeah, I've been looking at doing a second proxmox instance and figuring that part out 04:49:37 If you do, I don't recommend clustering them. Proxmox clustering is a disaster, easier to manage the servers independently 04:49:38 how dumb is it to save encrypted data to g 04:50:04 Not at all. Assuming the cryptography is sound, the only risk would be google removing your data, which is why you have redundancy 04:50:21 Or possibly save-now-decrypt-later but I doubt your data is *that* important 04:50:25 ah that's exactly what I was going to do. That's sad to hear. Have you tried the proxmox backup software? 04:50:44 Proxmox backup server is good, works well. Although just for backing up VMs/LXCs 04:53:45 What kind of inverter do you use with your PV? 04:54:18 I don't know. I did not set it up. 04:56:03 Nice to not have to worry about it. I'm hodgepodging a used system together at the moment. Old panels are very cheap. 05:50:23 Ahh this makes more sense as the average of block timestamps as opposed to the average of block times (the time taken to mine the block). This atleast wouldn’t cause that always increasing block time problem. The average of block timestamps increasing is fine since time is always increasing. 05:50:24 Although if that’s the case the reliability of the timestamp would still be pretty questionable. These measures seem to prevent large discrepancies but not small ones it seems. Small yet impactful ones that could affect the difficulty calculation significantly 06:03:21 Block timestamps aren't meant to be perfectly accurate, they're generated by the pool each time a new job is sent out, meaning they should be slightly behind the actual time the block was mined and broadcasted 06:04:15 If 1 pool is misconfigured or malicious and writing timestamps that are off by an hour, it wouldn't affect difficulty calculation much since it's based on the median 06:20:38 ^ actually not true, the minimum timestamp is based on a median, but difficulty adjustment may not be 06:20:57 I imagine it's done in such a way where 1 pool can't game the timestamps? hold on 06:21:52 I’m thinking about how a large entity or convergent group might say their block times are smaller than they actually are increasing the difficulty. Or they could lie about it taking longer to reduce the difficulty by a meaningful amount. 06:21:52 I mean it would be noticeable to everyone that the block times are skewing off of 2 minutes if that happened. But if that does happen what’s the plan for correction? 06:22:27 I’m thinking about how a large entity or convergent group might say their block times are smaller than they actually are increasing the difficulty. Or they could lie about it taking longer to reduce the difficulty by a meaningful amount. 06:22:28 I mean it would be noticeable to everyone that the block times are skewing off of 2 minutes in reality if that happened. But if that does happen what’s the plan for correction? 06:26:18 For example people could have blocks mined and appended in 1 minute, but put a timestamp with a 2min block time. Publish it and other miners will just accept it early and append the next block because there’s no mechanism to stop that 06:28:32 It's possible but some timestamps being inaccurate isn't itself a problem 06:28:45 The problem is when a small number of outlying timestamps affect the difficulty adjustment 06:29:30 Yeah if it’s just a few it’s fine but I see an incentive her to do this en masse and not even as part of a concerted effort 06:29:37 In this scenario, the next block would appear lucky 06:29:42 so it all evens out 06:29:44 Yeah if it’s just a few it’s fine but I see an incentive here to do this en masse and not even as part of a concerted effort 06:30:28 Yeah if it’s just a few it’s fine but I see an incentive here to do this en masse and not even necessarily as part of a concerted effort 06:33:18 what I mean by that is, assuming it takes exactly 10 mins to actually mine a block, someone looking at the chain would see: 06:33:18 block 1, minute 0 06:33:20 block 2, minute 12 <- this one is the malicious one 06:33:22 block 3, minute 20 06:34:39 so there's a 12 min gap then an 8 min gap 06:37:28 I mean it’s like they get to have their cake and eat it too (in a bad way for us). People get to publish immediately, have their blocks appended, but also skew the difficulty down to mine faster even though their hash rate is high enough to warrant increasing the difficulty. 06:38:57 they're not skewing the difficulty though, since the increase in block time between the prev and malicious block is offset by the decrease in block time between the malicious block and the next 06:43:14 I see your point but if many people start doing this there won’t be enough of a correction because many blocks will be offset or in terms of your example you’d have two consecutive malicious blocks instead 06:44:37 if every single miner does this, the block time goes back to normal because they're all offsetting by +2 mins 06:45:04 they'd need to collude and accumulate this offsetting 06:45:26 but if this goes on for long enough, nodes will reject because the timestamp reached 2 hours into the future 07:06:08 Okay yeah the 2 hour cap resolves it you’re right 07:07:27 It’ll force it to average out 12:20:03 wasap fam! how is it going? 12:20:04 let me share good news with you: quickex listed on swapspace aggregator! 12:21:30 and most pleasant stats update: top our 3 exchange directions related with XMR 12:21:30 1. BTC->XMR 12:21:32 2.XMR->USDT 12:21:34 3.USDT->XMR 14:24:09 https://xcancel.com/DontTraceMeBruh/status/1829024648090022183#m 14:25:39 https://xcancel.com/DontTraceMeBruh/status/1829024648090022183#m 14:51:11 In fairness the payout wasn't the reason I shared the screenshot, it was because they admitted they'd been ignoring customers and executors support messages because they decided to sell the platform (for nearly a month in my case) 14:51:12 Forcing people to get in touch via twitter, because they chose to ignore their official support communication methods, was the only reason for sharing 15:24:47 📰Missed Monerotopia Episode (#180)? Check out the Price, NEWS, GUEST Segment. 15:24:48 Reports here! ⤵️ 15:24:50 Price Report: 15:24:52 Youtube: https://youtu.be/8Y3expEw2BM 15:24:54 ODYSEE: https://odysee.com/@MoneroTalk:8/price-report-08-24-24-%28price-epi-180%29:3 15:24:56 News Segment: 15:24:58 Youtube: https://youtu.be/kOfbfQbXB00 15:25:00 ODYSEE: https://odysee.com/@MoneroTalk:8/antidarknet%2C-fcmp%2C-rfk-and-trump-more!:8 15:25:02 GUEST Segment: 15:25:04 Youtube: https://youtu.be/JRmYkXKOaFI 15:25:06 ODYSEE: https://odysee.com/@MoneroTalk:8/seth-for-privacy-08-24-24-%28guest-epi:2 17:39:31 Shower thought: what would happen if we just….deleted a random block from over 1 million blocks ago? 17:39:32 I mean literally, like you go into the database, pick say block 2,599,875 and delete it, and then launch monerod. What happens? 17:40:24 (And before anyone asks the block number is completely random; dw if I just called out one of your transaction blocks from a while ago) 17:40:33 it will fail to verify transactions with rings that use transactions from this block 17:41:33 Presumably kills your node on FCMP update 17:42:10 As in, if any transaction has members that can be traced back to the block, it’ll just fail? Or is it literally just the direct members of the deleted ring? 17:42:22 rings* probably 17:42:34 Well yeah but I’m ignoring that for now 😂 17:44:04 I'd guess any incoming tx with ring members which are outputs of txs in that deleted block will fail to verify 17:46:59 But if we assume that 1. The outputs in the block won’t be the true spend, and 2. That older outputs won’t be selected for decoys (idk if the 2nd one is reasonable, idk that much abt decoy selection) then it should be fine? 17:52:49 If you tried this on a years old block maybe it'd work for a while, but I don't get the point 18:15:46 Just curious 18:44:38 preland: (2) will eventually happen if the deleted block contains RingCT-eligible outputs. You can get the exact probabilities of that happening, but it's not worth it to me to do the hypothetical exercise. If it's a block with all pre-RingCT outputs, maybe it wouldn't happen since very few rings spend pre-RingCT outputs now. 18:45:45 strawberry is probably right that the node will halt when it tries to build the new output tree when FCMP is activated. I don't know all the details of it, but that sounds right. 18:46:40 I've had a new syncing node reject blocks when the storage medium was faulty. I assume some blockchain data was corrupted. 18:47:28 That's sort of the same as deleting a block 19:03:25 Fair enough; I was trying to figure out exactly what parts of the network break when you do a certain action 19:06:12 Though does that mean that if every network participant (or at least a controlling majority) were to censor a block (or accidentally remove/ignore it due to some weird bug) the network would just…go on fine? If any other nodes reference the block, the block is just marked as invalid, and nothing else of note happens? 19:07:06 I guess what I’m really asking is: is there data within each block that points to the block before it, such that you can’t remove a block without it becoming self-evident? 19:07:34 New nodes wouldn't be able to sync from scratch since there would be a missing block. It would create an error since the new block that exists would reference the missing block by the hash of it 19:07:54 Ok, that’s what I was wondering 👍 19:08:06 That's what a blockchain is. An unbroken chain of blocks that reference each other 19:09:11 That’s what I was thinking, but since no one had mentioned it when I asked I began to wonder if that was actually a feature in Monero or if it had been somehow altered or removed lol 19:10:18 Nodes don't routinely go back and re-verify the whole blockchain. That's why the first problem when you delete a block would be when you try to verify a new, specific block 19:11:12 There may be code in the node that panics when a block is missing, but that could be removed of course. But the verification of some new transactions wouldn't work. 19:12:25 IIRC in bitcoin there is a command to re-verify the most recent `N` blocks if you want. I don't know if Monero has a specific command that does that. 19:13:52 And I’m assuming that there are measures already in place such that a controlling majority couldn’t remove a semi-recent block and then retroactively modify the hashes of each consecutive block 19:14:02 monerod does have a `pop_blocks` command that deletes the most recent `N` blocks. I don't think bitcoin has something like that. 19:14:24 Huh that’s interesting 19:14:28 The measure is Proof-of-Work hashing 19:15:40 An entity with a majority of hashpower can "delete" recent blocks by creating an alternative chain. That's the 51% attack described in the bitcoin white paper. 19:16:26 IIRC Satoshi doesn't use that name, but it's the attack he describes 19:19:04 The bitcoin white paper is still useful for noobs to read. It describes the purpose of bitcoin, compares it to fiat online shopping, and it even has a section on privacy. 19:19:36 (It has turned out that the privacy wasn't very good.) 19:19:54 lmao 19:26:06 Yes, here is info on how to ask bitcoind to re-verify old blocks: https://bitcoin.stackexchange.com/questions/24641/what-is-verifying-last-288-blocks-at-level-3 22:41:44 https://banmonero.com/ 22:48:26 its a trolling project from one of the community members isnt it? 22:49:00 that gigachad guy in the twitter with a long weird name 22:49:03 > It is good that you have seen the error of your ways and wish to dispose of this tool of criminality that you dabbled in before it ate your eternal soul. We have created a "black hole" for Monero, an address that goes nowhere. You can send your Monero to this address and rest assured that it will be gone forever. 22:49:04 Welp, how can one check that they won't be used anymore? 22:56:21 he will spend it