-
m-relay<ofrnxmr:xmr.mx> No, liquidity period. 80% of zano is staked, which is why the coin pumps on 0 liquidity
-
m-relay<elongated:matrix.org> Small as in the community the number of miners the actual security cost
-
m-relay<diego:cypherstack.com> Which is why a block reward split of 80-20 miners-stakers might be feasible? Still a way to get money without staking while also having finality layer
-
DataHoarderyou say that like we can flip a switch and turn off the network, hi585858
-
m-relay<elongated:matrix.org> Zano is premined shitcoin, why are we discussing that ?
-
DataHoarder44 out last 100, indeed
-
m-relay<ofrnxmr:xmr.mx> I said 10:1, with only coinbases stakable
-
hi585858not asking to turn off the network
-
hi585858just sharing actual historical fact happening rn
-
m-relay<ofrnxmr:xmr.mx> Monero mined 100k coins in the first 3 days
-
m-relay<diego:cypherstack.com> yeah my numbers are not final, just representative. 10:! works too.
-
DataHoarderI am recording, trust me hi585858 :)
-
DataHoarderI hoard the data
-
m-relay<elongated:matrix.org> So did btc ?
-
hi585858its impressive how they gain from 10 block to 80 block and
-
hi585858now*
-
m-relay<ofrnxmr:xmr.mx> So when you talk about premine, remember monero did not have a fair emission, crippleminer, fast emission, etx
-
DataHoarderanother point is, would all coinbases be included, or only ones after certain date? or aged?
-
m-relay<ofrnxmr:xmr.mx> all coinbases, i think
-
DataHoarderwhich also brings issues about starting up PoS or finality layer that way
-
m-relay<elongated:matrix.org> Crippleminer was bytecoin
-
m-relay<ofrnxmr:xmr.mx> No, it was monero
-
m-relay<diego:cypherstack.com> so spend a coinbase once and it becomes ineligible forever?
-
m-relay<ofrnxmr:xmr.mx> Yup, diego
-
m-relay<diego:cypherstack.com> potentially a problem with other coins, but with a tail emission not so much
-
m-relay<elongated:matrix.org> Afaik it was bytecoin and hence the fork to xmr
-
m-relay<ofrnxmr:xmr.mx> Fork was due to premine lies
-
m-relay<ofrnxmr:xmr.mx> Monero forked, and had crippleminer and later proprietary miner that wasnt as crippled
-
DataHoarderthe other goal is to see if they turn on their selfish mining today as they said
-
m-relay<diego:cypherstack.com> I am a Monero historian, having read all the things. Monero was cripplemined. Bytecoin people were salty that Bytecoin scam failed, and were saltier that Monero got taken from them, so they released a crippled miner under a different alias, and people used it.
-
m-relay<diego:cypherstack.com> da-data.blogspot.com/2014/08/minting-money-with-monero-and-cpu.html
-
m-relay<gingeropolous:monero.social> naw, bytecoin had the crippled miner originally
-
m-relay<gingeropolous:monero.social> and monero just inherited it
-
m-relay<gingeropolous:monero.social> cripple miner may have been part of the creating that backstory of bytecoin being around for years
-
m-relay<diego:cypherstack.com> Right. 2-3 weeks of cripple mining before the fix.
-
m-relay<ofrnxmr:xmr.mx> I'm trying so hard to hit 20mb blocks on fcmp. Highest is 15mb so far
-
m-relay<ofrnxmr:xmr.mx> hard to maintain due to lack of inputs / locked inputs. Started gaming the median by mining an 1/3 blocks as empty, but still run low on inputs before i can get 50 blocks at over 10mb 🙃
-
m-relay<gingeropolous:monero.social> this finality layer business would still leave us open to empty block mining and tx censoring etc
-
m-relay<ofrnxmr:xmr.mx> And open the door for someone to outspend us
-
m-relay<elongated:matrix.org> How does tx censoring work ? You can know which decoy is being spent no Addr no amount
-
m-relay<ofrnxmr:xmr.mx> and, iiuc, the chain can halt if validators dont come to concensus
-
m-relay<elongated:matrix.org> For how long ?
-
m-relay<elongated:matrix.org> How does tx censoring work ? You cant know which decoy is being spent no Addr no amount
-
m-relay<ofrnxmr:xmr.mx> Until we hard fork
-
DataHoardersay they want to prevent p2pool miners from moving coins
-
m-relay<elongated:matrix.org> Which pos was stuck ?
-
DataHoarderthey can identify who it is due to how p2pool mines
-
m-relay<elongated:matrix.org> Which pos chain was stuck ?
-
DataHoarderif they sweep outputs at once
-
DataHoarderhere's some recent ones tied to a specific miner address p2pool.observer/sweeps
-
DataHoarderthey might have alternate ways of doing so
-
m-relay<elongated:matrix.org> P2pool is special case
-
DataHoarderyes, but they could have a view on an exchange transactions, for example
-
m-relay<ofrnxmr:xmr.mx> With a tfl? Idk
-
m-relay<elongated:matrix.org> Okay, same can be said for pow miners ? Pools?
-
DataHoarderthere's ways monero tries to prevent this and make it hard to know where a transaction comes from or who is
-
m-relay<elongated:matrix.org> Idk what’s special for pos, same can be true with pow
-
DataHoarderbut that's a different problem. if an attacker that can sustain 51% hashrate long term exists
-
DataHoarderand they know a txid
-
DataHoarderthey can mine everything but that tx
-
m-relay<elongated:matrix.org> With hybrid attacker needs to control both
-
DataHoarderand orphan any block that contains it
-
DataHoarderwith finality?
-
m-relay<elongated:matrix.org> Same for pow
-
DataHoarderif inclusion is decided solely by pow, no
-
m-relay<ofrnxmr:xmr.mx> There can be staking pools too
-
m-relay<elongated:matrix.org> Yes same for pow or pos
-
nioc<DataHoarder> yeah, the yields% that are usually done for by staking is ... waay too high to what monero, already on tail emission, is <<>> someone mentioned that ETH pays 2%
-
m-relay<datahoarder:monero.social> Yes I was always referring to pow, elongated. These messages made no sense on IRC as there was no threading there
-
DataHoarderFor context how it looks in irc irc.gammaspectra.live/f8233335da0f5672/IMG_6843.jpeg
-
m-relay<elongated:matrix.org> I think we need to hire some researcher for pos/pow to make it suitable for xmr
-
m-relay<elongated:matrix.org> Maybe hire cypherstack to do some research, if they are interested
-
hi585858make ccs people will donate 100%
-
m-relay<elongated:matrix.org> Diego Salazar:
-
DataHoarderPOS is a change that totally moves the fundamental ways that Monero works. So assume there will be more friction or longer time before it can be done, compared to privacy improvements/changes in signatures and transactions, or even the PoW function change (which I wasn't here for originally!)
-
hi585858fundamental is security and privacy
-
hi585858communism is not
-
niocis this the offtopic channel
-
m-relay<elongated:matrix.org> You can’t reject/move to hybrid, without any research
-
m-relay<rottenwheel:unredacted.org> nioc where are we and where is my beanie?
-
niocI am with Cat
-
m-relay<rottenwheel:unredacted.org> meow.
-
niocjust about to give her her bedtime snack
-
niocshe remains unconcerned
-
hi58585851% unknown on last 100 block
-
m-relay<diego:cypherstack.com> Hi its me.
-
m-relay<barthman132:matrix.org> Did they get it or did they just barely missed it?
-
m-relay<elongated:matrix.org> Would cypherstack be interested in hybrid pow/pos research?
-
m-relay<diego:cypherstack.com> Yes but you need to pay in qubic
-
m-relay<diego:cypherstack.com> I jest. Gimme the money and off we go (we're already low key looking at bit)
-
m-relay<elongated:matrix.org> Can you open a ccs? Or have a ccs on you own website
-
m-relay<diego:cypherstack.com> Oooh I can finally try out the whole Kuno thing, or whatever its called.
-
m-relay<elongated:matrix.org> Kuno works
-
m-relay<diego:cypherstack.com> Although honestly I was going to float the idea by you all of a general CS retainer.
-
m-relay<diego:cypherstack.com> People and projects are trying to snap up our hours recently and last time I didnt give Monero first dibs on things people got mad at me.
-
m-relay<elongated:matrix.org> CS retainer is not a bad idea, maybe discuss it in next MRL meeting ?
-
m-relay<articmine:monero.social> This can be very useful in order to encourage self custody for staking
-
m-relay<ofrnxmr:xmr.mx> I'm against staking pools
-
m-relay<articmine:monero.social> Why
-
m-relay<articmine:monero.social> What attack vectors do you see
-
m-relay<ofrnxmr:xmr.mx> The idea of getting paid to deposit your $ on an exchange or pool - youre essentially no different than a speculative stock investor
-
m-relay<ofrnxmr:xmr.mx> Its custodial
-
m-relay<ofrnxmr:xmr.mx> Like eth. "32 eth min" so everyone just lets binance stake for them
-
m-relay<articmine:monero.social> ... but is a self custody staking pool possible?
-
m-relay<ofrnxmr:xmr.mx> yea, and cold staking as well
-
m-relay<articmine:monero.social> I see self custody of the stake as a way to mitigate POS attack vectors
-
m-relay<ofrnxmr:xmr.mx> academy.particl.io/en/latest/part-g…king.html#connect-to-a-staking-pool
-
m-relay<ofrnxmr:xmr.mx> > It is highly recommended to be careful about which cold staking pool you choose to stake your funds with. In fact, because you are effectively delegating your staking power to a third-party, staking from a cold staking pool tends to centralize the staking weight of the network.
-
m-relay<ofrnxmr:xmr.mx> particl.wiki/learn/staking/pools
-
m-relay<ofrnxmr:xmr.mx> Its similar centralization issue as mining pools
-
m-relay<articmine:monero.social> What about a P2P self custody staking pool?
-
m-relay<fiatmoneysucks:matrix.org> How it will works?
-
m-relay<ofrnxmr:xmr.mx> I dont think you'd need a pool for that, and personally i think stakers should have to participate and run their own infra
-
m-relay<ofrnxmr:xmr.mx> I really don't like the idea of "whale delegates view key of their ledger, and checks back in 20 years"
-
m-relay<articmine:monero.social> So block singing for the staking pools
-
m-relay<articmine:monero.social> Signing
-
m-relay<ofrnxmr:xmr.mx> In my brief time being around the particl community, ive grown a distaste for the way everybody in pos behaves (passively)
-
m-relay<articmine:monero.social> We need to start thinking outside of the box here
-
m-relay<articmine:monero.social> Like the Bitmain ASIC version of POS
-
m-relay<ofrnxmr:xmr.mx> my outside the box was: hot staking only (wallet needs to be online to sign blocks), coinbases only (initial stake comes from pow. moving the funds removes the stake, irreversibly).
-
m-relay<ofrnxmr:xmr.mx> Problem with coinase-only is that an entity like qubic could quickly obtain a majority% if they opt not to sell.
-
m-relay<ofrnxmr:xmr.mx> on the other hand, to stake, you'd be forced to contribute pow. You wouldnt be able to stake someone elses coins, or take out a loan to borrow coins against
-
m-relay<ofrnxmr:xmr.mx> The "staking pools" in this scenario, would be mining pools who offer extra reward if you dont withdraw your coins. So it doesnt eliminate pool staking (unless paired with signing the blocks)
-
m-relay<articmine:monero.social> Block signing doesn't prevent pool mining. At least how I see it
-
m-relay<ofrnxmr:xmr.mx> block signing to prevent mining pools from staking your blocks
-
m-relay<barthman132:matrix.org> I mean there are douchbags in every community, but that is just how the world goes
-
m-relay<ofrnxmr:xmr.mx> My original idea was to split block production into 4min pow blocks and in pos blocks, with a 10:1 emission split. Reorging beyong 2 blocks on either side would require control of both sides.
-
m-relay<ofrnxmr:xmr.mx> i dont think splitting block production was received well either, but the pros are..
-
m-relay<ofrnxmr:xmr.mx> 1. Emission is still majority pow. Pos blocks are essential a soft finality
-
m-relay<ofrnxmr:xmr.mx> 2. P2pool payouts would be larger, due to increased pow block rewars
-
m-relay<ofrnxmr:xmr.mx> 3. Reorgs would be more difficult due to reduced block frequency
-
m-relay<articmine:monero.social> If the signing requirements are only 1% the pools can stake the balance
-
m-relay<ofrnxmr:xmr.mx> 4 min pow and* 4 min pos
-
m-relay<articmine:monero.social> I was thinking along the same lines with a 50%split block reward between POS and POW
-
m-relay<ofrnxmr:xmr.mx> i think 10:1 is nicer :P. Majority goes to pow miners, with pos being a bonus 10% for keeping your coinbases locked up to finalize the pow blocks
-
m-relay<boog900:monero.social> > Reorgs would be more difficult due to reduced block frequency
-
m-relay<boog900:monero.social> I still don't think this is the case when you take into account the amount of work reorged vs just the amount of blocks
-
m-relay<ofrnxmr:xmr.mx> 50:50 would probably be more attractive to only use pos, and turn off the pow
-
m-relay<articmine:monero.social> The real question here is: Does the why is greater than the sum of its parts apply to security?
-
m-relay<articmine:monero.social> Whole is greater than the sum of its parts between POW and POS
-
m-relay<articmine:monero.social> For security
-
m-relay<ofrnxmr:xmr.mx> The diff would be double, so a 1 block reorg is essemtially 2, and if a pos block comes before you reorg, then youd have to reorg that too. Ignorinf pos entirely, its harder to reorg 1 10min block than 5x2min blocks, isnt it?
-
m-relay<ofrnxmr:xmr.mx> Or actuallt, that might be roughly the same, but youd have less reorgs on 10min blocks than on 2min ones
-
m-relay<articmine:monero.social> The idea is mining on the POS block and staking on the POW block
-
m-relay<boog900:monero.social> The probability of reorging a number of block decreases exponentially the more blocks, so mining 1 10 min block is "easier" than 2 consecutive 5 min blocks
-
m-relay<articmine:monero.social> So they alternate
-
m-relay<ofrnxmr:xmr.mx> Boog, corrected myself here
-
m-relay<ofrnxmr:xmr.mx> Yup. Diff targetting 4mins per side should have ~360 pow and ~360 pos blocks per day
-
m-relay<captaincanaryllc:matrix.org> if more blocks makes it harder to reorg, how far can you push it?
-
m-relay<boog900:monero.social> it wouldn't be roughly the same but yes the amount of random alt blocks should decrease.
-
m-relay<boog900:monero.social> 1 block per hash would make it impossible without 51% :)
-
m-relay<boog900:monero.social> and assuming all blocks reach the whole network instantly
-
m-relay<boog900:monero.social> FWIW I was talking about when the attacker has less than 51%, with more than that they can reorg whatever they want (theoretically) with slower or faster blocks
-
m-relay<captaincanaryllc:matrix.org> right, so with more frequent blocks, qubic reorgs may not have happened
-
m-relay<captaincanaryllc:matrix.org> so increasing block frequency is a band-aid on its own? what are the downsides
-
m-relay<ofrnxmr:xmr.mx> No, with more frequent blocks, theyd have more reorgs
-
m-relay<ofrnxmr:xmr.mx> If blocks were 1 minute, assuming 100% luck, theyd have 14 block reorg instead of 7
-
m-relay<ofrnxmr:xmr.mx> If they had bad luck, they might get 10 blocks, good luck might get 18 blocks
-
m-relay<ofrnxmr:xmr.mx> more frequent blocks means you need consistent good luck. But each individual reorg is easier
-
m-relay<boog900:monero.social> you have assumed their share of the network has dropped by half
-
m-relay<boog900:monero.social> increased by double*
-
m-relay<boog900:monero.social> their share of the network is the same
-
m-relay<boog900:monero.social> they are still the minority hash power, this is all dependent on their luck
-
m-relay<boog900:monero.social> monero-project/research-lab #102#issuecomment-2402750881
-
m-relay<boog900:monero.social> to get 7 blocks at 20% of the network is 1.4% chance, to get 14 blocks at 20% of the network is 0.04571%
-
m-relay<ofrnxmr:xmr.mx> No, i assumed that the diffoculty has decreased by half
-
m-relay<boog900:monero.social> their share of the hash power is the same
-
m-relay<boog900:monero.social> it wouldn't be double because of the exponential but you get what I mean
-
m-relay<ofrnxmr:xmr.mx> Yeah, i'm sleeptalking (i dont sleep)
-
m-relay<ofrnxmr:xmr.mx> I see where i muddied my assumption
-
m-relay<boog900:monero.social> you would also need to take into account that with more blocks you get more attempts at reorgs
-
m-relay<boog900:monero.social> but because it drops off exponentially faster blocks would still be better for protecting PoW
-
m-relay<gingeropolous:monero.social> ugh im not seeing that. where in the paper does it directly talk about the different duration of blocks? the targed blocktime?
-
m-relay<gingeropolous:monero.social> ah nvm
-
m-relay<gingeropolous:monero.social> so 10 second blocks here we come?
-
DataHoarderp2pool 10 second blocks!
-
DataHoarderwith uncles :)
-
m-relay<spirobel:kernal.eu> ArticMine: no. its better to get rid of PoW entirely. it serves zero purpose. the hybrid is only to keep the myth intact for a bit so people handle the transition better. It would be more honest to transition directly instead of putting whool on peoples eyes as you said. ofrnxmr staking from coinbases makes no sense and introduces needless fungibility problems.
-
m-relay<spirobel:kernal.eu> 1. in the case of Monero we want as low a stake as possible in any case to increase the privacy pool
-
m-relay<spirobel:kernal.eu> 2. safety is just a liveness problem with the added twist that a third party potentially lost money to a double spend. After the network is restarted and rolled back to a state before the attack, the validators can vote to slash the attacker stake or use it to compensate the third party, if this third party is sufficiently likeable.
-
m-relay<spirobel:kernal.eu> the downside of keeping pow around: 1. waste of money 2. slower finality 3. if an attacker spends tens to hundreds of millions on the stake, is he really going to stop at renting a few cpus as well? the attack cost against PoW is miniscule compared to attacking PoS. Also: if the CPUs are bought they can be reused in the next attack. With slashed stake that is impossible.
-
m-relay<johnruth:matrix.org> Probability of consistent luck is lower. If you flip a coin five times vs ten times, getting all heads is 32 times harder in second scenario
-
m-relay<johnruth:matrix.org> For those who are brainstorming ways to secure network from this attack; one way is to look how to make monero more resilient, the other is to poke holes in qubic. Sometimes, the best defence is good offence
-
m-relay<johnruth:matrix.org> “There is no security on this planet, only opportunity”
-
midipoetThen you're just playing whack a mole every time a Qubic appears. Eventually a mole will eat through to the pantry.
-
m-relay<johnruth:matrix.org> I strongly disagree, lived long enough
-
m-relay<johnruth:matrix.org> I disagree. It’s like dealing with a bully. You show you don’t strike and many will try to take a jab at you. You rearrange somebody’s teeth once and nobody will fk with you
-
moneromoooI think you are misapplying a lesson you have learnt before.
-
moneromoooThe immediate obstacle you will face here is that of attribution and reach.
-
moneromoooA bully will be in range. Consider a hidden bully with a ranged weapon.
-
moneromoooAnd no, saying "I go to the bully and proceed to rearrange teeth" is not a good answer.
-
moneromoooThe thing on the internet is that it is easy to "hide" and two opponents have different capabilities. Moreover, use of those capabilities may bring abot attention from a bigger bully, one you do *not* want to face off in a teeth rearrangement situation.
-
m-relay<johnruth:matrix.org> Sounds like you never had to assert yourself or you like to live in fear, but this isn’t the point. It’s monero talk and I was making a metaphor
-
m-relay<ofrnxmr:monero.social> Plz explain how go rearrange someones face over the internet
-
m-relay<ofrnxmr:monero.social> How-to*
-
m-relay<ofrnxmr:monero.social> Or what the actionable implication was
-
m-relay<johnruth:matrix.org> That was metaphor. I was talking about qubic having possible vulnerabilities or wholes that can be exploited
-
m-relay<johnruth:matrix.org> Holes*
-
m-relay<johnruth:matrix.org> The only thing I know is they have halving next week, their “Ai training” is vapourware there isn’t any actual Ai model being trained and they pay. They pay (with btc) for hash on mining rentals and they paid influencers and shai for hit pieces
-
m-relay<hbs:matrix.org> which makes p2pool miners more exposed to QC risks
-
m-relay<torir:matrix.org> Previous message was a reply to DataHoarder:
-
m-relay<torir:matrix.org> > <DataHoarder> they can identify who it is due to how p2pool mines
-
m-relay<torir:matrix.org> (IRC can't see replies in Matrix)
-
m-relay<hbs:matrix.org> My understanding was that a FL would require a limited set of validators, so not that many miners could participate and stake would be low per staker then
-
m-relay<antilt:we2.ee> often, the higher your stake, the greater the probability to be selected as validator for an "epoch". But the curve can be made flat, too
-
m-relay<0xfffc:monero.social> if anybody can, I need this: link.springer.com/article/10.1007/s10207-024-00849-5
-
m-relay<venture:monero.social> i think the opposite is true. if you have 30% hashrate / chance of winning a block, winning 2 consecutive blocks, would be 0.3^2, for 6, 0.3^6 and so on. so exponentionally harder with each block. if you have 720 blocks a day, it's therefore more likely to to eventually be able to strike, vs 360 blocks a day (= less frequent / slower blocks)
-
m-relay<gingeropolous:monero.social> yeah its a doozy to get your head around. searching around infinite space for a winning nonce. but last night it made sense to me . Take a 2 10 minute block vs 10 2 minute block analogy: The attacker's challenge is to secretly out-build the honest chain. It's vastly more difficult for them to get lucky enough to secretly find more than 20 blocks while the honest chain is finding 2<clipped
-
m-relay<gingeropolous:monero.social> 0, than it is for them to secretly find more than 2 blocks while the honest chain is finding 2.
-
m-relay<gingeropolous:monero.social> so how fast can we sling blocks around the network
-
gingeropoloustevador had mentioned that these aren't asics... but the bitmain X5 is still out there. And they could be the main thing on those rental sites (how else do you get 10 MH)
-
gingeropolousswitching to RandomxV2 might go a long way with this situation
-
gingeropolousi was trying to find the code for that nonce distribution analysis to see how much of them are still on the network but couldn't find it
-
m-relay<johnruth:matrix.org> eprint.iacr.org/2024/363.pdf
-
m-relay<johnruth:matrix.org> arxiv.org/pdf/2502.17307
-
m-relay<johnruth:matrix.org> jit.ndhu.edu.tw/article/viewFile/2543/2561
-
m-relay<johnruth:matrix.org> oic-cert.org/en/journal/pdf/2/1/211.pdf
-
m-relay<johnruth:matrix.org> scispace.com/pdf/blockchain-system-…for-double-spend-and-467y88mhpz.pdf
-
m-relay<johnruth:matrix.org> ece.iit.edu/~yucheng/YCheng_PST22.pdf
-
m-relay<johnruth:matrix.org> scitepress.org/Papers/2024/135245/135245.pdf
-
m-relay<captaincanaryllc:matrix.org> I also want to know this
-
m-relay<boog900:monero.social> But you said it yourself, the probability of each individual reorg has dropped further than the increase chance you get because of more blocks.
-
m-relay<basses:matrix.org> idk if this was shared before
-
m-relay<basses:matrix.org> powerupprivacy.com/2025/03/05/moner…ty-one-percent-attack-analysis.html
-
m-relay<basses:matrix.org> calculates the approximate costs of 51% attack on Monero, research was published on March 05, 2025.
-
m-relay<basses:matrix.org> Rucknium
-
niocgingeropolous: mining rig rentals gives a description of the equipment that you are renting. I did not notice any bitmain X5
-
niochow many are left after so many burned up?
-
m-relay<rucknium:monero.social> captaincanaryllc gingeropolous See my rucknium.me/posts/monero-pool-transaction-delay
-
m-relay<rucknium:monero.social> >About 80 percent of blocks arrived at all five Monero nodes within a one-second interval.
-
m-relay<rucknium:monero.social> rando: Thanks. I had not seen that.
-
m-relay<barthman132:matrix.org> So around 12 to 18 million for one month to pull off. TBH that’s not very much in the grand scheme of things
-
m-relay<barthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/TRlIEGYMjhWujdNJxXXqqpep
-
m-relay<barthman132:matrix.org> Did qubic get ddosed?
-
m-relay<datahoarder:monero.social> They finished their marathon
-
m-relay<barthman132:matrix.org> Oh they did? Ok thanks
-
m-relay<datahoarder:monero.social> It happens for 24h in a row
-
m-relay<barthman132:matrix.org> Does their hashrate always drop to basically zero when they’re done?
-
DataHoarderwhen they are in their own mining phase they mine nothing in XMR
-
DataHoarderit comes in/out every hour for 30m
-
m-relay<lordx3nu:matrix.org> Is there any info showing how many blocks they found yesterday?
-
gingeropolousyou can hover over the pie chart at the bottom of miningpoolstats.stream/monero
-
gingeropolous297 . dunno what the window is for the pie chart
-
m-relay<lordx3nu:matrix.org> I'm curious if they crossed 40%.
-
m-relay<rucknium:monero.social> Checked moneroconsensus.info lately? :D
-
niocgingeropolous: in the upper right it says last 1000 blocks
-
niocif you click that it will give you last 100 blocks
-
gingeropolousthere yah go, so thats definitely covers the day
-
m-relay<rucknium:monero.social> Th line charts will show blocks on the main consensus chain only. That wouldn't include any honest blocks that got orphaned or any Qubic blocks that weren't broadcast because they lost the race.
-
m-relay<rucknium:monero.social> I mean, my line charts.
-
m-relay<barthman132:matrix.org> Ok it seems they’re starting back up again
-
DataHoarderyes, every hour, for 30 minutes
-
DataHoardersort of, it's fuzzy based on their ticks
-
m-relay<barthman132:matrix.org> They had 3ghz all yesterday
-
m-relay<barthman132:matrix.org> They had 3gh/s all yesterday
-
m-relay<gingeropolous:monero.social> ok, so even with superfast blocks, the attacker could still make empty blocks, and make massive re-orgs occasionally
-
m-relay<barthman132:matrix.org> Honestly at this point we have to hope their halving on Wednesday saves us.
-
m-relay<lordx3nu:matrix.org> Yeah I guess I'm looking for blocks found during the start and end of their marathon. I know sech has posted his internal data before 👀
-
DataHoarderfrom what could see they crossed 39-40%
-
DataHoardersee I gather the data but I don't chart or process it in a proper way :D
-
m-relay<lordx3nu:matrix.org> Haha of course you do, you are datahoarder
-
m-relay<captaincanaryllc:matrix.org> smaller blocks, fewer txs per block, same total confirmation lock time?
-
m-relay<captaincanaryllc:matrix.org> responding to this
-
DataHoarderI love replies irc.gammaspectra.live/35f618ff56e832e6/image.png
-
DataHoardersigh clipboard again
-
DataHoarderI should get around and make my new irc bridge proper for the rest of monero channels
-
DataHoarderit handles replies vastly better
-
m-relay<captaincanaryllc:matrix.org> meaning assuming blocks half the current size (example), would require twice as many confirmations to unlock (same amount of time)?
-
m-relay<gingeropolous:monero.social> yeah. so instead of waiting for 10 blocks, you wait for 20
-
m-relay<captaincanaryllc:matrix.org> 20 confirmations instead of 10. Wouldn't this make it more difficult (again) for adversary to reorg?
-
m-relay<gingeropolous:monero.social> yeah, afaiu
-
m-relay<gingeropolous:monero.social> same total proof of work performed, but the quicker blocks means the luck dragon has more chance to work with you (or against you)
-
m-relay<gingeropolous:monero.social> well in the case of like 30 second blocks, it would be 30 confirmations i guess
-
niocDataHoarder: yes please
-
m-relay<captaincanaryllc:matrix.org> their chances of getting blocks goes down, and their difficulty of getting confirmations goes up
-
» nioc tips DataHoarder 20xmr
-
DataHoarder:D
-
DataHoarderthe code is open source but it really isn't "production" ready. yet it has been working excellent over the past few months in p2pool channels
-
m-relay<gingeropolous:monero.social> i think the magic of the faster blocks is because the honest chain has a chance to find a new block faster. So the attacker has to always restart their attack to get their private chain longer
-
m-relay<spirobel:kernal.eu> + you get to keep the cpus.
-
m-relay<spirobel:kernal.eu> you dont lose anything
-
m-relay<spirobel:kernal.eu> in the case of pos the state is reversed and your stake is gone
-
m-relay<captaincanaryllc:matrix.org> does anyone want to start testing feasible block size/speed changes? ofrnxmr
-
m-relay<ofrnxmr:xmr.mx> with fcmp its hard to create txs fast enough to fill blocks. i think, A faster block time would lead to the most well connected miners often being the first-seen block, and smaller miners being orphaned more often
-
m-relay<gingeropolous:monero.social> according to Rucknium 's work: "About 80 percent of blocks arrived at all five Monero nodes within a one-second interval."
-
m-relay<ofrnxmr:xmr.mx> Thats sub-300kb blocks
-
m-relay<ofrnxmr:xmr.mx> Every ~2mins
-
m-relay<alexanarcho:matrix.org> damn unknown at 45%+ right now
-
m-relay<ofrnxmr:monero.social> Meanwhile zcash has 75% on one pool
-
m-relay<elongated:matrix.org> Honest pool they say 😅
-
m-relay<diego:cypherstack.com> An interesting attack to do on Zcash is if said big pool only put in non shielded stuff in the blocks forever.
-
m-relay<diego:cypherstack.com> Effectively making it Bitcoin.
-
m-relay<elongated:matrix.org> Ztrash foundation probably owns that pool
14 seconds ago