Topic: idea: adaptive block rewards, a design criteria to punish large pools (Read 701 times)

Just have a special miner - pool will pick one of the miners to broadcast (for a small reward in the next round) resulting block from their IP address/geographical location, selected from all miners so the profit will be maximized. Pools can pick from hundred of IP's to overcome whatever hurdle is there in path to maximum profit - a better situation than a single miner, that may be unable to overcome the obstacle (only one IP) that may or may not appear for him.

Better would be to fix the problem (so 51% attacks won't be possible), one sort of an attempt is combined PoW + PoS coin (but this only slightly mitigates the problem, does not remove it), but inventing any nice, universal solution is very very hard and may need complete protocol redesign.

Don't get me wrong, I see the benefit. But for a person (or a group of people) with enough hash power the deliberate manipulation can cause some significant issues. I can see the uber-rich doing some seriously detrimental things for monetary gain. If the pool is large with a lot of small time people, they'll switch pools. But if the pool is made up of a few big time players, they won't care about switching when they can alter the price of their own coins.

This is what concerns me about coins that aren't reconciled with.

I see your point. You are worried that some pool operator with high enough hash power may deliberately and artificially decrease the total rewards of the coin network constantly for a certain period of time. This is technically possible. But the protection is that the high-hash pool operator can do it only at the expense of downgrading his own rewards, which would in turn mean lower shares for the members of the pool. It is eventually inevitable that the pool's members will cash out and run away lowering the pool's hash rate. This renders the centeralizarion-oriented-pool-operator's approach impractical.

My apologies, I apparently skipped part of my train of thought. Say the colluding farm owners bought a bunch of the coins (that's why I say it was mined okay for a few weeks).

Price goes up. They dump. Buy up at the lows. Rinse and repeat. Since they can control the scarcity of the coin this enables them to act as wanton profiteers at their discretion.

What I propose is that: What a pool operator can do is that he can only decrease his next block reward. The protocol does the checks by ip of the client, or by client id or whatever appropriate measure. Only the client with too much hash rate is punished next time it finds a block. The other clients are not affected. I don't think that coin's market value is affected anyhow by some pool trying to centralize. If something, this temporary scarcity in rewards would make the coin more valuable both because of temporaray lesser-coin-number-increments caused by some noobish pool operator and by centralization-proof design.

Sure minting amounts aren't constant, but the effect on monetary supply could be harmful. Consider the following scenario then:

Mining goes normal for let's say a few weeks. Then several people with farms decide to pool their hashing power together and happen to have as much hashpower as the current network and do it in a way so that by your protocol is considered to be a pool. Right there, they have artificially decreased the amount of coins produced by day in half.

Would forcing scarcity be beneficial? And what would happen if they did it for a prolonged amount of time and then stopped for a prolonged amount of time before continuing on again and repeating the cycle? Don't you think the coin's market value would be shellshocked?

well the minting amount is not constant I believe for many altcoins nowadays. example: dogecoin via wikipedia, quoting: "Unlike some other cryptocurrencies, there is no limit to how many Dogecoins can be produced".

Say if you could make it work (it doesn't sound practically feasible). How do you propose to reconcile these truncated coins so the minting amount remains constant?

I believe this kind of a criteria is towards the solution of the problem. The pools may or may not mind stopping themselves from exceeding 50% hash rate. In the current crypto-currency ecosystem, there is no sanction for this kind of an approach of the pool operators. You simply have to trust the operators which is no good. It is vulnerable in many ways. I believe we should aim for ways to limit the hash rates of the pools by design, not by trust. The hash rates announced by the operators may not match their real hash power. They might claim they do not want 50% hash power while pulling for it and preparing a 51% attack. There are dead coins in the market because of a 51% attack and no one can claim bitcoin will not be one of the victims of a double spending attack in the future.

The criteria I propose might not be perfect and might require some higher complexity than the way I present + polishing. However, if applied correctly it may help. Reminder: The purpose is to only make it harder for the pool operators, not impossible. The bitcoin network indeed runs by a similar idea, technically a 51% attack is never impossible, just gets harder and harder as the hash rate increases. We should keep in mind that it is on the other hand more desirable as the value of bitcoin increase and increase. The numbers I give may also be configured such that they dynamically adjust with the ever-changing total network hash rate, if necessary.

a serious sub-problem to overcome: I realize that, while we make the job of the higher-hash-rate-aimed-pool-operator harder, besides that, it will undesirably make the job of new pools harder because first few blocks they find will not be issued. This may be counted as cost of registering a pool to the altcoin that implements this criteria.  Regarding this, it would be helpful if not necessary, if we discover adapting some sort of underlying primitive/mechanism to distinguish the already-registered pools from new ones. We want to restrict new-ip-block-submission to a certain extent that it is hard for existing pools to overcome it, at least they loose some block rewards and loose some member shares (or eventually members) every time they try to work around the block sending punishment from new IP addresses.

The whole implementation of the criteria might discourage solo-mining. But since almost all altcoins nowadays are pool-mined from day1, this would not cause any problem.

Geo-location, IP banning ... right.

Well, otoh, here's an example of a pool that "punishes" miners that flock to them: max.1gh.com
So, all the remaining  Maxcoin pools combined (all MPOS, I believe), where one needs to provide email, user, password, click on terms of service, validate email, setup workers, keep password safe, unlock, bla bla... amount for less than 40%.

Perhaps there's a reason why people end up centralizating in the first place. Instead of "punishing" these or those, how about solving the problem?

how about the protocol does not allow new IP's to find new blocks? Say a certain period of time should pass after the IP registers in the network to be allowed to find a block? It might also be something like the 1st block found by any IP is not counted. Or a combination of these.

I believe that small pools with 1% hashing power would not mind this kind of a reward punishment as their rewards are not affected. They should be keeping track of the ratio of their hash rate vs the total network hashrate though. A protocol supporting decentralization might be an incentive for both people supporting the coin and new pools to pop up.

Ok, sure. So I'll just find a block and then broadcast it from a different IP address. Your system is defeated.

How are pools to blame for miners that flock to them? You want to punish success?

No pool operator will support a coin with such scheme. Your basic idea with some modifications, perhaps, but tbh I don't see them.

hi all,
I dunno if anyone proposed this kind of a criteria but I guess I have an idea having potential to be applied to new crypto-currencies to overcome pool-centralization-problems that bitcoin faced.

the idea in simple words: For too large pools, the mining block rewards will decrease.

a possible implementation of the idea: The protocol (or all clients) keep in mind (or on blockchain) which client(s) accomplished the last n block-findings. If the block is constantly found by a certain client, such as in a higher rate than a predetermined threshold, than the client is still rewarded next time it finds a block but not with the regular way, instead in diminishing values. The higher rates a certain qt-client finds blocks, the higher the decrease in block rewards.

punishment exemplified: Say n is set to be n=100. Average percentage of blocks found by a certain client (if > 1%) is cut from the next block reward. The cut is say 10 times the percentage.
0% - 1% of all the last 100 shares are found by a certain client ===> no punishment
1% - 2% of all the last 100 shares are found by a certain client ===> 10% next-time-decrease in block rewards for that client.
2% - 3% of all the last 100 shares are found by a certain client ===> 20% next-time-decrease in block rewards for that client.
.
.
.
10% - 11% of all the last n=100 shares are found by a certain client ===> 100% decrease or, in other words, no rewards for the client next time.

The rewards are truncated. In the case of bitcoin protocol, instead of 25 bitcoin rewards, a client with 1%-2% average block finding gets not 22.5 but 22 bitcoins next time. A certain possibility to overcome this reward punishing by large pools is to run multiple clients and split the hashing power of the members so that no client runs >=1% of the hashing power. While this partially explains the reason why the punishments should be 10 times or more than the average rates of the last-n-block-finding-percentage, it does not stop pools from running 50 clients and do not really prevent centralization in pooling.

However, I believe an additional enforcement might be employed such as determining the location of the clients based on IP which is quite easy and putting a limit on the number of rewards of a certain geographical location can find in a unit of time. This makes the job of the pool with the purpose of centralization indeed harder and harder decreasing the feasibility of their job forcing them tonot only run many clients on different pool servers, but also distributing pool servers all around the world.

I would like to hear about your opinions, cheers.

Is there a working way to enforce this kind of a criteria on pools maybe applying techniques of cryptography? What do you think guys?