Dealing with (temporary) losses due to mining - dealing with it programatically

[314159265359879]

There was a discussion in Discord about this asteria mentioned we might vote when to stop mining when the yield drops due to fluctuations in market valuation of BTC or STX or both.

I do not think we can use an onchain voting procedure for this, that may take to long. I think we should decide beforehand what we deem unprofitable. The way stxmining.club calculates this is just one way. The bullish miner that kept bidding 800,000 sats per block clearly had an other idea compared to the miners bidding ~400k sats (on May 19th it was the first time he changed since a long time).

Some questions to consider: i.e. do we use a 30 day moving average to valuate stx? instead of the current average? Do you use the value of BTC when it was committed or day to day avg trading price? In Discord I found agreement that we do not want to consider conversion to dollars at all, seems like a good idea to only consider the BTC <-> STX trading pair.

When members commit BTC to the miner address they could give a range for their stx valuation in sats (i.e. 2500 sats per 1 stx or 3000 - 2500 sats per stx). This could be repeated/adjusted by members every cycle (2 weeks). That way temporary changes in the market have little influence? And the miner can use that data to make his bids based on that info.

The miner would need to programmatically adjust its bids based on what other miners do. Temporary bidding more to keep going vs stopping and restarting may also be reasonable for hours in the day and within reason ofc (some max bid). Atleast it was Daemon's experience that miners who were online continuously were most profitable because the odds become more favorable (with good ratio between own bid/total bid per block ofc. )

There is also a system in place to discourage short term miners. I am not sure if that is only done by the time between winning a bid and getting the reward or there is more to it.

How I think we should build this now based on the trading pair.

• Use some oracle for STX/BTC pair valuation: lets say 30 day moving average for 1 stx is 3000 sats. (MarketValuationSTX)
• Lets assume we require some minimum of profitmargin: lets say 5%. (MinimumProfitMargin)
• Total bid should not exceed 3000 - 5% of 3000 = 2850 sats per stx or 2850000 sats per block
• We set a certain minimum percentage of blocks we want to win: i.e. 10% of all blocks (BlockWinRate)
  --> influenced by (how many miners there are? and) how much BTC the pool has for two weeks, lets assume we want to continuously mine that is best for the network and best for our odds on winning 10% of blocks consistantly. We bid more and win more blocks if we have more BTC. We always work in mining per (2 week) cycle (that is also needed to earmark profits and sypool tokens). People can start committing BTC to mine in a specific cycle.
• In that case we bid a maximum of 10% of 2850000 per block
• MarketValuationSTX and MinerValuationSTX (=total commits by other miners per stx in a coinbase) together determine the actual bid, when we make our first bids we will also have to see how the other miners adjust their bids. i.e. if current bids total 2,850,000 per block and we add 285,000 the total will exceed the MarketValuationSTX and our effective BlockWinRate is <10% (285/(2850+285)) yet we expect other miners to adjust in time how many blocks that is to be determined.

And then we can think about scenarios where a new miner starts bidding or one leaves and our effective BlockWinRate goes down or up. We may accept that for x amount of blocks and then make adjustments accordingly.

Asteria in the call just now someone asked how long untill someone can claim rewards. Would this need to be a fixed amount so we know what Sypool tokens are for what profit margin? Or is this arranged outside of smart contracts.
It would make sense to have Sypool tokens for a specific cycle. You commit for mining in cycle 10 and you receive sypool tokens earmarked cycle 10. Sats will be spend in cycle 10 (as per the above bids are adjusted to spend all committed sats for that cycle so the miner can be active continuously). And then someone can claim rewards for cycle 10 by sending Sypool cycle 10 tokens to the contract and claim stx rewards with whatever effective profit margin.

[friedger]

In that case we bid a maximum of 10% of 2850000 per block

The 10% here is not the BlockWinRate, correct?

There is also a system in place to discourage short term miners.

There is the sliding window calculations that take the median of the last 6 blocks to calculate your winning probability.

BTC tx fees are also relevant to determine loss/profit.

I like the 2 week cycle approach.

[314159265359879]

In that case we bid a maximum of 10% of 2850000 per block

The 10% here is not the BlockWinRate, correct?

How so? I was thinking this is the same 10%. I do think that "TargetBlockWinRate" is a better name for it. And as you said we should take into account the bitcoin transaction fee in our calculation.

Which would make it: 10% of (2850000 minus avg BTC transaction fee * number of miners)? (MaximumSustainedBid)

There is also a system in place to discourage short term miners.

There is the sliding window calculations that take the median of the last 6 blocks to calculate your winning probability.

Thanks for the clarification that is excellent, a good reason to aim for consistent mining so that when we do shutdown those first 6 blocks/1 hour after a reboot will not hurt our profit margin in the long run.

BTC tx fees are also relevant to determine loss/profit.

Good point we could use a average for BTC transaction fee (a week?) to adjust the (MaximumSustainedBid)

I like the 2 week cycle approach.

👍