The block size is already unintentionally capped at ~100MB due to the details of the block sync protocol and server packet limits in monerod. The hard cap of 90MB that is being discussed in the MRL would be an explicit stopgap measure before other parts of the daemon broke, potentially causing net splits. Almost all proponents of this cap would be okay removing it in a future hard fork after the technical issues have been resolved.

How long does it hang there? It should only hang for ~1 second, it does that for me. Otherwise, the wallet is generated correctly.

https://shai-deshe.gitbook.io/parallel-thoughts/proof-of-work/the-qubic-minority-report

TLDR; just because you have >=51% of the blocks in a certain timespan, does NOT mean you control 51% of the hashrate. Due to probability, you can expect anyone with any non-zero hashrate to produce more than 50% of blocks in a timeframe of some length with some probability. If you near 33% of total hashrate, that can be pretty often in practice. According to this report, Qubic never breached 40% of the total hashrate, and hovered around 1/3 of the total hashrate during active mining marathons, which weren’t pepetually on-going. Qubic increased the average actualized hash-rate over its whole operation by ~5%.

Thank you! I’m excited to see how this goes

It’s the same size as the current public testnet, which is ~9.5GB on my machine.

Can you paste the body of the post, please? I’m currently network-blocked from Reddit.

I do not recommend this application whatsoever. The techniques used are far from “The proper way to churn Monero” and most are actively harmful to privacy. I hate to be so harsh, but this repo is a hot mess of all the worst ways to churn Monero clobbered together.

Please note that the private view key, barring some edge cases, can also see outgoing transactions for all practical tracing purposes. They however can’t see the outgoing destination address. See this presentation: https://youtu.be/MYzZ1DzSWCY?t=263 for more info.