[Idea] New Altcoin with built-in Max Hash power limiter?

[JohnDorien]

Is it possible to integrate a limiter for max hashing power?
Would be something like if hashp>2000kh/s then stop thread??

I would like to build a fork of lite/feather/chn/whatevermoreisthesame-coin with following changes:

- Reward 100 coins per block
- Diff incrementation very slow --> even "late adopters" will have a chance for coins doing solo mining
- Medium start diff --> For not having the first 10k blocks at 10 early adopter's wallets
- Maximum hash power limitation --> Even chances for everyone!
- Announced 5 days before launch!


Somebody with programming skills interested in joining this coin? I myself would need 10 weeks to implement the mentioned above as i am not that good in programming...

Please post your thoughts on this

[monocolor]

interesting... how do you know the hash power out there?

maybe a better way is to "hold" any block for a given amount of time, after it is solved. No payout immediately.

[JohnDorien]

interesting... how do you know the hash power out there?

maybe a better way is to "hold" any block for a given amount of time, after it is solved. No payout immediately.

we have the hash power calculation function in the miner thread. The limiter has to be based on that calculations. Problem may only be that this is only locally and maybe someone could just edit the source to get around that limitation as it is not controlled by the network.

That gets me to the thought, if it may be possible to have a "block solved at hashpower" value integrated to the solved block submit so the network can reject every mined block with a value higher than the limit?

[Luckybit]

interesting... how do you know the hash power out there?

maybe a better way is to "hold" any block for a given amount of time, after it is solved. No payout immediately.

What about random interval schedules? If the miners don't know exactly how many coins they'll get or when, they'll mine forever and it will be random just who gets how much of what. This would create a maximization of mining resources while discouraging the ASICs.

Think of it like an RPG where if you use the best weapon in the game (ASICS) it might not work on every monster which spawns. Since you wont know which monster will spawn, you wont want to use just any weapon but have them all. And since you don't know when that rare monster will spawn, you'll have to hunt in that area for as long as it takes until it spawns. Think of Dragonquest with the metal slime. Think of Final Fantasy with cactrot.

[xorxor]

Fine idea, but an utopian concept. One word:

botnet

[Impaler]

You cant put that in the miner, people just edit it out, recompile, put the miner on the network and win blocks.  It would be no different from putting a "please don't mine this with an ASIC" popup message in the client, pointless and guaranteed to be ignored instantly.

Only what is in the protocol that the rest of the network sees can be enforced.

[monocolor]

we have the hash power calculation function in the miner thread. The limiter has to be based on that calculations. Problem may only be that this is only locally and maybe someone could just edit the source to get around that limitation as it is not controlled by the network.

That gets me to the thought, if it may be possible to have a "block solved at hashpower" value integrated to the solved block submit so the network can reject every mined block with a value higher than the limit?

Yes it is local. Even we put it in the submit parameters, people can still cheat and put the fake value. I think the block can be stamped the first time someone take it, and unless certain time elapsed, we will not payout the block. And "available" block generation has to be strictly, say, every 2 mins.

[JohnDorien]

interesting... how do you know the hash power out there?

maybe a better way is to "hold" any block for a given amount of time, after it is solved. No payout immediately.

What about random interval schedules? If the miners don't know exactly how many coins they'll get or when, they'll mine forever and it will be random just who gets how much of what. This would create a maximization of mining resources while discouraging the ASICs.

Think of it like an RPG where if you use the best weapon in the game (ASICS) it might not work on every monster which spawns. Since you wont know which monster will spawn, you wont want to use just any weapon but have them all. And since you don't know when that rare monster will spawn, you'll have to hunt in that area for as long as it takes until it spawns. Think of Dragonquest with the metal slime. Think of Final Fantasy with cactrot.

Sounds like the wish to have scrypt+sha mixed mining neccessary to solve a block?

Fine idea, but an utopian concept. One word:

botnet

that is already a "problem" which we can never cut out

we have the hash power calculation function in the miner thread. The limiter has to be based on that calculations. Problem may only be that this is only locally and maybe someone could just edit the source to get around that limitation as it is not controlled by the network.

That gets me to the thought, if it may be possible to have a "block solved at hashpower" value integrated to the solved block submit so the network can reject every mined block with a value higher than the limit?

Yes it is local. Even we put it in the submit parameters, people can still cheat and put the fake value. I think the block can be stamped the first time someone take it, and unless certain time elapsed, we will not payout the block. And "available" block generation has to be strictly, say, every 2 mins.

The 2 mins would need to be locally or within the network? If in the network, isn't this against the fair chance for everyone basic? I mean right after that 2 mins again the ones with highest hash power will have best chances to solve that block..

[JohnDorien]

we have the hash power calculation function in the miner thread. The limiter has to be based on that calculations. Problem may only be that this is only locally and maybe someone could just edit the source to get around that limitation as it is not controlled by the network.

That gets me to the thought, if it may be possible to have a "block solved at hashpower" value integrated to the solved block submit so the network can reject every mined block with a value higher than the limit?

Yes it is local. Even we put it in the submit parameters, people can still cheat and put the fake value. I think the block can be stamped the first time someone take it, and unless certain time elapsed, we will not payout the block. And "available" block generation has to be strictly, say, every 2 mins.

so how make it cheat proof within the protocol?

[digitalindustry]

Think of it like an RPG where if you use the best weapon in the game (ASICS) it might not work on every monster which spawns. Since you wont know which monster will spawn, you wont want to use just any weapon but have them all. And since you don't know when that rare monster will spawn, you'll have to hunt in that area for as long as it takes until it spawns. Think of Dragonquest with the metal slime. Think of Final Fantasy with cactrot.

i'm thinking all that , but don't sadly know what any of them actually are - but - i think i get the jist , and its a good idea!

[JohnDorien]

Think of it like an RPG where if you use the best weapon in the game (ASICS) it might not work on every monster which spawns. Since you wont know which monster will spawn, you wont want to use just any weapon but have them all. And since you don't know when that rare monster will spawn, you'll have to hunt in that area for as long as it takes until it spawns. Think of Dragonquest with the metal slime. Think of Final Fantasy with cactrot.

i'm thinking all that , but don't sadly know what any of them actually are - but - i think i get the jist , and its a good idea!

Indeed a good idea, i think this could be implemented by havin the neccessarity to have 50% scrypt solved and 50% sha.
doing that would then result one needs 2 GPu / CPU to mine that coin properly?

[CvRChameleon]

Is it possible to integrate a limiter for max hashing power?
Would be something like if hashp>2000kh/s then stop thread??

I would like to build a fork of lite/feather/chn/whatevermoreisthesame-coin with following changes:

- Reward 100 coins per block
- Diff incrementation very slow --> even "late adopters" will have a chance for coins doing solo mining
- Medium start diff --> For not having the first 10k blocks at 10 early adopter's wallets
- Maximum hash power limitation --> Even chances for everyone!
- Announced 5 days before launch!


Somebody with programming skills interested in joining this coin? I myself would need 10 weeks to implement the mentioned above as i am not that good in programming...

Please post your thoughts on this

Strangely enough I had a dream last night about exactly the same idea, was just a dream, but my limit was ~300kh/s; for even lower GPUs.  It was meant for slower GPUs to mine something, preventing power hashing of people taking over majority of coins, but after reading the replies from people that really know whats going on that it could be hard to implement (people just editing source and recompiling)...

Anyway laugh at me more : what about making it non-soloable() {insert a non-created-non-possible-function-that doesnt make it possible to 127.0.0.1?} , creating ~10 (example) mining pools at launch (which should ideally never be offline / dissappear), each distributing the same amount of hashing power total, and having a centralized mining pool registration page; which then assigns your mining worker to one of those pools.  Limit of one worker per account; preventing one mining pool having much more hashing power over others; if you want another worker, create new account which can technically be assigned to a new pool.  If a user gets detected with higher hashing speeds, het gets banned asap.

The point that the original user (maybe) tried to make (or what Im saying now) is that everyone that mines gets enough / SAME amount of coins of other miners.  

Problem is with my ~300kh/s it will be only ancients (like me) mining this... good or bad?  Would be cool if ASICS / faster GPUs had no impact in collecting most in pool.

Anyway looking forward to your rants.  

[Extornia]

Why not just increase difficulty if hash goes too high, compared to current diff? And then let it go back when hash is low again? That'd be fair. Kinda like terra.

[JohnDorien]

Is it possible to integrate a limiter for max hashing power?
Would be something like if hashp>2000kh/s then stop thread??

I would like to build a fork of lite/feather/chn/whatevermoreisthesame-coin with following changes:

- Reward 100 coins per block
- Diff incrementation very slow --> even "late adopters" will have a chance for coins doing solo mining
- Medium start diff --> For not having the first 10k blocks at 10 early adopter's wallets
- Maximum hash power limitation --> Even chances for everyone!
- Announced 5 days before launch!


Somebody with programming skills interested in joining this coin? I myself would need 10 weeks to implement the mentioned above as i am not that good in programming...

Please post your thoughts on this

Strangely enough I had a dream last night about exactly the same idea, was just a dream, but my limit was ~300kh/s; for even lower GPUs.  It was meant for slower GPUs to mine something, preventing power hashing of people taking over majority of coins, but after reading the replies from people that really know whats going on that it could be hard to implement (people just editing source and recompiling)...

Anyway laugh at me more : what about making it non-soloable() {insert a non-created-non-possible-function-that doesnt make it possible to 127.0.0.1?} , creating ~10 (example) mining pools at launch (which should ideally never be offline / dissappear), each distributing the same amount of hashing power total, and having a centralized mining pool registration page; which then assigns your mining worker to one of those pools.  Limit of one worker per account; preventing one mining pool having much more hashing power over others; if you want another worker, create new account which can technically be assigned to a new pool.  If a user gets detected with higher hashing speeds, het gets banned asap.

The point that the original user (maybe) tried to make (or what Im saying now) is that everyone that mines gets enough / SAME amount of coins of other miners. 

Problem is with my ~300kh/s it will be only ancients (like me) mining this... good or bad?  Would be cool if ASICS / faster GPUs had no impact in collecting most in pool.

Anyway looking forward to your rants. 

I like the thought in this, but i'm afraid this sort of implementation would lead to a strong centralization of the coin, which is against all crypto coin ideas.
Basically the 2000kh/s limit would still give you good chances @300kh/s

Why not just increase difficulty if hash goes too high, compared to current diff? And then let it go back when hash is low again? That'd be fair. Kinda like terra.

This would not prevent any big players having all the coins. If the diff is raising to high the chances for "small players" get even worse.

[BBQKorv]

So instead of building rigs with as high hashrate as possible, people would build multiple rigs with just 2MHs. What does that solve?

[markm]

There is no need to conflate minting with securing the network.

Miners can get paid by transaction fees.

Coins can be distributed by other methods entirely. There is no need to have miners mint them.

-MarkM-

[JohnDorien]

So instead of building rigs with as high hashrate as possible, people would build multiple rigs with just 2MHs. What does that solve?

That's still a number of miners with max 2mh/s each, even if they belong to one person. Still same chances for every miner.

There is no need to conflate minting with securing the network.

Miners can get paid by transaction fees.

Coins can be distributed by other methods entirely. There is no need to have miners mint them.

-MarkM-

How does this contribute to this coin idea? Sounds like a whole new sort of setup to me.

Still open question, is there any programmer out there to support this coin especially the point of implementing the max hash into the network (-protocol)?

[markm]

You want the max hash possible, to secure the coin.

So do not limit hash. Just do not mint coins that way.

Let the transaction fees pay the miners, and use any other means whatsoever to distribute coins.

Any means at all.

For example you could sell GPUs, FPGAs, ASICs, whatever, in general, mining gear; and give free coins with any mining gear purchased. The people thus have gear, and have an incentive to mine with it (they need mining done so as to secure their wealth, the coins are worthless unless there is enough mining happening to secure the chain.)

-MarkM-

[JohnDorien]

You want the max hash possible, to secure the coin.

So do not limit hash. Just do not mint coins that way.

Let the transaction fees pay the miners, and use any other means whatsoever to distribute coins.

-MarkM-

This is indeed a good idea, but not for this coin as this is supposed to be spread amongst all miners even those with small hashing power, i think the total hash power will be good due to good support.

I myself have 600kh/s for scrypt and do not point it to any pool or something because it is just not worth it due to the minimum i get out of it. Would bet i am not alone thinking this way amongst all the users not having mining rigs worth 10k's of dollars.

So what would small miners prefer, having real changes on coins or mining ages to get a small amount of any coin...

[markm]

Small miners can mine low difficulty chains, that is how small miners are making fortunes from BBQcoin.

For many many many months you didn't even need a GPU to mine BBQcoins, it was mined by CPU miners.

Several other chains are still like that.

There are also some chains that are getting a little hard for CPUs compared to those easiest chains, but anyone with even just one GPU can rake in coins all day long.

BBQcoin of course already completed that part, enough CPU miners got enough BBQcoin that it became worthwhile to remind GPU miners of its continued existence, getting them to return to mining it, and, soon, to get it on exchanges.

So if you only have a low amount of mining power you should be mining one or more low difficulty coins that have not yet been jumped back on like BBQcoin by GPU miners. Rake in coins month after month, afterall it is not like a small miner has any significant electrical bill nor capital cost for rigs, it is dirt cheap to mine such coins.

Then when you feel you have enough of them, start reminding the GPU miners that those chains still exist.

Then just like happened with BBQcoin, one day they will jump on the chain, driving its difficulty out of reach of small miners but making the coin "popular", some small exchange that needs something no other coin has as a way to attract users picks it up, and presto your months and months of picking up coins basically for free pays off massively.

Meanwhile, since the GPUs moved to the newly re-popularised chain you had been picking up free before moved from somewhere else, wherever they moved from starts dropping in difficulty, people start saying it is dead, eventually its difficulty gets really low, and it takes its turn as one of the "under the radar" coins that small miners can pick up in large quantities virtually free.

Looks like it might be a renewable-resource cycle!

-MarkM-