Bitcoin Forum
October 21, 2017, 09:31:56 PM
 News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 Home Help Search Donate Login Register
 Pages: [1]
 Author Topic: Anti-Pool-Hopping Concept  (Read 862 times)
Trangoul
Newbie

Offline

Activity: 1

 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%]
1508621516
Hero Member

Offline

Posts: 1508621516

Ignore
 1508621516

1508621516
 Report to moderator
1508621516
Hero Member

Offline

Posts: 1508621516

Ignore
 1508621516

1508621516
 Report to moderator
1508621516
Hero Member

Offline

Posts: 1508621516

Ignore
 1508621516

1508621516
 Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
NothinG
Hero Member

Offline

Activity: 560

 June 14, 2011, 12:32:36 AM

Let's see this in action!
I would surly be a part of this.

linenoise
Full Member

Offline

Activity: 237

 June 14, 2011, 04:16:14 AM

This is what eligius US has started phasing in. It doesn't let lucky pool hoppers get a disproportionate share compared to the steady users.

WorldTurtleCoin.com ICO is happening now. Modernize the MUD
 Pages: [1]
 « previous topic next topic »