RandomX on a Bitcoin fork invites botnets and churn. With a tiny fixed cap your security budget collapses after issuance. Add tail emission or expect cheap reorgs.
PQC should start hybrid. Add outputs spendable by ECDSA or Dilithium/Falcon. Publish signature size, verify time, and fee impact before launch.
A one-week "bootstrap" is a premine. You should drop it and do a public testnet instead. Then a coordinated mainnet with a frozen commit, reproducible builds, multiple independent seeds, and a start anchored to a a Bitcoin block height.
Thank you. This is exactly the kind of high-level, critical feedback this project needs. Let me address them
On PoW, Security Budget, and Tail Emission:My initial choice of RandomX was to avoid the immediate network centralization from ASICs that would kill a community launch on Day 1. If we used SHA-256, established ASIC farms would instantly dominate the hashrate, giving no chance for the community or developers to participate.
However, your point about the long-term security budget collapsing is a major concern that I have been weighing. A pure fixed-cap supply is simple, but as you said, it can lead to cheap reorgs in the future. A
tail emission is a proven solution for this, ensuring a permanent security budget. This seems like a necessary trade-off for long-term network health and it's a topic the core team must seriously consider.
On PQC Implementation:100% agree. A hybrid approach is the only responsible way to introduce new cryptography. It provides a necessary fallback and allows the ecosystem to adapt. And you're right, publishing hard data on signature size, verification costs, and fee impact from a public testnet is a non-negotiable prerequisite to any mainnet launch.
On the Launch Process & Developer Incentives:It completely invalidates my "bootstrap" idea. Thank you for setting the standard straight, this is the process we must follow.
This raises the fundamental question that every fair-launch project faces: how do we incentivize the core developers who will spend months of unpaid time building this?
If a headstart is a premine, and a premine is unacceptable, we need a transparent and fair mechanism. Here are some potential ideas, and I'm open to better ones:
- A small, hard-coded treasury fund: Something in the range of 0.5-1% of the total supply, vested over a long period (e.g., 2-4 years). This would be transparent in the coinbase and provide a budget for sustained development, audits, and listings, not a one-time payout.
- A public donation address: A simple, voluntary way for the community to support the project post-launch.
I am completely open to more suggestions. How have other successful fair-launch projects solved this incentive problem without compromising on fairness? Your insight here would be invaluable.
