I think the whole PoS finality layer thing got out of proportions because people heard PoS and flipped.
At the beginning, the Monero Research Lab was just gathering ideas on how to deal with the situation and that was one of the ideas proposed.
People heard PoS, and it went viral, with all the misunderstanding that virality and oversimplification bring.

If you listen to KabayaNerve on MoneroTalk you will see that he proposed that and immediately said that the PoS finality layer will not get community approval and is very unlikely to be implemented.
You still have people on Twitter saying that some undefined people that may or may not be Monero devs are pushing for Monero to become a PoS coin like Ethereum. It’s simple, it’s emotional, it got viral, the only issue is that it’s wrong (it’s not an accurate description of what is happening).

For BTC, I think that the huge network effects are the main reasons for it maintaining its price and thus security budget until now (as for any coin, you could say).
As you said, it will be interesting to see how the situation develops after 2 more halvings.
A conclusion in my article is that BTC now has a king, and its name is Blockstream. They control the network and will update it as they see fit, what the plebs and jealous people like us think is of no importance. They will never let that much power evaporate from their hands, and will rather hardfork into PoS than letting that happen because some miner does not make enough money.
The original Bitcoin is dead, long live Bitcoin

Haha! STDs for Monero devs! The analogy is funny.

You got it, the finality layer is complex and needs a lot of conditions to be done right, and it’s outsourcing security to another network, not great.

I don’t think that the current BTC POW is that elegant though. Mining rewards are declining, and the fees are not coming. So the security budget is declining at each halving. At some point, mining hashrate will decrease, because miners run a business, and BTC will also be open for the same kinds of disruptions.
I once wrote an article on the topic.

I agree that a PoS consensus is not suitable for what Monero wants to be.

BTW, how come you have a laser eyes profile pic, but you can critically analyze things about BTC? I always thought that people with laser eyes profile pics where maxis that did not accept any criticism of BTC. It’s refreshing to see a change!

I don’t think it will happen either, the community too much opposed.

First there are people that don’t take the time to read about it and think it’s about changing from RandomX mining to staking. Then there are people like me that do not want to rely on another chain for the security of Monero.

It’s still good to discuss it openly. This way, we can get to a better solution and the community can decide in what way this PoS finality layer can be a contingency plan or not.

I understand, I also agree that it would be a shame.

Nevertheless, I want people to feel free to discuss it, discussing this as one option among many could bring the community to a better, stronger solution.

It’s true that we should not rush into action without carefully considering the consequences in the short and long term.

The attack still demonstrates an important point of improvement for the Monero ecosystem. We now have a hostile mining pool with too much hashrate and it’s time to dust off the theoretical attack scenarios and see what harm it can do and what we can do about it.

The attacker can and does reorg blocks as a consequence of selfish mining. That means less mining rewards for the other miners.

The attacker cannot censor any specific transaction (because the transactions are private so there is no easy way to differentiate any specific one). They could still decide to only mine empty blocks or their own transactions, and that would increase confirmation times for all the other users.

The attacker can try a double spend attack, for example on an exchange. They can deposit XMR at the exchange, get BCH for it and withdraw it. Then they reorg the latest blocks up to before depositing their XMR to add a transaction before that deposit. That transaction will send that previously deposited XMR to one of their other wallets instead of going to the exchange.
If this attack is successful, in the end, they will have both the BCH from the exchange and the XMR in their other wallet.
This is actually why Kraken has increased their confirmation times for XMR to 24 hours. When you increase the confirmation time, you increase the number of blocks between the XMR deposit and the BCH withdrawal in the scenario above. So much so that even with 80% of the hashrate the attack is no longer feasible.

There are other points I guess, but we need to address these. Some action needs to be taken to improve, but as you said, we need to be careful.

He was using moneroocean, I am not sure if he moved to something else now.

Xenu was using moneroocean and you can actually visually see the bump in hash on mining pool stats when he started.
It’s true that this effort would have been even better if we had a way to outbid the hostile mining pool when they start their attack.
This is still a valid and valuable effort IMO.

A community effort to gather resources to counter the hostile mining pool, led by antimoonboy

Xenu is not a rando.
He is the host of antimoonboy, a well known Monero focused podcast.
For this Monero Defense fund, he was using moneroocean and you can actually visually see the bump in hash on mining pool stats when he started.

Xenu is the host of antimoonboy, a well known Monero focused podcast.
For this Monero Defense fund, he was using moneroocean and you can actually visually see the bump in hash on mining pool stats when he started.

This is very close the the finality layer idea being discussed currently.
The idea is to record somewhere that this or that block has been seen and is considered final. At that point, even if someone publishes a longer chain afterwards, the longer chain will be ignored as it does not continue from the blocks that have been finalized already.

It is an interesting and good idea @qwerty@discuss.tchncs.de. There are some technical and community details that need consideration as to how exactly to implement that, but it’s one of the good options on the table.

For example, one of the technical details is were/how should we record that a block is finalized.
For this, we need to align a lot of decentralized nodes on a common state of things (which block is finalized), so that they are aligned on what has happened and what has not.
We actually already have a solution for that: a blockchain. Blockchains are a solution to the byzantine general’s problem (a.k.a aligning decentralized actors with each other on a shared state of things, even though they do not all communicate with one another, they communicate at different speed, etc).
So we could use a blockchain to record that this or that Monero block is finalized.
It needs to be a different blockchain, and have some characteristics like fast enough block time, a way to avoid deep re-orgs (POW with enough security budget or POS),…
Right now if you directly apply these conditions, you end up on the bright idea of using Ethereum or something like Litecoin.
The Monero community does NOT want to have to rely on ETH or LTC for security.
That would feel like a huge blow and a huge let down…

But yeah, if need be, for me, this is still a perfectly acceptable temporary solution.
What do you think?

If I remember correctly, that’s partly because p2pool requires access to a full node with the whole blockchain, while a lot (or some?) of the current hash rate is not running their own nodes.
If you somehow force everyone to p2pool we are not sure of the distribution and decentralization of the remaining miners, as some mining will drop out instead of running their own node.
Sometimes it’s because they don’t have the 200gb available for storing the blockchain. Sometimes they are mining multiple blockchains and requiring a full monero node is too much hassle.

Granted, with p2pool you can mine using someone else’s full node and let it spy on you a bit. Do we want that?

The other big issue is that you would have to hard-fork changes to the protocol to impose p2pool and that’s a big change that should be carefully considered, not done in a rush.

We have to remember that Monero is fine for now (as in not dying right now), we are preparing mitigations for POW centralization issues and the cure should not be more severe than the disease.

Thanks! I have fixed it now

Wait! You don’t know about the blocksize war?
You will be amazed after reading Hijacking Bitcoin

Monero and Bitcoin Cash have a lot of common in their goals and community, don’t pay attention to the downvotes.

Monero is still fine, maybe if something unexpected happens we can use BCH for the finality layer of Monero? I don’t remember the hash rate on BCH and it’s potential for the same centralization. The 10 minutes block time might be an issue for that though.

I am using a new wallet for this, I don’t actually plan on using the cents I will receive there.
Using the smaller pools is an interesting idea, I might try that later on

Thank you for supporting the network!

Right now the difficulty setup of the mining is the same for all the miners.
All the miners are trying to solve the same equation, randomly trying this or that value to see if it matches.
The first one to propose a value that solves the equation gets to mine the new block and gets the block reward.
When new miners join in, there is no mechanism to differentiate them, from the protocol’s POV. If a miner joins p2pool there are things there to identify them, but not on the general Monero protocol.
In the general Monero protocol, you just need to be the first to find a solution to the equation and propose the new block. You don’t even have to be the one that mined it (found the solution and proposed the block) you just need to send it, so someone could do all the heaving mining and send you the new block and you will be the first one to send it to the network.

The way the protocol manages miners arriving and leaving is via the difficulty adjustment. When a lot of new miners join, the increased hash rate will make it easier to find the solution to the equation, so new blocks will come more often.
That means that the time between blocks will be less than the desired 2 minutes. After a while, the protocol will notice that and increase the difficulty so that we get back to 2 minutes. The same happens when miners leave, there is less computational power to find the new blocks, it takes more than 2 minutes, and the protocol will reduce the difficulty to get back to 2 minutes.

Right now the difficulty is not for single miners, but for the network as a whole. There is no easy way to implement this idea, I am not sure adding name tags to this or that hash power would be a good thing, and it looks easy to bypass.

p.s: Thank you for no longer keeping to yourself, we are glad to have another voice to chat with, and this forum will grow thanks to that!
KabayaNerve (Monero dev) has made a github issue where people are invited to post their ideas. You can get more inspiration from there.

Thanks, I am going to try this

Yes, engaging a huge attack directly this way would mean having in the end a lot of regular users spinning up gupax.
But the main benefit here is that for me and anyone else doing that, it’s practically free to run the miner.
We don’t need to have a million users running gupax, it starts with 10, then 100, then 1000, then more.
We don’t need to reach a million in any case. Each additional miner, as small as his share is, is a direct additional cost for the attacker.
The small miners can add hashrate for free, and the attacker always needs to compensate that and add some more on top.
Remember, this attack is expensive for the attacker, and its funds are limited.

This asymmetry is key, don’t let the whale discourage the shrimps from banding together.

And as Malcom X said, don’t let your enemy tell you how many of you there are.