I lack the technical knowledge to propose how this will be accomplished so I am just posting what I would like to see happen. This proposal is meant to start a discussion per the Iron Fish proposal process and receive feedback/and suggestions as to how this can be implemented.
As people are aware, 59.9% of hashrate is currently unknown. This ruins the Iron Fish core developer’s ability to decentralize the network and makes the network insecure because an unknown entity can 50%+ attack the network at any time.
I propose that, at least temporarily, until hashrate is more spread out, all mining nodes that submit blocks require a basic approval from the Iron Fish foundation. The 59.9% does not participate in Iron Fish discussion nor have they contributed anything the way smaller miners have. This way they are either forced to identify themselves and participate or choose another network to leech off of.
Why this is important:
I believe long-term this will benefit Iron Fish’s price as having hashrate spread out between identified entities will make the network more secure for users. In addition, kicking the leech off the network will increase rewards for current miners who participate by 2x. Iron Fish as a network is currently useless while the majority of hashrate belongs to a single unknown entity. This should be considered an attack and should be dealt with as such. Once bridges are released, no major user will bridge millions of dollars of assets over when the network could be 51% attacked at any time. At least this way if an attack happens we can ban/shame the known party and continue forward.
Stakeholders of Iron Fish include the developers, miners, and users. They will all benefit from decentralization. In addition, the developers and miners (note that pools are also referred to as miners, I am not suggesting that miners who mine to a pool identify, only the pools themselves) will benefit from knowing who the miners are and having a contact method. For example if there are bugs these can be reported to the developers and if there are updates/forks the developers can email miners.
This is a well written proposal, but my recommendation would be to keep each proposal as simple as possible. I think the Afterwards section should be left out so that the proposal is just one topic that you want to accomplish. If that gets passed, you can file another proposal with recommending an algorithm change separately.
Apologies, I assumed you wanted something that was Sybil resistant.
Could you explain this a bit more? Are you certain that 60.6% is the same party or a single pool, and not many people who want to remain private? Which attacks, exactly, are you concerned about? And how does KYC (or more charitably, asking for an email) prevent those attacks?
An unknown entity controlling the majority of hashrate scares off users. Would you trust $100k in BTC to a chain with an unknown majority controller?
Identifying them will help some, Iron Fish devs can then ask them to spread out their hashrate some. At the very least this allows the Iron Fish devs to take action in a soft approach as they can now communicate with the party. Right now they can’t do communicate which handicaps them.
To me this proposal will only benefit the network and has no real downsides besides the work involved.
Throw money at them, expensive and impractical long-term given that Iron Fish only has a small % compared to daily issuance over the next few years. Also more IRON may just dump price more.
Making mining easier by an algo change is complicated and yes total # of hashrate would increase but that’s like saying going from ethash to sha-256 increases hashrate, sure the # increases but not the decentralization. There is a set $ emissions a day changing the device that can be achieved on won’t do much and the same problem may repeat. Also every current miner will hate you.
So kill every pool by having the core developers make their own pool? That’s not a good suggestion and people hate that on Flux. Probably they can’t do so legally as well.
My proposal isn’t exactly a solution but it costs little, doesn’t result in more IRON in the ecosystem, and doesn’t impact existing miners. It gives a way for the Iron Fish developers to talk to the 60% so at least we can know what it is instead of having people daily screaming it’s an ASIC conspiracy and this chain is dead.
I didn’t suggest an algo change, not sure where you got that.
As I said, you can limit the impact by putting a % hashrate limit on the pool. It achieves the exact thing you’re looking for here — no need to jump to extremes and assume it will take the whole pie. It’s also a great way to help distinguish whether these are solo miners.
The team has actually discussed this course of action a while back and decided against it. I think its a logical thought because its so easy to implement but there is one big downside to this proposal in my opinion: it would erode the public trust that the network will remain decentralized. If any one group had the capability to choose which blocks did or did not get accepted onto the network they would also have full censorship ability which is really antithetical to the ethos of crypto.
I’ll expand on a potential implementation to show why we don’t see this as a possibility. One implementation would be to make a consensus change to add a whitelist of miners (public keys) that are allowed to submit blocks. New miners would have to get their public key into the whitelist in order to start mining and the whitelist would most likely be stored in the Github repository with the node. This concept exists and its called a permissioned blockchain. Permissioned chains are out there but mostly in institutional settings for example the Binance Chain. The main drawback is they sacrifice censorship resistance which is a big deal for a chain that aims to be decentralized like Iron Fish.
If IF went to a permissioned chain I think it would be very difficult to restore trust that it would ever go back to being un-permissioned. Even if the whitelist were removed there would always be thought in the back of users’ minds that a whitelist is an option. I also see it as a slippery slope towards less decentralization in general like whitelisting who can submit transactions. So even though it’s a simple change it would be a major line crossed and one that the chain might never be able to return from so we don’t want to cross that line.
Majority unknown hashrate is a threat to decentralization but I don’t think we can solve this with a solution that also erodes decentralization (and in a potentially permanent way). I appreciate your bringing up the proposal though so it can be discussed openly.
My proposal is for this to be temporary as 60%+ of hashrate being unknown is a very rare issue for chains. I think we can maintain this for a 3 month period as we don’t even have bridges yet so it’s not like mass decentralization is needed.
I was hoping for a genius solution to the 60%, if not then I would say my proposal is the best we got and hearing that it’s easy means I support it even more. I’m not proposing strict KYC like for the airdrop, just the basics. And of course, this solution is cheap and simple.
Decentralization implies that stakeholders can vote to do things in a decentralized manner, I would say let’s vote on a temporary permissioned chain to solve the 60% unknown problem and if the vote passes then we’re following decentralized governance.
White list for miners maybe great solution in case it is possible to implement it fast, also the criteria to get key may not include sharing any sensitive information except for hardware details.
For now, miners who choose to mine ironfish goes to mine other coins to sell it and buy $IRON, due to exchange rate. And if not stop unknown hash rate source immediately it will continue, I mean gpu miners will exit from IF mining. By last two weeks unknown hash rate already get 65%, and in two weeks it will be 75%.
Many people also share hate about IF and even who was support the project start thinking that something goes wrong.
As more time unknown will mine and sale, so harder will be get audience back.
Other words, the audience sympathy already losing day by day, and in case to not protect gpu miners now, later you will have to convince miners to come back.
I believe now is time to protect project itself to save it, privacy require protection now, becuse later it could not have demand, or will be very hard to get people back.
Also, for users things now looks dramatically, because they are all under stress, and in discord all team members pretend that everything is fine, active few times a week.
I know that IF will overcome this period, but hope for reaction too.
I would rather support an algo change. I don’t love giving a single entity (in this case IF foundation) the ability to essentially filter/alter blocks. Sounds like a slippery slope and just terrible optics for a decentralized project.