TechLife Ledger

Qubic vs. Monero, preliminary results: (For those who do not know me, I am not affiliated with Qubic, I do not hold any Qubic, and I am plausibly the most vocal and obnoxious Qubic critic to date. That's exactly why they hired me). I was provided a wallet seed by @c___f___b from which I generated the public view key: 7804f957c13215e6c98d54c443d16d36e603ca8a4c81ced9e46449bcbd7c6696 In this post, I will inaccurately refer to blocks whose coinbase transaction can be associated back to this wallet as "blocks created by qubic", and refer to the ratio between such blocks and other on-chain blocks as the amount of blocks "created by qubic". This is not the full picture, but it is accurate enough for now. In the full report (which will hopefully be posted tonight or tomorrow), I explain the limitations of the method, and make more careful inferences of the data. (I will also provide the full list of blocks created by the wallet, as well as tx_proofs that can be cross-checked against any Monero node to verify the results.) That being said, the preliminary view is honestly a bit astounding. In the graph below, the blue line shows the fraction of blocks created by CFB's wallet out of all blocks created up to that time. The red line shows the fraction in a sliding (centered) window of 30 blocks (about one hour). As we can see, while not quite being able to maintain superiority for the entire range, there are quite a few one-hour-long windows where Qubic created almost as many as 80% of the blocks in the window. This does not mean that Qubic managed to hit 80% of the typical XMR hashrate. In these magnitudes of fluctuation, there are forces pulling in all directions, from switch mining to selfish mining. But it defnitely means that Qubic genuinely disrupted Monero by hash power alone. In the full report, I will discuss in greater length what can be inferred and to what degree of confidence. And will also use the stage to remind that I warned against these kinds of scenarios more than three years ago, against ASIC "resistance" in general, and RandomX in particular. The same threat lingers over other bloated hashes such as Ethash and Scrypt. The only defense against this kind of raiding is to make sure ASICs are many orders of magnitude more efficient than any existing generic hardware, and (to the best of my knowledge) that can only be achieved by ASIC friendliness. Anything else might be appealing to miners and easier to justify, but it will always face these kinds of threats.