<o​range_horizon:matrix.org> I haven't investigated qubics tokenomics in depth, but it according to their tracker they burned the most in epoch 174. burned 120 billion qubic, while the epoch emitted 1 trillion. i would argue that the price pump has little to do with the actual burn and much to do with the increased attention the have. hence my argument is that although the rewards do help them in the attack, <clipped m

<o​range_horizon:matrix.org> more important to them is to control the narrative that they are being successful at what they are doing.

<o​range_horizon:matrix.org> but its not all about qubic either. State actors may have much deeper pockets and not require the reward, preferring to allow miners to keep it so that the attack goes unnoticed as long as possible.

<o​range_horizon:matrix.org> Under solo mining enforced only, would p2pool still operate?

<l​eonarth_:matrix.org> any pool can operate but the reward goes exclusively to the miner that signed the block

<l​eonarth_:matrix.org> if the block is unsigned then it's business as usual but the reward is halved

<o​range_horizon:matrix.org> doesn't that then basically provide a downward pressure on legitimate mining? I mean if I have a typical desktop PC it could be a year or more before I see a reward. realistically the network needs to incentivise mining if it is going to succeed. otherwise there would not be a good enough defense.

<l​eonarth_:matrix.org> the game theory incentives must be thought through

<l​eonarth_:matrix.org> definitely hashrate will drop as pools dismantle and more people start mining individually instead of sending hash to pools

<o​range_horizon:matrix.org> To me, Monero is attractive because it is an everyday currency, for everyday people. I value most that there is reward in an everyday person mining, and there is also the possibility of spending it and using it on everyday purchases. I'd love to see ideas implemented that somehow manage to incentivise the everyday person against the more powerful. because that I think is how we wi<clipped m

<o​range_horizon:matrix.org> n. if every normal person loves it and uses it, then in countries that allow as such, they will vote to protect it also.

<g​ingeropolous:monero.social> so we don't need monerosim to investigate this blocktime thing. that can just be done with 2 private testnet nodes pitted against each other with different blocktimes and different hashrate distribution percentages

<g​ingeropolous:monero.social> make a script for the attacking node to selfish mine, and just run it a whole lot

<d​iw_tim:matrix.org> It did not do "fuck all". Their hash rate has declined from consistently getting 3+ GH/s, even 4+ GH/s at times, to 1-2 GH/s, and that's excluding the loss of confidence in their token as the price plummets. The situation is worsened by the fact that miners receive tokens, which they try to sell before other miners, triggering a cascading effect. More people are shorting Qubic as <clipped message>

<d​iw_tim:matrix.org> well increasing pressure on their ponzi scheme. Qubic miners no longer earn double their investment due to the halving event and decline in price. Some miners have abandoned mining there, including those from hashvault. Why spread bullshit?

<b​arthman132:matrix.org> They never got 4ghs I believe. They did get to 3ghs, but that was their peak that I saw. The 4ghs they reported was fake and like 10 minutes later it dropped by half

<b​arthman132:matrix.org> Qubic is still able to do big reorgs, because nobody other than whales or die hard idealists mine monero. There’s simply zero incentive to do so and as long as that’s the case. monero will be vulnerable to a 51% attacks in the present and in the future.

<b​arthman132:matrix.org> You’re right! Qubic miners earned 3 times more than a monero miner before the halving. Now they earn around double

<b​arthman132:matrix.org> The qubic halving honestly definitely didn’t effect them as I hoped it would. Sure the price of the Qubic did drop and the puts pressure on them, but on their marathons, they still get 2.5 to 2.8ghs pretty consistently. That’s still like 40% of the monero hashrate and they still able to do massive 8 block reorgs.

<b​arthman132:matrix.org> The qubic halving honestly definitely didn’t effect them as I hoped it would. Sure the price of Qubic did drop and the puts pressure on them, but on their marathons, they still get 2.5 to 2.8ghs pretty consistently. That’s still like 40% of the monero hashrate and they still able to do massive 8 block reorgs.

<h​bs:matrix.org> There is an incentive to mine Monero, securing the Monero network because Monero is useful

<b​arthman132:matrix.org> If that’s a enough of a incentive for then great, but it’s not for most miners tbh

<b​arthman132:matrix.org> If that’s a enough of a incentive for you then great, but it’s not for most miners tbh

<l​eonarth_:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/tMdJWTayAprFVjKSAmRefywI

<l​eonarth_:matrix.org> getting dangerous

<b​asses:matrix.org> website?

<l​eonarth_:matrix.org> xmrstats

<l​eonarth_:matrix.org> doing `sweep_all index=all address` from cli should allow me to restore the wallet from that tx block, reducing my sync time, right?

<n​eromonero1024:monero.social> yes

<l​eonarth_:matrix.org> though if I want to see all the transaction history I can just use the old wallet height and all txs would reappear

yes

<l​eonarth_:matrix.org> thank you guys

<b​arthman132:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/JwWUekDxzIlAgnhYgKoOJtCu

<b​arthman132:matrix.org> Is the network one right? Because the hashrate from the pools is different from the network and when Qubic stops mining it doesn’t seem to calculate it correctly

<o​frnxmr:monero.social> Proudly said by a non-miner, likely no-coiner

cant see screenshot :)

<b​arthman132:matrix.org> What do you mean they were able orphan 5% of blocks. Hell in some days it reaches almost 10%

<b​arthman132:matrix.org> What do you mean? they were able orphan 5% of blocks. Hell in some days it reaches almost 10%

<o​frnxmr:monero.social> Whats your hashrate?

<b​arthman132:matrix.org> Cringe

<o​frnxmr:monero.social> Very much so

<b​arthman132:matrix.org> I own cryptocurrency, but it’s not replacing fiat

<b​arthman132:matrix.org> You may hate my take, but deep down you know I’m right

You may take my hate, but down down I think I'm wrong.

<o​frnxmr:monero.social> Not even close

<o​frnxmr:monero.social> @bart

The sad metaphor for the new fascist takeover.

<b​arthman132:matrix.org> Fascist takeover?

Well, I guess worsening rather than takeover if you prefer.

Ignore me. Your line just had me muse on the hateful shit going down in various places.

<b​arthman132:matrix.org> Can I ask a question? Why is the network hashrate different from the hashrate from miningpoolstats?

Could be a difference between reported hash rate from shares and derivation from network difficulty.

You can't know current network hash rate, unless you monitor every miner at the same time. Both measures are approximations.

Pool reporting is probably the one most likely to be closer to the trust if pools are honest, but is the one that's much easier to lie about.

Derivation from diff will always lag by a fair bit, but can only be messed with by actually mining/not mining (and playing with block timestamps to some extent).

<b​arthman132:matrix.org> Because the network hashrate doesn’t actually move down with qubic once they turn off their pool for like 15 minutes each hour. However the hashrate one does

"closer to the truth" above, but the typo also works.

I have no idea about this, I'm not following the antics. But mining 45/60 could be to avoid bringing network diff up too much.

Or they have heavy hourly cron jobs.

<b​arthman132:matrix.org> Well even if you have 40% of the hashrate you could still get 51% of blocks if you’re lucky. Also if the network one was accurate then Qubic already passed the 51% of the network plenty of times

Yes, it's a random process. If you throw a dice 100 times, you might well get a 1 5 times in a row.

monero-blocks now has -nodejs-pools to pass compatible nodejs apis to the program without changing the code, so you can expose your own or other custom scripts git.gammaspectra.live/WeebDataHoarder/monero-blocks

<e​ye_i:matrix.org> 1700Kh/s

<e​ye_i:matrix.org> O7

<o​frnxmr:monero.social> @bart the "network" column is calculated based on the difficulty.

<o​frnxmr:monero.social> if i am the only miner on the network, and have 10gh, but only mine for 5 mins every 10 mins, the "network" will report ~5gh

<o​frnxmr:monero.social> its not a realtime stat, and doesn't and cant account for hashrate it doesnt know about

<o​frnxmr:monero.social> Surpassing 50% of that number does not mean you have 50% of the hashrate. If they mined for 24hrs, that number would increase to ~7gh

some new orphans have shown up on moneroconsensus.info but they seem to be old qubic's blocks

<b​arthman132:matrix.org> Ok thanks for the explanation

<o​frnxmr:monero.social> Its "gaming" the difficulty. A lower difficulty allows one to find blocks faster. This is likely why qubic does not mine constantly — to avoid raising the difficulty.

<b​arthman132:matrix.org> Ok thanks. I was just trying to figure out which one was more relevant.

<o​frnxmr:monero.social> neither

<b​arthman132:matrix.org> In terms of how much of a percentage of the hashrate Qubic has I meant as of right now

<o​frnxmr:monero.social> The "hashrate" is self-reported, and only includes pools. The "network" is calculated based on difficulty/block production, and doesnt account for selfish mining / reorgs.

<o​frnxmr:monero.social> the hashrate is abt 5gh without them

<b​arthman132:matrix.org> Sounds about right. Once they stop mining once in a while the hashrate goes from a 6 to around a 4.5

<o​frnxmr:monero.social> "4.5" is only pools

<b​arthman132:matrix.org> Ok then add around a .5 for everyone else and you get a 5

<o​frnxmr:xmr.mx> probably less than .5, but yea

<b​arthman132:matrix.org> How do you guys think we can get monero easier to buy? The most common way people get monero is just to exchange other cryptocurrencies for it

<o​frnxmr:xmr.mx> can ya try to use proper rooms

<o​frnxmr:xmr.mx> [#monero:monero.social](https://matrix.to/#/%23monero:monero.social) is probably a good place for that

<b​arthman132:matrix.org> Oh ok sorry. What do you think can be done against malicious remote nodes?

<o​frnxmr:xmr.mx> Define malicious

<s​yntheticbird:monero.social> me

<s​yntheticbird:monero.social> im malicious

<b​arthman132:matrix.org> A malicious node is a node that is controlled by the government to trace monero transactions and can even slap IP addresses to monero wallets.

<o​frnxmr:xmr.mx> Dont use them

<b​arthman132:matrix.org> The problem is you can’t really be sure if the remote node you’re using is malicious or not. The only way to avoid this is to use your own local node, but most monero users use remote nodes for their transactions.

<o​frnxmr:xmr.mx> Don't use nodes that you don't trust

<o​frnxmr:xmr.mx> And, like any internet activity, if you dont want to share your ip with the operator of the service, then dont.

<b​arthman132:matrix.org> What new features are planned in the feature for monero?

<o​ne-horse-wagon:monero.social> You might like to follow the conversations in the Monero Dev room.

<o​frnxmr:xmr.mx> monero planned features: confidential, permissionless, secure, reliable, fast, scalable currency

<b​arthman132:matrix.org> Well I was more or less asking what features are planned or in development right now. Like features FCMP and stuff like that

<o​frnxmr:xmr.mx> really depends if your asking about features for users, or backend festures

<b​arthman132:matrix.org> Both

<o​frnxmr:xmr.mx> Features that users will notice: none. Monero works as intended

<b​arthman132:matrix.org> Yes, but ring signatures were getting a little outdated tbh and it’s good we’re moving to FCMP

<o​frnxmr:xmr.mx> Features on the backend: sock5 support, p2p encryption, dynamic block sync size, peer selection improvements, tx relay efficiency improvements

<b​arthman132:matrix.org> Sock 5 support and the p2p encryption sound pretty good

<o​frnxmr:monero.social> Is there no way to include orphans in the difficulty calculation?