Join 76,294 users and earn money for participation

How my RPi4 handles mining 1GB blocks

6 1262 exc boost
Avatar for mtrycz
Written by   82
4 months ago

tl;dr

It did it.

Introduction

I recently tried mining the biggest blocksize allowed on BCH's Scalenet on my beloved RPi4. I took some time to set up, but I did it! This was enabled by using the improved "light" template from BCHN.

Since then I have been wondering how far can it really go. So I progressively increased the number of transactions/blocksize to check.

If you don't know what this is about, check out Mr Toomim's article about Scalenet. Also, check out my other articles in this series: 1, 2, 3, 4.

Methodology

As usual I used my beloved RPi4

  • BCH's Scalenet

  • RaspberryPi4 (8GB version, with a 64bit OS), with a nice passive cooling case (keeps temeprature below 60C and helps with throttling)

  • an 8GB Sd card I had lying around

  • A spare 256GB NVMe SSD attached through an USB3 adapter (I upgraded my laptop to 1TB, so I found a use for this one).

  • BCHN node software (release version 23.0.0 with no particular patches)

Total cost: ~21 tx fees on the BTC network. (as of time of writing - subject to change)

I have generated transactions on my laptop with txunami and BU, and waited for them to propagate to the RPi. Tried to run my modified version of cpuminer on the RPi locally. Moreover, since a 1GB block is out of Scalenet's consensus, I ran a second BCHN node on my laptop to check that it is correctly accepted.

To produce a blocktemplate in reasonable time, I had to adjust the node's cache settings, with -maxsigcachesize=192 and -maxscriptcachesize=192.

Results

It took me some 1 hour 20 minutes to accept 5,2 million transactions to the mempool. Took some 2 minutes 23 seconds to generate a "light" block template.

I mined the 1G block 0000000004822a2d638459cf5a41c4df9f255f6744c4fd51bc81d5854cce0cbd on my RPi locally (with its respectable 800khash/s, it took me some 50 minutes), without hitting swap. The submission process (local re-validation) took some 9 minutes 50 seconds. It was correctly validated by my other BCHN node configured to accept 1GB blocks.

5.2M transactions took some 5GB of RAM, with the rest of my 8GB being used to create and validate the block.

I cannot show you the block on a node explorer, as it is out of Scalenet's consensus. But it being an RPi, the results are easily reproducible.

Conclusion

Technology will only improve. Software is technology, and it is improving at a steady pace. I love my RPi, because it is great at exposing bottlenecks in a reliable and reproducible manner. Just a couple of months ago, the maximum this hardware could mine was 128MB; with software improvements, now it's three (binary) orders of magnitude more. It's not feasible for any current practical usecase, but it's possible.

Currently 1GB is the absolute maximum an RPi could handle, with RAM being the limiting factor. It is also the absolute maximum it could sustain validating continuously without falling behind, because ARM doesn't have optimized assembly for checking signatures, as x86 does.

Technology improvements will expand the limits both of what is possible and what is safe. It's great to be a part of the community that is pushing this limits, for making Bitcoin Cash accessible for the whole world. Cheers!

23
$ 39.45
$ 13.37 from @molecular
$ 5.00 from @codevalley
$ 5.00 from @btcfork
+ 15
Avatar for mtrycz
Written by   82
4 months ago
Enjoyed this article?  Earn Bitcoin Cash by sharing it! Explain
...and you will also help the author collect more tips.

Comments

Congrats Just saw your post on bitcoin.com Nice 👍🏻🙂

$ 0.00
3 months ago
$ 0.00
4 months ago

ARM doesn't have optimized assembly for checking signatures, as x86 does.

You mean libsecp256k1? Would it be possible to get a comparable performance improvement for arm?

$ 0.00
4 months ago

I am relatively sure that a person familiar with ARM assembler would not have a hard time translating the x86 assembly into ARM.

Since it's security critical code, tho, it would be a big endavour to prove it right.

I think there are much bigger gains to be had in parallelization.

$ 0.00
4 months ago

Great experiment, thanks for doing this.

A spare 256GB NVMe SSD attached through an USB3 adapter

Is this the way to attach storage to an rpi4 with the highest speed or are there other good options?

$ 0.00
4 months ago

With a dedicated shield (that costs more than the rest of the setup) you could connect the NVMe SSD through a SATA shield with possible 10-20% io improvement wrt USB3.

* To the best of my understanding.

$ 0.00
4 months ago