<p​reland:monero.social> 99% of miners stop right before the winning hash 💰 💴 🔥 🤑💲💵💷💶

<h​anshan:monero.social> matrix.monero.social/_matrix/media/…ero.social/hWCRHKuwwfPpvfRZvQteeiTW

<h​anshan:monero.social> don't mean to brag but...

<o​frnxmr:monero.social> Thats not braggin

<h​anshan:monero.social> heh

<o​frnxmr:monero.social> Go check your "blocks mined"

<o​frnxmr:monero.social> Monero blocks

<h​anshan:monero.social> hey I got a couple

<o​frnxmr:monero.social> Most recent shares

<o​frnxmr:monero.social> Most recent monero blocks

<o​frnxmr:monero.social> Most recent likely sweeps

<o​frnxmr:monero.social> At the bottom of your miner page, check the second one. Have you found any blocks?

<h​anshan:monero.social> 3 blocks with my 5950

<o​frnxmr:monero.social> shown on the p2pool page?

<h​anshan:monero.social> yeah

<o​frnxmr:monero.social> Thats 1.8xmr

<o​frnxmr:monero.social> now clock "all historical payouts"

<o​frnxmr:monero.social> Click*. Did were you paid more or less than 1.8xmr

<h​anshan:monero.social> nowhere close

<o​frnxmr:monero.social> Thank for playing 🍻

<h​anshan:monero.social> this 5950 has probably only mined a third of that over that period

<h​anshan:monero.social> shoulda solo'd it

<o​frnxmr:monero.social> This is why i recommend solomining

<h​anshan:monero.social> the main thing re solo is just knowing whether its actually doing anything or not

<o​frnxmr:monero.social> Unless youre mine blocks, youre not doing anything

<o​frnxmr:monero.social> Just getting participation trophies

<o​frnxmr:monero.social> If you need to know that your finding "shares", you can use xmrig-proxy and send a custom difficulty to the miner

<h​anshan:monero.social> so you need some live display of the participation trophies...

<h​anshan:monero.social> that would be encouraging

<o​frnxmr:monero.social> 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

<h​anshan:monero.social> yeah nobody I gonna do that.

<h​anshan:monero.social> i mean,

<h​anshan:monero.social> *i* might

<h​anshan:monero.social> but

<n​eromonero1024:monero.social> hardhatter: got the complete picture about block timestamps

<n​eromonero1024:monero.social> * a block timestamp must be greater than the average of last 60 blocks

<n​eromonero1024:monero.social> * a new block timestamp may not exceed 2 hrs above the system time (shoutout to strawberry for the info)

<n​eromonero1024:monero.social> blocks violating these rules won't be accepted

<n​eromonero1024:monero.social> couple that with the difficulty adjustment rules, the monero protocol greatly limits how much you can fiddle with the block timestamps

<s​nowman:tetaneutral.net> I just discovered Gitea. What a great tool.

<s​nowman:tetaneutral.net> What are people using for data hoarding- archiving websites and videos and such?

<r​ecanman:kernal.eu> archivebox.io I guess

<r​ecanman:kernal.eu> I run a private instance and it holds well with ~30TiB of data, although I'm sure there are people with much more

<s​nowman:tetaneutral.net> Are you using a spinny drive?

<s​nowman:tetaneutral.net> 30T is a lot

<r​ecanman:kernal.eu> I have 288TiB total

<s​nowman:tetaneutral.net> I was hoping for something more similar to Pocket

<s​nowman:tetaneutral.net> wow

<r​ecanman:kernal.eu> 48*6, six each running in raidz2 so two drives are redundant

<r​ecanman:kernal.eu> (48 drives each 6TiB)

<s​nowman:tetaneutral.net> what kind of enclosure/hardware supports that many drives

<r​ecanman:kernal.eu> netapp ds4246 holds 24x3.5". Or 2426 (I think) for 2.5"

<r​ecanman:kernal.eu> To clarify, they are all spinning rust, not ssds

<r​ecanman:kernal.eu> Old enterprise SAS drives for dirt cheap on ebay. ~$7/TiB

<s​nowman:tetaneutral.net> Wow that thing is huge

<s​nowman:tetaneutral.net> and ++ to the cheap rusties. you may have inspired me to dust off my old hdd box

<s​nowman:tetaneutral.net> what's the power consumption on all of that

<r​ecanman:kernal.eu> About 600W total? Along with 2 poweredge R620s running at ~80% utilization and a switch

<r​ecanman:kernal.eu> Costs virtually nothing extra for me, luckily, due to my conditions

<s​nowman:tetaneutral.net> you live inside a solar panel

<r​ecanman:kernal.eu> Possibly 😃

<r​ecanman:kernal.eu> Been running them for ~3.25 years or so? Had one drive fail so far

<r​ecanman:kernal.eu> Even sometimes with sudden power cuts before I had a UPS. They hold up really well

<s​nowman:tetaneutral.net> I have a pretty basic old tower running proxmox

<s​nowman:tetaneutral.net> debating how I want to start doing backups

<r​ecanman:kernal.eu> 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

<r​ecanman:kernal.eu> Depending on the importance of your data, I would back up to another small local server and to a cloud provider (encrypted)

<r​ecanman:kernal.eu> Kopia is a good tool. E.g upload to google (encrypted)

<s​nowman:tetaneutral.net> Yeah, I've been looking at doing a second proxmox instance and figuring that part out

<r​ecanman:kernal.eu> If you do, I don't recommend clustering them. Proxmox clustering is a disaster, easier to manage the servers independently

<s​nowman:tetaneutral.net> how dumb is it to save encrypted data to g

<r​ecanman:kernal.eu> Not at all. Assuming the cryptography is sound, the only risk would be google removing your data, which is why you have redundancy

<r​ecanman:kernal.eu> Or possibly save-now-decrypt-later but I doubt your data is *that* important

<s​nowman:tetaneutral.net> ah that's exactly what I was going to do. That's sad to hear. Have you tried the proxmox backup software?

<r​ecanman:kernal.eu> Proxmox backup server is good, works well. Although just for backing up VMs/LXCs

<s​nowman:tetaneutral.net> What kind of inverter do you use with your PV?

<r​ecanman:kernal.eu> I don't know. I did not set it up.

<s​nowman:tetaneutral.net> Nice to not have to worry about it. I'm hodgepodging a used system together at the moment. Old panels are very cheap.

<h​ardhatter:monero.social> 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.

<h​ardhatter:monero.social> 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

<s​trawberry:monero.social> 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

<s​trawberry:monero.social> 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

<s​trawberry:monero.social> ^ actually not true, the minimum timestamp is based on a median, but difficulty adjustment may not be

<s​trawberry:monero.social> I imagine it's done in such a way where 1 pool can't game the timestamps? hold on

<h​ardhatter:monero.social> 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.

<h​ardhatter:monero.social> 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?

<h​ardhatter:monero.social> 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.

<h​ardhatter:monero.social> 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?

<h​ardhatter:monero.social> 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

<s​trawberry:monero.social> It's possible but some timestamps being inaccurate isn't itself a problem

<s​trawberry:monero.social> The problem is when a small number of outlying timestamps affect the difficulty adjustment

<h​ardhatter:monero.social> 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

<s​trawberry:monero.social> In this scenario, the next block would appear lucky

<s​trawberry:monero.social> so it all evens out

<h​ardhatter:monero.social> 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

<h​ardhatter:monero.social> 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

<s​trawberry:monero.social> what I mean by that is, assuming it takes exactly 10 mins to actually mine a block, someone looking at the chain would see:

<s​trawberry:monero.social> block 1, minute 0

<s​trawberry:monero.social> block 2, minute 12 <- this one is the malicious one

<s​trawberry:monero.social> block 3, minute 20

<s​trawberry:monero.social> so there's a 12 min gap then an 8 min gap

<h​ardhatter:monero.social> 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.

<s​trawberry:monero.social> 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

<h​ardhatter:monero.social> 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

<s​trawberry:monero.social> if every single miner does this, the block time goes back to normal because they're all offsetting by +2 mins

<s​trawberry:monero.social> they'd need to collude and accumulate this offsetting

<s​trawberry:monero.social> but if this goes on for long enough, nodes will reject because the timestamp reached 2 hours into the future

<h​ardhatter:monero.social> Okay yeah the 2 hour cap resolves it you’re right

<h​ardhatter:monero.social> It’ll force it to average out

<q​uickex:matrix.org> wasap fam! how is it going?

<q​uickex:matrix.org> let me share good news with you: quickex listed on swapspace aggregator!

<q​uickex:matrix.org> and most pleasant stats update: top our 3 exchange directions related with XMR

<q​uickex:matrix.org> 1. BTC->XMR

<q​uickex:matrix.org> 2.XMR->USDT

<q​uickex:matrix.org> 3.USDT->XMR

<m​x_mandelbrot42:matrix.org> xcancel.com/DontTraceMeBruh/status/1829024648090022183#m

<m​x_mandelbrot42:matrix.org> xcancel.com/DontTraceMeBruh/status/1829024648090022183#m

<t​hedragon44:matrix.org> 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)

<t​hedragon44:matrix.org> Forcing people to get in touch via twitter, because they chose to ignore their official support communication methods, was the only reason for sharing

<k​orgprivacy:matrix.org> 📰Missed Monerotopia Episode (#180)? Check out the Price, NEWS, GUEST Segment.

<k​orgprivacy:matrix.org> Reports here! ⤵️

<k​orgprivacy:matrix.org> Price Report:

<k​orgprivacy:matrix.org> Youtube: youtu.be/8Y3expEw2BM

<k​orgprivacy:matrix.org> ODYSEE: odysee.com/@MoneroTalk:8/price-report-08-24-24-%28price-epi-180%29:3

<k​orgprivacy:matrix.org> News Segment:

<k​orgprivacy:matrix.org> Youtube: youtu.be/kOfbfQbXB00

<k​orgprivacy:matrix.org> ODYSEE: odysee.com/@MoneroTalk:8/antidarknet%2C-fcmp%2C-rfk-and-trump-more!:8

<k​orgprivacy:matrix.org> GUEST Segment:

<k​orgprivacy:matrix.org> Youtube: youtu.be/JRmYkXKOaFI

<k​orgprivacy:matrix.org> ODYSEE: odysee.com/@MoneroTalk:8/seth-for-privacy-08-24-24-%28guest-epi:2

<p​reland:monero.social> Shower thought: what would happen if we just….deleted a random block from over 1 million blocks ago?

<p​reland:monero.social> I mean literally, like you go into the database, pick say block 2,599,875 and delete it, and then launch monerod. What happens?

<p​reland:monero.social> (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)

it will fail to verify transactions with rings that use transactions from this block

<s​trawberry:monero.social> Presumably kills your node on FCMP update

<p​reland:monero.social> 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?

<p​reland:monero.social> rings* probably

<p​reland:monero.social> Well yeah but I’m ignoring that for now 😂

<s​trawberry:monero.social> I'd guess any incoming tx with ring members which are outputs of txs in that deleted block will fail to verify

<p​reland:monero.social> 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?

<s​trawberry:monero.social> If you tried this on a years old block maybe it'd work for a while, but I don't get the point

<p​reland:monero.social> Just curious

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> I've had a new syncing node reject blocks when the storage medium was faulty. I assume some blockchain data was corrupted.

<r​ucknium:monero.social> That's sort of the same as deleting a block

<p​reland:monero.social> Fair enough; I was trying to figure out exactly what parts of the network break when you do a certain action

<p​reland:monero.social> 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?

<p​reland:monero.social> 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?

<r​ucknium:monero.social> 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

<p​reland:monero.social> Ok, that’s what I was wondering 👍

<r​ucknium:monero.social> That's what a blockchain is. An unbroken chain of blocks that reference each other

<p​reland:monero.social> 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

<r​ucknium:monero.social> 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

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> 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.

<p​reland:monero.social> 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

<r​ucknium:monero.social> monerod does have a `pop_blocks` command that deletes the most recent `N` blocks. I don't think bitcoin has something like that.

<p​reland:monero.social> Huh that’s interesting

<r​ucknium:monero.social> The measure is Proof-of-Work hashing

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> IIRC Satoshi doesn't use that name, but it's the attack he describes

<r​ucknium:monero.social> 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.

<r​ucknium:monero.social> (It has turned out that the privacy wasn't very good.)

<s​yntheticbird:monero.social> lmao

<r​ucknium:monero.social> Yes, here is info on how to ask bitcoind to re-verify old blocks: bitcoin.stackexchange.com/questions…erifying-last-288-blocks-at-level-3

<s​tarlingfarchecker:monero.social> banmonero.com

<r​eal_glitch:matrix.org> its a trolling project from one of the community members isnt it?

<r​eal_glitch:matrix.org> that gigachad guy in the twitter with a long weird name

<o​renty7:matrix.org> > 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.

<o​renty7:matrix.org> Welp, how can one check that they won't be used anymore?

<b​asses:matrix.org> he will spend it