Potentially interesting discussion from Discord:

modnar()
 —
Yesterday at 9:52 PM
What makes Qogecoin better than other cryptocurrencies that boast some form of hardness to a quantum threat?
securefreak
 —
Today at 5:07 AM
I'll answer, since no one else has. Nothing, right now.
and it will remain that way until something tangible is produced that can take advantage of the coin.
Right now the only way to hold QOGE is a wallet that requires a desktop computer and that only works on Windows and Linux right now. An Mac wallet apparently is being worked on but unsure if it works with the new macs with M1/2 processors
So until either the people who created the coin get things out or there is more involvement in the community to help them, there is not really anything that stands out at all right now
neqochan
 —
Today at 8:13 AM
Additionally to what @securefreak said, it should be mentioned that we are the only QS-focused cryptocurrency that is upstream with Bitcoin. This means that we build on a very stable, well tested codebase.

This is a stark contrast to most other Altcoins in general, which are usually based on very old versions of bitcoin or litecoin. We were originaly also based on such an old codebase and had a hardfork a few weeks ago to migrate all functionality such as segwit. This makes Qogecoin a lot feature-richer by default than most altcoins regardless of quantum safety.

Some currencies have completely custom codebases, but unless one has a huge team like Solana, I don't think it is feasible to implement something from scratch. We have very high standards regarding production quality of software in general and completely writing a Blockchain from scratch that satisfies these requirements is currently unrealistic for us.

Apart from Quantum safety we focus heavily on infrastructure that is viable in the long term. I don't think there are many other Altcoins where the developers are contributing fixes to open source projects like Clang/LLVM and hipSYCL (and likely the experimental Carbon language soon) to make the absolute bleeding edge of software infrastructure usable for their Project.

Introduced relative_includes, relative_angled_includes, transitive_relative_includes and transitive_relative_angled_includes in https://github.com/eomii/rules_ll/releases/tag/20220612.0. These let us use workspace-relative imports in our build files. This makes custom dependency overlays much easier to maintain.

Before this change we had to use something like to use custom include paths. This was already not pretty before bzlmod, but didn't really manifest itself as an issue since old workspace includes had no version numbers and as such would stay usable across updates.

With bzlmod every dependency has a version number, so these paths became This made it very painful to maintain overlays, as we had to bump that version in every instance of these include attributes.

With the new relative attributes we can now simply use to achieve the same. So we no longer need to update every attribute instance when we bump a version. The old way is still present so that we can use out-of-tree local include paths such as
A big quality of life improvement