Bitcoin mining on a calculator? :)

[John Ioannidis]

http://www.righto.com/2015/05/bitcoin-mi...-1401.html discusses computing sha256 on an IBM1401.

Anyone up to the challenge of coding SHA256 on an HP41?

[Les Bell]

(05-25-2015 01:14 AM)John Ioannidis Wrote:  Anyone up to the challenge of coding SHA256 on an HP41?

The User's Library had an implementation of RSA for the HP-16C, and it's on the Museum "DVD", from memory. However, a man has to know his limits. . .

I get my students to implement a DES-like cipher in Java; the pain of doing that kind of bit-fiddling in a language that does not support unsigned integers gives them a new appreciation of the virtues of C. I would expect similar pain here.

[Dave Britten]

Let's see, from a quick watching of that video of him doing it by hand, I see you'd need a majority function, a sort of bit multiplexing function, parity, bit shifts/rotates, and sums. Definitely not stuff the 41C was built for, particularly since it's all being done on 64-bit unsigned ints.

The 42S and 48* might be able to pull it off with far less hand-made bit manipulation code. Maybe the 16C, too. Does it have enough program space, and 64-bit word size?

[Les Bell]

(05-25-2015 02:23 AM)Dave Britten Wrote:  The 42S and 48* might be able to pull it off with far less hand-made bit manipulation code. Maybe the 16C, too. Does it have enough program space, and 64-bit word size?

The 16C has all the necessary instructions, and a 64-bit word size. I suspect it wouldn't be too hard to implement SHA256 on that machine, although Bitcoin mining, in the available time and memory, would be a bit of a stretch.

[Dave Britten]

(05-25-2015 02:29 AM)Les Bell Wrote:  

(05-25-2015 02:23 AM)Dave Britten Wrote:  The 42S and 48* might be able to pull it off with far less hand-made bit manipulation code. Maybe the 16C, too. Does it have enough program space, and 64-bit word size?

The 16C has all the necessary instructions, and a 64-bit word size. I suspect it wouldn't be too hard to implement SHA256 on that machine, although Bitcoin mining, in the available time and memory, would be a bit of a stretch.

Yeah, you definitely aren't going to do any practical Bitcoin mining on any of them, but technically you could do it for purely academic reasons.

[Les Bell]

(05-25-2015 03:11 AM)Dave Britten Wrote:  Yeah, you definitely aren't going to do any practical Bitcoin mining on any of them, but technically you could do it for purely academic reasons.

The stumbling block is that the hash needs to be signed with the miner's private key - and an RSA algorithm just fits in the 16C, with no memory left over (from memory - my 16C decided to throw a fit and clear memory not long after I'd keyed the whole thing in, so that I didn't really get a chance to play with it). The SHA256 won't fit at the same time, but both algorithms are required. That rather rules it out, unfortunately.

Now, if the 16C only had a very long tape which it could write and read back . . .

The RPL machines look like much better candidates in that light - especially with SysRPL.

[Paul Dale]

Sounds like a job for the WP 34S


- Pauli

[Les Bell]

(05-25-2015 07:46 AM)Paul Dale Wrote:  Sounds like a job for the WP 34S

I wouldn't put it past you.

[Dave Britten]

(05-25-2015 07:46 AM)Paul Dale Wrote:  Sounds like a job for the WP 34S


- Pauli

It's got 64-bit unsigned mode, bit set/clear (SB, CB), and test bit set/clear (BS?, BC?), plus rotate instructions, so it probably wouldn't be too hard.

[Egan Ford]

The SHA256 input for BC mining is 80 bytes with 32 bytes of output. 16C has 203 bytes of RAM. Can you fit the program in the 16C in 91 bytes?

[Egan Ford]

(05-25-2015 03:11 AM)Dave Britten Wrote:  Yeah, you definitely aren't going to do any practical Bitcoin mining on any of them, but technically you could do it for purely academic reasons.

Well, sort of. Today the nonce is too small. It's only 32 bits and current mining rigs can blow through that in a second with no solution. So extra nonce has to be added to the variable Coinbase Data in the first transaction of the block, and that in effect changes the Merkle Root (32 bytes of the header that gets SHA256'd). To compute the Merkle Root you need all the transaction data for that block (about 300-500KB). This would put most of these retro calcs out of the running.

If a newer version of the block header were to support an extra 8-12 bytes of nonce, well then, it shouldn't be a problem.

I only scanned the 1401 article, but it appears they ran SHA256 on a block that was already mined, i.e. with the correct nonce and extra nonce (merkle root).

[Egan Ford]

Hmmm... actually you only need the transaction hashes and the first transaction to recompute the Merkle Root. Assuming no more than 1024 transaction/block (recorded peak is 943), then that'd be only 32K of RAM + 50-150 bytes for the first transaction (payback to the miner). This can be future reduced with precomputed values for the other branches reducing the computation and storage to log₂1024. ~ 320 bytes + 50-150 bytes.

So yes Dave, you could. Too bad you will not be alive to see the results.

[Dave Britten]

(05-26-2015 02:36 PM)Egan Ford Wrote:  Hmmm... actually you only need the transaction hashes and the first transaction to recompute the Merkle Root. Assuming no more than 1024 transaction/block (recorded peak is 943), then that'd be only 32K of RAM + 50-150 bytes for the first transaction (payback to the miner). This can be future reduced with precomputed values for the other branches reducing the computation and storage to log₂1024. ~ 320 bytes + 50-150 bytes.

So yes Dave, you could. Too bad you will not be alive to see the results.

Yeah, heavy emphasis on the difference between "theory" and "practice" on this one.

[Les Bell]

(05-26-2015 06:19 PM)Dave Britten Wrote:  Yeah, heavy emphasis on the difference between "theory" and "practice" on this one.

Given that specialised ASIC BitCoin mining rigs run at 1.15 TeraHashes per second - and the serious miners run clusters of them - it's going to be pretty hard to win the race and be first to find the right nonce in order to claim the 25 BitCoins reward.

[Dave Britten]

(05-27-2015 08:21 AM)Les Bell Wrote:  

(05-26-2015 06:19 PM)Dave Britten Wrote:  Yeah, heavy emphasis on the difference between "theory" and "practice" on this one.

Given that specialised ASIC BitCoin mining rigs run at 1.15 TeraHashes per second - and the serious miners run clusters of them - it's going to be pretty hard to win the race and be first to find the right nonce in order to claim the 25 BitCoins reward.

Mere details! One need not take first place to finish a marathon. Though it certainly helps with obtaining sponsors.

I've (partially) implemented the SHA256 routine on my 48SX by following what he's doing in the "by-hand" video, and it's running 64 rounds in 47.44 s without any really tight optimization. It's not really a complete program, as his video doesn't explain how to obtain the final output, and I didn't bother finding the 64 values of K for each round, so I'm just using the first one over and over, but in terms of pure speed, it's not bad. If there were any practical use to this, I might get all the values of K and figure out some of the other details.

If your system has bitwise functions, then you can easily calculate the majority, choose, and parity functions as follows:

Maj(a,b,c) = A and B or A and C or B and C
Ch(a,b,c) = A and B or not A and C
Par(a,b,c) = A xor B xor C

No need to waste cycles manually looping and comparing each bit individually.

[debrouxl]

Someone did it several weeks ago on the TI-68k/AMS platform using TIGCC/GCC4TI: https://vimeo.com/123798651

[Egan Ford]

(05-27-2015 06:49 PM)debrouxl Wrote:  Someone did it several weeks ago on the TI-68k/AMS platform using TIGCC/GCC4TI: https://vimeo.com/123798651

That's not mining, it's just creating a private key for use with bitcoin. That can be done on any calculator. Converting to a public key using ECC and then SHA256ing and RIPE160ing that, and then base58checking to get a public address to accept funds is some work, but not mining.

[debrouxl]

Alright, I forgot about that and I stand corrected