Whenever qubic finds 2 blocks in quick succession, they don’t publish them and instead keep building on them in secret as long as they are 2 block ahead of the public chain. When the rest of the network gets close to them and is 1 block away, they publish their longest chain and cause a reorg. Since they don’t control 51% of the network if the rest of the miners/pools adopted a “first seen chain -1 n blocks” policy, so kept mining on the first seen chain as long as it’s only 1 block shorter than the longest one the qubic strat wouldn’t work and all their blocks would get re-orged instead.

  • ArseneSpeculoos@monero.town
    1·
    15 hours ago

    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?