Could somebody please explain why the limits for the byte length have always been set way lower than what the little-endian encoding would allow?

E.g. length 1 would allow for 255, length 2 up to 65535. Instead 128 resp. 16512 was defined as upper limit.

https://github.com/vthoang/cgminer/blob/master/util.c#L1035

Code:

/*  For encoding nHeight into coinbase, return how many bytes were used */
int ser_number(unsigned char *s, int32_t val)
{
        int32_t *i32 = (int32_t *)&s[1];
        int len;

        if (val < 128)
                len = 1;
        else if (val < 16512)
                len = 2;
        else if (val < 2113664)
                len = 3;
        else
                len = 4;
        *i32 = htole32(val);
        s[0] = len++;
        return len;
}

Edit: Comparing with kano's repo, the limit is set to half max there, which makes more sense from a consistency perspective.

Hi there,

I have read alot already about taproot activation, but out of all the publicy available information I still didn't get if there is any relevant change introduced by the taproot soft fork that affects mining software. In particular, I'd like to understand if cgminer would need an amendment now (or in the near future) to still be able to generate valid (i.e. accepted) blocks.

As a first verification step, I have solo-mined on testnet with cgminer 4.11.1 (which is three years old) on a Bitcoin core 22.0 node and was generating valid and confirmed blocks just fine.  EDIT: Even without signalling taproot support in the version bit of the block header.

Which was unexpected, so I assumed that legacy and segwit transactions will still be mined successfully (as long as there are any in the mempool). Which again could be fully wrong...

Is the taproot support signalling in the block header the least thing that needs to be done to produce valid blocks on mainnet?  

Can somebody please advise?

[UPDATE]

Probably an academic bf question, but since I now started to scratch my head about this I would like to come to a conclusion:

If I understood correctly, the extranonce is provided by bitcoind via stratum. So it does not matter whether using a solo pool (with direct stratum connection) or mining directly on one's own bitcoind. If that's the case, that would imply that there is a 1:1 relationship between btc address and the extranonce value(s).

I browsed through the ckpool code and looked at the difference between clients and workers, with the latter being the stratum instance (irrespective of the count of workers, as being bound to the same btc address)

So the actual question with solo mining now is, if I start multiple cgminer instances mining with the same btc address, will they do the same work redundantly? Does it make a difference - or not -, if each instance uses a seperate worker (which still relates to the same btc address)?

The conclusion would be to use a seperate btc address per cgminer instance, or better, combine all ASICs in a single cgminer instance.

For general pool mining, this is not relevant ig, but for solo mining this might well be relevant.

In the end, I may ofc be utterly wrong here

Let me know your thoughts.

UPDATE: Forget the above. Digging further, I learnt that each miner instance generates its own copy of the coinbase transaction (to include the applied extranonce) when starting to mine a new block. So the extranonce is not important here, but I take it as outcome:

When solo mining, always use all available hashing power for the very same miner instance with a single btc address!

As a real world example: What has higher probability? Winning in a single lotto drawing when buying 30 tickets - or winning in one of 3 lottery drawings when buying 10 tickets for each?

I will take this as personal guidance unless somebody steps up and proves me that this is pure bs. 

Hi all.

I have photovoltaics at home and think about getting an ASIC miner mainly to mine the power excess away, rather than feeding it into the grid (due to the poor rates).

Suppose, I get a cheap S9/T9 for that purpose, would the hardware be able to deal with that or rather die prematurely due to the ramp up/downs? Not talking about hard power on/offs via e.g. wifi socket, but rather adaptively controlling the hashrate (frequency/voltage) via API (is that possible?) so that I can throttle or max up as appropriate during the day.

If somebody has experience/knowledge in that field please let me know.

EDIT: Found out about cgminer/bmminer API meanwhile in a seperate thread: https://bitcointalk.org/index.php?topic=5241201.0. So the question is whether the bmminer driver in the S9 (latest) firmware supports the ascset command to be able to control freq and voltage via API.