 |
June 14, 2011, 12:27:44 AM |
|
The would require more server involvement in payout, meaning it would need to take the payout (50 BTC) itself then distribute it to the miners. I also have some more advanced ways to tweak it so it is less penalizing on hopping, but if you're trying to stop hopping, this seemily would work well.
Lets say we have 5 miners, working on a block that has 1,050,000 shares and took 1 hour to solve.
A - Finds 500,000 shares, and has 100% uptime.
B - Finds 250,000 shares, but was hopping and was only connected to the server for 30 minutes.
B - Finds 150,000 shares, but was hopping and was only connected to the server for 20 minutes.
D - Finds 100,000 shares, but was hopping and was only connected to the server for 10 minutes.
E - Finds 50,000 shares, and has 100% uptime.
The basic idea is that there are 2 rounds of BTC calculations before distribution.
The first calculation is a standard share % but then multiplied by the uptime %, with the BTC 'lost' going into a pool.
The second takes the leftover pool and re-allocates it based directly on share %.
The breakdown would be as follows for the scenario above:
A - His share ratio is ~47.6% so he would 'recieve' 23.809523 BTC. Since his uptime was 100% he would be credited 23.809523 BTC.
B - His share ratio is ~23.8% so he would 'recieve' 11.904761 BTC. Since his uptime was 50% he would be credited for 5.952380 BTC with 5.952380 going into a pool for the second round.
C - His share ratio is ~14.3% so he would 'recieve' 7.142857 BTC. Since his uptime was 33.3% he would be credited for 2.380952 BTC with 4.761904 going into a pool for the second round.
D - His share ratio is ~9.5% so he would 'recieve' 4.761904 BTC. Since his uptime was 16.7% he would be credited for .793659 BTC with 3.968253 going into a pool for the second round.
E - His share ratio is ~4.8% so he would 'recieve' 2.380952 BTC. Since his uptime was 100% he would be credited for 2.380952 BTC.
Now, total credited was 35.317463 BTC with 14.682537 in a pool to be distributed. Based on the share ratios (shown above), the miners would recieve the following in addition to thier credited amounts:
A - He would recieve 6.991684 more BTC for his share ratio.
B - He would recieve 3.495842 more BTC for his share ratio.
C - He would recieve 2.097505 more BTC for his share ratio.
D - He would recieve 1.398336 more BTC for his share ratio.
E - He would recieve .699268 more BTC for his share ratio.
Bringing the total BTC earned (actually send out to the miners):
A - 30.801207 instead of 23.809523 (100% uptime) [An increase of ~29%]
B - 9.448222 instead of 11.904761 (50% uptime) [A decrease of ~21%]
C - 4.478457 instead of 7.142857 (33.3% uptime) [A decrease of ~37%]
D - 2.191995 instead of 4.761904 (20% uptime) [A decrease of ~54%]
E - 3.080220 instead of 2.380952 (100% uptime) [An increase of ~29%]
|
