STX Mining Pool Infrastructure

[homiebtc]

This pull request adds the infrastructure for pooled stx mining for the mining bot.

At a high level:

This pooling infrastructure assumes the following:

• This is a custodial pooled stx mining service - people can join your pool by sending you btc, and you send them stacks at the end of every PoX cycle, where the number of stacks is weighted based on how much btc they sent vs the amount of btc in your pool
• All inputs to your specified pooling address will be new contributors.
• All outputs to your specified pooling address will be btc spent on mining.

Formulation

For cycle :

• Let be the total BTC contributed to the pool during cycle .

• Let be the total BTC in the pool at the end of cycle .

• Let , or the amount of BTC left in the pool after mining during cycle and not including the newest contributions in cycle .

• If you contributed BTC during cycle , your reward percentage for cycle will be . In other words, your reward percentage is based on how much you contributed in last cycle compared to all the BTC in the pool.

• If you contributed BTC during cycle where , your reward percentage for cycle will be . In other words, your reward percentage is based on your reward percentage from the last cycle and the amount of btc left in the pool after mining, not including new contributors.

• If you contribute during multiple cycles, your total reward percentage is the sum of your reward percentages per contribution.

Example:

Pool begins mining in cycle 10. Any BTC sent to the specified address during cycle 9 is counted as a contribution.

Before Cycle 10

For example:

• 
• You contribute 0.1 BTC ()
• Other people contribute 0.9 BTC total.
• Pool has a total of 1 BTC right before cycle 10 begins ()
• You will earn of all mining rewards in cycle 10.

Cycle 10

• 

• You earn 10% of all mining rewards this cycle.

• This address begins to mine STX.

• This is an example of what would be displayed in the UI

  Before Cycle 11

• 

• For example, let's say by the end of cycle 10, 0.1 BTC has been spent on mining, and another 0.9 BTC was contributed, so pool now has 1.8 BTC before cycle 11. ()

• Your last contribution was during cycle 9 (), so your reward percentage for cycle 11 will be , so you will receive 5% of all rewards in cycle 11

Cycle 11

• 
• You receive 5% of all mining rewards this cycle.
• This address continues mining STX.
• BTC sent to this address during this cycle will count as contributions for cycle 12
• This is an example of what would be displayed in the UI

Before Cycle 12

• 
• For example, let's say by the end of cycle 11, another 0.1 BTC has been spent on mining, and no other BTC was contributed, so pool now has 1.7 BTC before cycle 12 ().
• Since no other BTC was contributed, and your last contribution was during cycle 9 () you still get a total of 5% of all mining rewards in cycle 12 ().

Cycle 12

• 
• You receive 5% of all mining rewards this cycle.
• This address continues mining STX.
• BTC sent to this address during this cycle will count as contributions for cycle 13
• This is an example of what would be displayed in the UI

Before Cycle 13

• 
• You contribute another 0.4 BTC to the pool
• For example, let's say by the end of cycle 12, another 0.1 BTC has been spent on mining, so there is now 2 BTC before cycle 13 ().
• Your contribution during cycle 12 gives you a cycle 13 reward percentage of
• Your contribution during cycle 9 gives you a cycle 13 reward percentage of
• Your total reward percentage will be 0.04 + 0.2 = 0.24 of all mining rewards in cycle 13.
• This is an example of what would be displayed in the UI

To test this for yourself, I have added two files: tests/testPoolBalances.json and tests/testPoolContributors.json. In these two files, change the first address key to one of the bitcoin addresses you have imported into the mining bot. Then add "poolContributors" as a key to your local storage with the value from tests/testPoolContributors.json, and add "poolBalances" as a key to your local storage with the value from tests/testPoolBalances.json. These values would be normally automatically generated through API calls, but you can manually change them for the sake of testing. Your local storage will look something like this .

User flow

• On the manage pool page, users can turn on pooling

• Users can then specify the BTC address they are mining with and that they intend to pool with. The list of possible addresses is taken from the addresses they added in the wallets page. They can also specify which cycle the pool starts in. In the example above, this was the cycle that the pool began mining in.

• Whenever the user queries on the table, we make api calls to Blockcypher to query the bitcoin blockchain for your pooled address. Any inputs are considered a contribution to the pool and we save the incoming address and contribution amount. Any outputs are considered btc spent on mining.

• After a cycle ends, you have the reward percentages for each address, so you would compute how many stacks you mined during that cycle, multiply this by the reward percentages for each address to determine how much stacks each address deserves, and then you could send this using the stacks wallet. Automatic payment has not yet been implemented.

• We also have not implemented a way to take fees in return for this pooled mining service.

Thank you for reading and please let me know of any changes I should make; I am open to any and all feedback!

[gzelda]

Here are two obvious issues which will occur in Mining-Pool:

• Operator ( the owner who has the actual mining-pool miner's private key ) evil problem
  • operator can receive the BTC but doesn't burn any BTC in stacks mining
  • operator can receive the BTC but doesn't burn enough BTC in stacks mining

• Burn-fee related problem

  • Sometimes there will be a better burn-fee range by stx/btc price and total-sats per block. But users in one cycle cannot decide anything. Here are two examples:
    • The new cycle has only one user join in, the burn fee is tiny
    • The new cycle has over 20 users joining in, the burn fee is over the profitable range.

  Because the burn-fee setting is a strategy game, a normal miner can choose to keep going or quitting, but for mining-pool, the user has no privilege to do anything but only seeing the mining process going to the next cycle.

@danosaur98 Here are several suggestions for setting up the mining pool:

1. The operator should stake something to be trustless
2. The operator will have a default burning range like 200,000 sats to 700,000 sats. Not too tiny, not too big. The number depends on the current environment and users' commit value.
3. Setting the depositing cycle not too big, one Pox Cycle is too long for a normal user. 30～50 blocks is good I think.

[gzelda]

Thanks a lot for the contribution to Mining-Bot. It's awesome! Welcome to discuss more detailed information before the PR merge. @danosaur98

[SherLzp]

I think this solution is not flexible enough, and all decisions are in the hands of Operator. According to the current profit distribution formulation, users cannot decide whether I will participate in a certain round of mining.