<r​ucknium:monero.social> Two people requested it and the statement would reflect what I am actually working on at the moment, e.g. moneroconsensus.info

Monero Network Simulation Tool has moved to funding! ccs.getmonero.org/proposals/gingeropolous-netsim.html

Revuo Monero maintenance (2025 Q3) has moved to funding! ccs.getmonero.org/proposals/revuo-monero-maintenance-2025-q3.html

acx part-time work on Monfluo 2025Q3 has moved to funding! ccs.getmonero.org/proposals/acx-mon…ance-and-further-development-2.html

Rucknium Research II has moved to funding! ccs.getmonero.org/proposals/Rucknium-Research-II.html

vtnerd full-time 2025 q3 has moved to funding! ccs.getmonero.org/proposals/vtnerd-2025-q3.html

<a​lfieedwards:monero.social> I do not have a Github account but wanted to ask about a particular comment from fluffypony:

<a​lfieedwards:monero.social> monero-project/research-lab #136#issuecomment-3171174945

<a​lfieedwards:monero.social> > Literally impossible. Pools have NO OBLIGATION to identify themselves in block metadata, and even if they did, a pool could literally pretend to be another pool / multiple separate pools. We only know how much hashrate pools have because they self report + tag blocks.

<a​lfieedwards:monero.social> Considering solo miners likely constitute of just around 2% of hashrate (according to Unknown part of graph from MiningPoolStats before Qubic has disabled API access):

<a​lfieedwards:monero.social> 1. Why is it not possible (with or without hard fork) to secure the network by requiring miners to place their ECDSA signature somewhere in a mined block? Why impersonation is used as argument if ECDSA signatures are not possible to be spoofed if Monero software is given a public key?

<a​lfieedwards:monero.social> 2. Could someone explain why whitelisting mining pools (by their signature requirement) is not being considered? Each Monero update could include updated whitelist of public keys that belong to approved mining pools. Blocks mined by unknown entities could be rejected by the network. Known mining pools with good reputation (P2Pool, SupportXMR, and others) would just need to request<clipped messag

<a​lfieedwards:monero.social> to be whitelisted. A mining pool that would turn out to be harmful (acting malicious by mining empty blocks, openly announcing 51% attack, etc) could get excluded.

<a​lfieedwards:monero.social> I ask about this solution because many other networks do exclude malicious peers. Tor for example excludes various groups of malicious relays and protects their network this way.

<r​ucknium:monero.social> Alfie Edwards: Probably because permissionless mining is a Monero principle.

<p​reland:monero.social> Second what Ruck said; a “whitelist” isn’t a viable solution

<r​brunner7:monero.social> If you think such whitelisting through to extreme levels, you could arrive at quite crazy results, like a single PC under control of the most respected and trusted person in all Monero community doing all the mining. What do we need all that pool circus for if it's all about "reputation" :)

<a​lfieedwards:monero.social> Joining P2Pool does not require permission though...

<a​lfieedwards:monero.social> Could you elaborate what you mean by a single PC doing all the mining? How that would happen in theory?

<r​brunner7:monero.social> We would just mandate it. If some sort of committee can decide which pools "have good reputation" and are therefore allowed, and which not, you can go on and discard those pools altogether. That committee just makes a vote for the "most trusted and respected Monero person", and that will do the mining.

<a​lfieedwards:monero.social> This is the same risk as implementing a backdoor in Monero software by commitee of current Monero developers. If backdoor is not to be considered a practical risk at the moment, why tampering with whitelist would?

<r​brunner7:monero.social> Why do you call that a risk? As I understand your proposal, we would *want* to have some group of people decide about "pool reputation". That would become the new "modus operandi" of Monero, the cryptocurrency.

<r​brunner7:monero.social> That would not be a power grab, or something hidden, no conspiracy, we would just say "from now on pools have a reputation, and if it's too low, we kick it"

<r​brunner7:monero.social> And everybody cheers if that bad, bad pool that everybody dislikes finally gets the boot

<a​lfieedwards:monero.social> It is not about likeness, but defined requirements for a mining pool to be accepted.

<r​brunner7:monero.social> I think there is a saying "sweet summer child" :)

<r​brunner7:monero.social> This is one of my core convictions about cryptocurrencies, gained in 7 years into Monero: If you give up "trustless" and "permissionless" in the running of the network, you can forget all that crazy blockchain, mining, consensus stuff and just use PayPal.

<a​lfieedwards:monero.social> Trustless designs do not exist. In every software there is a trust model. If you do not trust developers, you fork or choose alternative. If you imagine a scenario of all Monero devs turn evil and giving a single pool permission for all hashrate, then you can choose a different coin.

<r​brunner7:monero.social> Or Qubic, by the way. If you want to run a node for that network, you need "their" permission.

<r​brunner7:monero.social> And you can't really "mine" that coin.

<r​brunner7:monero.social> Note the end of this statement, that with "network": If you give up "trustless" and "permissionless" in the running of the network

<r​brunner7:monero.social> Of course there are tons of trust in software development, I would be dumb not to grasp that

If we care about keeping Monero trustless and permissionless, promoting P2Pool is a better path than any whitelist. It gives us both decentralization and improved security, without introducing the need to “approve” miners.

<a​lfieedwards:monero.social> If mentioned Qubic, or any other botnet will 51% attack then we all will pay a huge cost of permisionless mining.

<r​brunner7:monero.social> What will be that "huge cost"?

<a​lfieedwards:monero.social> Yes, I have included whitelisting P2Pool in my proposal. However, P2Pool won't reach a meaningful hashrate in any near future.

<a​lfieedwards:monero.social> That is because of modern marketing and centralisation tendencies. Army of Twitter bots now decide which mining pool will be the most popular and crowds follow the crowd.

<a​lfieedwards:monero.social> Other ideas mentioned on #136 seem to be much worse, either ineffective or requiring finality layer of different blockchain like Litecoin or Bitcoin.

<r​brunner7:monero.social> I see Qubic achieving their stated immediate goal - getting 51% of Monero's hashrate and then basically "orphan out" all other Monero miners - as some sort of singularity. Very, very hard to make predictions what will happen afterwards. Big surprises, also positive ones, may await us there.

<k​ayabanerve:matrix.org> Federating mining pools was an option I discussed early on.

<k​ayabanerve:matrix.org> It'd eliminate P2pool as P2pool can't sign blocks.

<k​ayabanerve:matrix.org> Not to mention, p2pool could otherwise be itself attacked.

<a​lfieedwards:monero.social> Maybe Qubic will exit scam, their developer is in Belarus, unlikely to get any legal consequences of that. Will sell all premined shitcoin to buy XMR at cheap. Monero price will then slowly increase back. I personally do not expect any positive surprises here.

<a​lfieedwards:monero.social> Why it can't sign blocks?

<k​ayabanerve:matrix.org> Because it's a decentralized network without an ECDSA private key?

<k​ayabanerve:matrix.org> (We also wouldn't use ECDSA of all things)

<a​lfieedwards:monero.social> Isn't P2Pool a sidechain, that could just be a source of information which blocks were mined using it?

<a​lfieedwards:monero.social> Why not?

<k​ayabanerve:matrix.org> Because ECDSA is a filthy algorithm requiring novel assumptions, with much worse multisig, and not currently in-use anywhere on the monero blockchain?

<k​ayabanerve:matrix.org> Right, so you could use the p2pool data to identify p2pool blocks (without requiring a signature), but again, then a malicious actor could launder malicious blocks through p2pool.

<a​lfieedwards:monero.social> So why P2Pool is declared as 51% attack solution?

<a​lfieedwards:monero.social> But EdDSA is. It isn't about particular algorithm but digital signatures in general.

<k​ayabanerve:matrix.org> P2pool isn't a 51% attack solution

<k​ayabanerve:matrix.org> Mining with p2pool is just better than pool mining

<k​ayabanerve:matrix.org> More honest miners on p2pool will make a 51% attack more difficult

<b​tclovera:matrix.org> A common mining pool "controls" hashrate that does not belong to it. A 51% attack is easy this way.

<b​tclovera:matrix.org> P2Pool is different because no one controls other people's hashrate. There is No admin pool

<b​tclovera:matrix.org> By the way guys, YouTube yesterday deleted 2 my YouTube channels because Monero Content. 😭 More specific Gupaxx and XMRig.

<b​tclovera:matrix.org> Today they returned one after appellation

<b​tclovera:matrix.org> But there is not a safe place 😬

<a​lfieedwards:monero.social> I get it, so with Qubic it is modified software that is used to control and give certain malicious objectives for miners using it. They could join P2Pool and it would not make a difference.

<a​lfieedwards:monero.social> Sadly, at getmonero.org/get-started/mining there is no mention about Gupax or Gupaxx, while it is probably the main source of information for new miners.

<a​lfieedwards:monero.social> Currently this page promotes P2Pool through more complicated setup, discouraging newbies. Might be one of reasons they choose centralized pools instead.

<a​lfieedwards:monero.social> Currently this page promotes P2Pool through more complicated setup, discouraging less technical newbies. Might be one of reasons they choose centralized pools instead.

<a​lfieedwards:monero.social> Maybe there could be a video embed with a tutorial if getmonero.org's webmasters agree.

<a​pplelover999:matrix.org> Interesting. Is it common to get Monero content pulled?

<b​tclovera:matrix.org> I got one strike a few months ago because of XMRig 🤨

<b​tclovera:matrix.org> Now I just not posting any links

<b​tclovera:matrix.org> Just returned the second one channel

<b​tclovera:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/elWGJhhQDmtwSpFdSBKELJST

<b​tclovera:matrix.org> Very fast to be honest

<b​tclovera:matrix.org> I have a lot of content about Monero

<b​tclovera:matrix.org> I think someone or somebody report my channel as "scam"

<m​onerobull:matrix.org> I kinda like the idea of "finalizing" with staking

<m​onerobull:matrix.org> Not as main consensus mechanism but as a backstop

<g​ingeropolous:monero.social> ugh. staking

<m​onerobull:matrix.org> With Zk proofs it could maybe be done without privacy impact

<g​ingeropolous:monero.social> just call 1800-mr-monero to get your block finalized

<m​onerobull:matrix.org> If it's 1 block per week it should really have been little centralization risks

<b​tclovera:matrix.org> This was discussed?

<m​onerobull:matrix.org> I saw kayaba talk about it on twitter

<m​onerobull:matrix.org> And it's also what I thought would be the best compromise

<m​onerobull:matrix.org> I would need to know the deeper implications though

<m​onerobull:matrix.org> Maybe I am overlooking something

<r​brunner7:monero.social> Looks like high traffic finally broke Ruck's moneroconsensus.info ...

<r​brunner7:monero.social> We may have literally dozens of Qubic fans display that constantly

<g​ingeropolous:monero.social> dozens!

<r​brunner7:monero.social> What's the box this is running on?

<r​ucknium:monero.social> It's not really a question of which box. It's the matter of Shiny Server community edition is single-threaded.

<r​ucknium:monero.social> I can kick everyone off. Watch this.

<r​ucknium:monero.social> Kicks off the idle clients. Everyone else just has to reload the page.

<r​ucknium:monero.social> There are a few things I can write more efficiently, but now that I allow a lot of custom parameters, caching wouldn't be as effective.

<m​onerobull:matrix.org> Do a 15 min idle timeout

<r​ucknium:monero.social> I might do that. I don't know what qualifies as idle, though. Not selecting any new inputs or not having the page in the foreground?

<r​ucknium:monero.social> I can increase the number of allowed connections, but I don't know at what point that will cause big slowdowns for everyone.

<r​ucknium:monero.social> Anyway, IMHO this app is a big success. I'm glad rbrunner said "go for it" two MRL meetings ago.

<r​ucknium:monero.social> Even if CfB may be my biggest customer ;)

<m​onerobull:matrix.org> It is very good yeah

<s​yntheticbird:monero.social> RUCKNIUM

<s​yntheticbird:monero.social> REWRITE IN RUST WHEN?

<s​yntheticbird:monero.social> SORRY FOR CAPS

<m​onerobull:matrix.org> Btw with the selfish mining, whenever they attempt to mine a longer chain and get overtaken they lose all blocks they have already mined right?

<m​onerobull:matrix.org> Because they can only get ahead 3-4 blocks with luck?

<r​ucknium:monero.social> Yes. There is no "uncle" reward on the Monero blockchain. Their losing blocks are not broadcast through the network, but CfB showed a few of them here, I think: xcancel.com/c___f___b/status/1954926476958028186

<r​ucknium:monero.social> The "unknown" ones that are orphaned. I think he is running the moneroconsneus.info app locally, including Qubic's private info.

<m​onerobull:matrix.org> You should sneak in malware /s

<m​onerobull:matrix.org> What would happen if the top 3 pools decided to no longer build on qubics chain

<r​ucknium:monero.social> Successful counterattack, AFAIK.

<r​ucknium:monero.social> And then some discussion about what happens if pools decide to coordinate on other issues.

<m​onerobull:matrix.org> Yeah I guess you kind of open Pandora's box with that

<r​brunner7:monero.social> Oh, wow, second 3 block reorg today a minute ago. Really good testing for our node software :)

good time for network simulation software

<l​ordx3nu:matrix.org> Based qubic

<j​effro256:monero.social> Like fighting a house fire with a nuclear bomb

[CCS Proposals] jeffro256 opened merge request #602: jefro256 full-time development 2025Q3 repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/602

[CCS Proposals] Jhon Rebkt opened merge request #603: Add proposal: MoneroSwap.ai — Privacy-First, Instant Monero Swap (80 XMR initial funding) repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/603

<3​21bob321:monero.social> Fckn ai

at least we will finally have a monero swap service ( ͡° ͜ʖ ͡°)