Why not..?

[nkocevar]

How about that title for an attention getting advice? Anyways, I have an important (to me) question...


Why not create an altcoin that has a reward based on an order of magnitude of hashing power of each miner such that reward(R) is equal to log base 10 of hashing power? For example:

1 MH/s = (log(1)=R); R=0 coins
2 MH/s = (log(2)=R); R=approx. 0.30103 coins
5 MH/s = (log(5)=R);R=approx. 0.69897 coins
10 MH/s = (log(10)=R); R=1 coin
1337 MH/s = (log(1337)=R);R=3.12613 coins
10 GH/s = (log(10000)=R);R=4 coins
10 TH/s = (log(10000000)=R);R=7 coins

This would create a vast wealth-gap reduction, so that 1% of addresses do not own 70% of coins. In doing so, there would be a great decrease in market-dumping and would be asic-proof in the code itself. If a miner with 10 TH/s mined 1 block with a reward of 7 coins, another miner could make the same profit with 10 MH/s of hashing power in 7 blocks. That discourages huge for-fiat-profit mining operations and encourages everyone to mine to make their coin, further supporting the network itself because everyone can generate coins even with an old CPU (every H/s counts!)


Thoughts, Concerns, "Fuck you, you socialist bastard"(s), etc.

[Q7]

Although there is nothing wrong with your idea which i think is great that it allows everyone to participate in mining but  I remember there was an altcoin created before operating on the same concept but failed. Wish I could remember the name of the coin though

[Fernandez]

This is easy to get around. I will simply run multiple miners. Anybody sane will break it up and run multiples.

[nkocevar]

This is easy to get around. I will simply run multiple miners. Anybody sane will break it up and run multiples.

How could one fix this? Limited wallets? Limited "mining spots"? Miner verification? There has to be something not too intrusive

[nkocevar]

This is easy to get around. I will simply run multiple miners. Anybody sane will break it up and run multiples.

WAIT A MINUTE! Then everyone could do that... More coins generated, difficulty increases as its common knowledge to run multiple instances... eventually it will reach equilibrium again?


**EDIT: Nevermind... argument flawed again... damnit. People with more fiat resources can purchase a way to run more instances than an average joe.**

[Bit_Happy]

This is about "an altcoin", so shouldn't it be in the other section of the forum?
Edit: Good ideas in the OP...

[nkocevar]

This is about "an altcoin", so shouldn't it be in the other section of the forum?

Altcoin can be used to describe BITCOIN forks maybe this can be sensibly revised and applied to bitcoin itself in some way but still maintain bitcoin as its name... just like switching POW to POS or POS to POW

[nkocevar]

Im going to edit OP to ask mod to switch to proper section of the forum... but for now I'd like some input if anyone is willing.  I'm either beginning a manic episode or I am actually onto something (or both xD).

[DannyHamilton]

By basing a fixed reward on a proof of work Bitcoin prevents a Sybil attack. You have to think about how your protocol will overcome a Sybil attack in order to make it work. I don't see a decentralized way to know exactly how much hash power someone is providing.

You need a centralized entity to determine and enforce rules about splitting hash power.

[NeuroticFish]

If the hashing power would be on a more used algo (scrypt, x11, x13), then a pool that handles the power will do. Basically the pool (multipool) could use some power for coin1, some power for coin2, ... getting more income without rising the diff too much.

So what you need is a smarter multipool program, not really a new coin.

[nkocevar]

By basing a fixed reward on a proof of work Bitcoin prevents a Sybil attack. You have to think about how your protocol will overcome a Sybil attack in order to make it work. I don't see a decentralized way to know exactly how much hash power someone is providing.

You need a centralized entity to determine and enforce rules about splitting hash power.

The "Rules" of bitcoin are determined and enforced via code. With proper code-modification, these new "rules" would be implemented in every computer mining or running wallet software, therefore making it decentralized. Correct?

*EDIT: Plus, those rules could be variable just as difficulty is. Instead of a target block time, you have a target reward (per "user")? Maybe?*

[DannyHamilton]

But bitcoin doesn't reward you for something that isn't verifiable (hash power available to you) it rewards you for completing a difficult proof of work. A single reward for a single proof no matter how much or how little hash power you actually have. The proof of work can be (and is) verified by every mode in the network.

Can you think of a verifiable way for everyone to determine exactly how much hash power I have available to me without knowing anything about me?

[DannyHamilton]

You have to think in terms of a Sybil stack and determine exactly how you are going to verify whatever you plan to enforce. Then figure out if there is any way for individuals to "spoof" whatever criteria you choose.

[CrackedLogic]

You can move it yourself. Look at the bottom left corner. Then click move topic.

[nkocevar]

You can move it yourself. Look at the bottom left corner. Then click move topic.

You learn something new every day

[CrackedLogic]

You can move it yourself. Look at the bottom left corner. Then click move topic.

You learn something new every day

  you're welcome.

[nkocevar]

How about this scenario:

Say you have 10 "users" (but lets say instances) mining with the following IPs
1-65.25.42.63
2-126.154.98.22
3-65.25.42.64
4-25.68.36.45
5-65.25.42.65
6-87.22.55.89
7-65.25.42.66
8-45.22.36.59
9-65.25.42.67
10-65.25.42.68

We dont *know*, except for in this scenario, that "users" 1,3,5,7,9, and 10 are the same person trying to commit an attack.

What if every block randomly generates a random number set each new block that corresponds to "instance ID's" assigned to every mining instance such that 49% of instance ID's are randomly picked to ACCEPT work from, and 2% of ID's are maintained from the previous 10 blocks to accept work from...

is there some variant of that in which you can exponentially decrease the odds of 51% of the network being under control by the same group? or is it impossible?

[MaxDZ8]

You cannot work in IPs.
IPv6 maybe. Maybe. But as for IPv4, I know a major ISP around here which puts all its users out of a single IP.

[nkocevar]

You cannot work in IPs.
IPv6 maybe. Maybe. But as for IPv4, I know a major ISP around here which puts all its users out of a single IP.

I was just using it as an example. Basically all the network would see would be multiple "instance ID"s submitting work, be it from the same person or multiple people, no IPs are used in the selection process

[DannyHamilton]

How about this scenario:

Say you have 10 "users" (but lets say instances) mining with the following IPs
1-65.25.42.63
2-126.154.98.22
3-65.25.42.64
4-25.68.36.45
5-65.25.42.65
6-87.22.55.89
7-65.25.42.66
8-45.22.36.59
9-65.25.42.67
10-65.25.42.68

We dont *know*, except for in this scenario, that "users" 1,3,5,7,9, and 10 are the same person trying to commit an attack.

What if every block randomly generates a random number set each new block that corresponds to "instance ID's" assigned to every mining instance such that 49% of instance ID's are randomly picked to ACCEPT work from, and 2% of ID's are maintained from the previous 10 blocks to accept work from...

is there some variant of that in which you can exponentially decrease the odds of 51% of the network being under control by the same group? or is it impossible?

A few questions:

1) How do you get every node on the entire network to choose the same random number (so that they all choose the same 49% to "accept work from"?

2) How do you keep the nodes that will be ignored for the next block from knowing that they will be ignored (so that they don't just turn off all their equipment until the block is solved and the next "random number" is chosen?

3) If nodes 1, 2, 3, 4, and 7 all broadcast the exact same block within a fraction of a second of each other, how do nodes 6 and 8 know which node "solved" the block?