<f​iatmoneysucks:matrix.org> The research mentions Ed25519 as a type of EdDSA. on page 2/7. "In contrast to ECDSA-based systems, several modern blockchains, including SUI, Solana, and Near, employ EdDSA (typically Ed25519)."

<i​nterestingband:matrix.org> it looks like smth interesting is happening with mining; :D

<s​packle:monero.social> Fun thought: You could enforce solo mining on some fraction of blocks; leaving a portion of blocks available for pool mining. This could limit malicious pool actions while still allowing pools to operate.

<r​brunner7:monero.social> Very interesting thought

<1​7lifers:matrix.org> yes

<1​7lifers:matrix.org> let's have war between pools who owns the most blocks

<1​7lifers:matrix.org> "haha supportxmr admin you suck i have 2 more blocks than u"

<1​7lifers:matrix.org> "oh look at hashvault admin crying about me having 4 blocks more than him"

<s​packle:monero.social> 17lifers (Ryan): I am not sure I follow your thinking.

<l​m:matrix.baermail.fr> That would be ideal to have only solo miners and p2pool working. Small miners can gather and counter big miners instead of giving up like apparently what happened to wownero.

hmm, it's possible to do a hybrid approach: demand the first coinbase output to be some % of the block reward (10% for example) and be signed with the private key, and the rest of the block reward can go to as many outputs as you need. Regular pools can still exist with 90% of the block reward (thus unprofitable), solo miners and P2Pool can exist

too (P2Pool miners will receive 90% of the block reward regularly in small portions, and 10% in solo-like mode). The percentages can be tweaked. This will give P2Pool 10% edge over the regular pools

Need to think more about this idea

<a​ntilt:we2.ee> this would be ideal

regular pools could also just do two outputs, with the 10/90% split, and worst case they get one output stolen

Yes

And anyone can steal it

unless they have per-miner keys

<s​packle:monero.social> I would think that forcing some blocks to be entirely solo mined would offer the best protection against the attack recently discussed. It ensures the block sequence is a collaboration between pools and solo miners.

<s​packle:monero.social> Compare this against allowing a malicious pool to produce the entire block sequence, even if doing so at economic disadvantage.

<a​ntilt:we2.ee> this is the incentive afaik. Getting your funds stolen by your fellow attackers may also help ironing out the mob mentality

<p​reland:monero.social> According to cfb (great src ik) block 3471232 should be marked as malicious by moneroconsensus.info

He delayed the broadcast of that block, yes

But they didn't mine an alternative chain at that moment

it could be something interesting to add there, delayed blocks vs time seen

Okay, there is a message in discord that they will do selfish mining (whatever is their implementation) if their hashrate is above 2 GH/s, so probably already tonight.

<k​ayabanerve:matrix.org> 3.14stache: Ed25519 is not a type of EdDSA. Ed25519 is an elliptic curve over which EdDSA is frequently used, with an IETF-standardized specification available.

<b​oog900:monero.social> sech1 aren't they decentralized, can't we just listen to their network and broadcast blocks ourselves?

Mining there is centralized

<b​oog900:monero.social> so they are trusting the wallet owner to do the correct thing with mined coins?

yes, exactly

<r​brunner7:monero.social> And the wallet owner is, as far as I know, more or less a secret

Meanwhile, from an exchange support: "QUBIC is not working anywhere. Their chain has been getting DDOS'd and is barely running right now."

<u​ntraceable:monero.social> sharing some ideas from a Twitter user "reject empty blocks when tx in mempool; variable difficulty adjustment based on how many blocks certain pool has mined over a certain period of time like a day ( more blocks mined by the pool the higher difficulty needed by the pool to have its block accepted). limit blocks per miner per day"

We can't know who mined which block, wallet address is hidden

<a​ntilt:we2.ee> the "correct" thing: to pretend he burned some shitcoin they bubbled into, keep the xmr... and rug.

<l​ordx3nu:matrix.org> Apparently they are going to start 24 hour mining three days a week. Thursday, Saturday, and Monday.

<s​gp_:monero.social> This is old news by now, but we finally posted about it :) magicgrants.org/2025/08/05/Veridise-Gadgets-Circuit

<s​gp_:monero.social> I have one item to add to the agenda for tomorrow Rucknium : Veridise's reviews of Helioselene: gist.github.com/SamsungGalaxyPlayer/981e8281b91b49901f516eec54ee3c4d

<s​gp_:monero.social> I know the deadline is supposed to be Monday, so I know it might not be possible to get a "final" approval during the meeting. I was waiting on one remaining option for the curve review which delayed me posting this here by a few days.

<b​inspacepart:matrix.org> when I looked at the paper earlier, it seemed to me that the important point was actually the existence and use of a single standardized key derivation algorithm, and the fact that the user keeps that seed derivation in addition to the private key

Qubic has started selfish mining, they are delaying broadcast of their blocks, right now

No reorgs so far

<l​ordx3nu:matrix.org> Looks like there was a split on monero consensus

<l​ordx3nu:matrix.org> For 3471456

<o​frnxmr:monero.social> [@rucknium:monero.social](https://matrix.to/#/@rucknium:monero.social) can you make the visual show the details on the block that follows the winning chain?

<o​frnxmr:monero.social> So we can see who mined the longest chain after an alt

<o​frnxmr:monero.social> There are 5 alt blocks, 4 of which were won on the unknown side. The question i have, is who mined the block that made the unknown chain longer

<r​ucknium:monero.social> AFAIK, if you selfish mine with less than about 33% of hashpower, you are just shooting yourself in the foot: cs.cornell.edu/~kevinnegy/Selfish%20Mining%20Re-Examined.pdf

<r​ucknium:monero.social> "Shooting yourself in the foot" = earning less revenue than just using the standard honest mining strategy.

<r​ucknium:monero.social> ofrnxmr: You mean un-hide the next block in the main chain? Yes, I think that should be easy.

<r​ucknium:monero.social> flip flop: I will add "Nonoutsourceable Scratch-Off Puzzles to Discourage Bitcoin Mining Coalitions" to the links in the mining centralization agenda item.

<r​ucknium:monero.social> sgp_: I will add to the agenda.

I observer 2 of Qubic's blocks orphaned so far, but they're not on moneroconsensus.info because they were never broadcasted to the network

*observed

5d064a260f522c4cbcdb4db9bb683a8d26ec9af70d6cd4beb7ac842990ba5232 at height 3471493

<r​ucknium:monero.social> ^ Foot shooting commenced

654e61155659de2109f44c6fec8f4da52c9b3f6bc29c35faf6fee70aafca88ff at height 3471495

<r​ucknium:monero.social> potentially

Not potentially, I have my own sources. Can't disclose right now. These were two Qubic's orphaned blocks

<3​21bob321:monero.social> Insider trading

<b​oog900:monero.social> looking at my node logs it synced 3471456 and 3471457 (had to ask for the blocks), it was not sent them

<b​oog900:monero.social> I wonder if that is why 3471493 and 3471495 were not sent around the network

<b​oog900:monero.social> they were not ahead so no node asked for them

they were not broadcasted at all

<b​oog900:monero.social> yeah but neither was 3471456 and 3471457 (to my node)

<b​oog900:monero.social> my node had to ask for them

One more Qubic's block orphaned, 8a576d911c3d50be8fbf2a008462c56ff06d211ab84246cbd5719e4055c5c569

Their selfish mining doesn't work out