<p>I asked this question on another forum but did not get any responses so I thought I'd try here.</p>
<p>I've been researching bitcoin mining for a while and I have a work-in-progress hypothesis that could potentially speed up the mining process. I am keen to seek some feedback on the viability of this approach.</p>
<p>I've identified a way that allows asynchronous pre-computation of a number of values that can be computed well in advance of knowing the hashPrevBlock. These are billions of pre-computed 32bit values that do not need to be re-calculated when the block height changes; i.e. they can be reused indefinitely. The only caveat being that ASIC miners would now rely on memory to fetch these values instead of having to calculate it for every new hashPrevBlock.</p>
<p>In my opinion, this saves a lot of energy and chip area as the ASIC miner no longer needs to calculate these values. These values can be calculated once in software and then 'fed' to memories that the ASIC miners have access to.</p>
<p>Any feedback on how this approach is flawed or a non-starter? I have read about memory hard PoW algorithms that are ASIC-resistant. Am I making Bitcoin mining ASIC-resistant by such an approach?</p>
<p>Surely there have to be benefits of being able to pre-compute gigabytes of data ahead of time that will simplify/speed up the Bitcoin mining?</p>

CC BY-SA 4.0
2022-11-08T10:57:40.980Z
Does this answer your question? [Is pre-mining of a future block possible?](https://bitcoin.stackexchange.com/questions/9452/is-pre-mining-of-a-future-block-possible)
CSᵠ
CC BY-SA 4.0
2022-11-21T23:31:08.623Z
I've reviewed this already and it doesn't answer my question.
I'm well aware that one can't mine block X+1 until block X has been solved, as each block requires a hash of the previous block to be valid.
My question is more around the benefits of identifying precomputations for the next block and storing them in memory. Would this be a beneficial approach in hardware?
arikachimoaririki
<mining-theory><mining-hardware><asic><memory>
Bitcoin mining pre-computation benefits?
arikachimoaririki
# Bitcoin mining pre-computation benefits?

(Asked by: username_0 on 2022-11-07)

I asked this question on another forum but did not get any responses so I thought I'd try here.

I've been researching bitcoin mining for a while and I have a work-in-progress hypothesis that could potentially speed up the mining process. I am keen to seek some feedback on the viability of this approach.

I've identified a way that allows asynchronous pre-computation of a number of values that can be computed well in advance of knowing the hashPrevBlock. These are billions of pre-computed 32bit values that do not need to be re-calculated when the block height changes; i.e. they can be reused indefinitely. The only caveat being that ASIC miners would now rely on memory to fetch these values instead of having to calculate it for every new hashPrevBlock.

In my opinion, this saves a lot of energy and chip area as the ASIC miner no longer needs to calculate these values. These values can be calculated once in software and then 'fed' to memories that the ASIC miners have access to.

Any feedback on how this approach is flawed or a non-starter? I have read about memory hard PoW algorithms that are ASIC-resistant. Am I making Bitcoin mining ASIC-resistant by such an approach?

Surely there have to be benefits of being able to pre-compute gigabytes of data ahead of time that will simplify/speed up the Bitcoin mining?

**Tags:** mining-theory, mining-hardware, asic, memory

> **Comments:**
> **username_1**: Does this answer your question? [Is pre-mining of a future block possible?](https://bitcoin.stackexchange.com/questions/9452/is-pre-mining-of-a-future-block-possible)  
> **username_0**: I've reviewed this already and it doesn't answer my question. I'm well aware that one can't mine block X+1 until block X has been solved, as each block requires a hash of the previous block to be valid. My question is more around the benefits of identifying precomputations for the next block and storing them in memory. Would this be a beneficial approach in hardware?  

---

## 0 answers

