Bitcoin mining on a vintage Xerox Alto: very slow at 1.5 hashes/second | Hacker News Reader

Bitcoin mining on a vintage Xerox Alto: very slow at 1.5 hashes/second

righto.com

251 pointsdarwhy41 comments

It actually puts compute power in perspective for me quite nicely, as GigaHashes per second (GH/s) is the most common metric in mining pools. My core i5 laptop gets around 10MH/s. A gaming desktop with GTX1050 pushes above 100MH/s.

Compare that to a state-of-the-art Antminer at ~11Th/s using 1.1kW. Estimating a large pool size of ~250 Ph/s. And the Alto's rough payout calculation of about a billionth of a penny for 2017 looks right!

Any chance ethereum and zcash mining are up next for that poor old Alto that just wants to retire and dream of electric sheep?

> It actually puts compute power in perspective for me quite nicely

Apparently doing it manually is about 0.67 hashes per day http://www.righto.com/2014/09/mining-bitcoin-with-pencil-and... so it's still nearly 200,000x faster than a human with pencil and paper.

If I understand etherium and zcash mining, they use algorithms designed to require a lot of RAM so it is ASIC-resistant. (I.e. they want mining to be practical on a PC, not requiring custom hardware.)

Unfortunately for the Alto, the gigabytes of data required for mining won't fit into the 512kB memory. Even swapping to the hard disk won't work, since that only holds 2.5MB. Thus, while Bitcoin would have been possible in the 1970s, etherium and zcash wouldn't have been.

> Thus, while Bitcoin would have been possible in the 1970s, etherium and zcash wouldn't have been.

Not with current DAG sizes, but if this system had been available in the 70s it wouldn't have the current DAG sizes. If you assume a DAG that numbers in tens/hundreds of kbyes then it would have been workable.

Not only lots of RAM but lots of very fast RAM. This is what makes it ASIC-resistant for now (it's not hard to attach a huge RAM to an ASIC, but going for hundreds of GB/s is really expensive). So unfortunately it's GPUs for now.

\> unfortunately

i think you are missing the point. the idea is to prevent ASICs from taking over. if you could build one that could mine ETH or zcash, it would be a failure from their perspective.

I think parent means it's unfortunate for those of us that are looking to buy a video card for gaming. Or actual work.

It's unfortunate because the GPU prices and availability right now are going nuts. I wanted to buy a GTX 1070 and it's out of stock with weeks of waiting on preorders on most European websites, with price increases of 40-50% in the last 30 days.

In the short term it may seem more unfortunate, but the problem with expensive ASICs is that they make centralisation far easier, by making it less feasible for ordinary people to do the mining.

The people behind sia coin believe differently [0] and after reading that I'm more inclined to believe them.

The short version is that since "commodity" hardware can mine many things, you can't gauge how much power there could possibly be. Someone with 100,000 GPUs could turn their whole system to your coin and have over 50% of the hashing power for a day, then go back to whatever else the day after.

With ASICs, the devices can't be used for anything other than that specific coin, so to "save up" your hashing power to sneak in a day that you can get majority hashing power would be stupid. You'd have to be giving up the income from them while you waited.

The article explains it much better than I can, I really recommend it.

[0] https://blog.sia.tech/choosing-asics-for-sia-b318505b5b51?gi...

What's stopping a government agency from "saving up" their hashing power so they could get majority control over Bitcoin if they needed to? Seriously, if you were the NSA, wouldn't this be a sensible thing to spend a few million dollars on? And they could use their mining hardware now, hidden through pools, so it would almost pay for itself. (Yes, I know I'm getting into tinfoil hat territory.)

In practical terms a 51% attack is not good, but actually has a fairly straight-forward solution to solve. Change the PoW. A 51% attack can't steal your coins, only restrict your spending them for the length of time they are conducting the attack. So the issue isn't that you have 51% attack possibility, but that people think you do, and furthermore think you're going to abuse it. If a government attacked it, they'd simply hard-fork away from the mining algorithm, and millions of dollars of hardware investment gets flushed down the toilet.

200K antminter S9 will produce about 50% hashrate of current bitcoin network that cost about 300M$ not counting electricity (200MW). But that means they have to R&D themselves these chips if they want attack quick. Otherwise they won't getting that much hashpower in one piece.

If they decide slowly enter game, attack price will raise significantly since network difficulty will be adjusted as they will add more of their miners into network and their projected 50% hashrate will be just 25%

So realistically its about 1 billion $ to attack current bitcoin network.

Nothing I guess, but they also aren't saying ASIC based mining perfect, just that it's better than the alternative (GPU based mining algorithms)

$2500 BTC makes spending a lot of money on asics reasonable, because if prices hold, you can earn back a large spend in 6 months or so. Finding the asics to purchase becomes the problem.

My copy of The TTL Data Book suggests that the ALU was able to do XOR, an earlier blog post stated that microcode opcode bits go through a table instead of being fed directly to the 74181 function pins.

I wonder why Xerox didn't want to use all the ALU features.

In microcode, the Alto provides the 16 most useful functions of the 74181 (calling most of the 74181's operations "mostly useless"). This includes XOR and OR. However, the Alto copied the Data General Nova's instruction set, which doesn't include OR and XOR, so you can't use these instructions from machine code. I think there's extended microcode that provides "extra" instructions for XOR and OR and an improved BCPL compiler to make use of them, but I haven't tracked it down.

See the Alto hardware manual (page 4) on bitsavers for details: http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/...

Here is a document I found on the DG Nova instruction set:

http://users.rcn.com/crfriend/museum/doco/DG/Nova/base-instr...

If you scroll down to "Arithmetic/Logic Instructions" you'll see that they did not have room for XOR nor OR, since several of the 8 opcodes that fit into the 3-bit field are what we'd normally think of as "one-operand", but have been expanded to be "two-operand" (oddly enough, there is an increment but no decrement instruction either.)

It's interesting to compare to two other well-known CPUs with a 3-bit ALU opcode field:

The Z80's (and 8008/8080/8085) ALU opcodes are: ADD/ADC/SUB/SBC/AND/XOR/OR/CP

The x86's ALU opcodes are: ADD/OR/ADC/SBB/AND/SUB/XOR/CMP

That's an interesting comparison with microprocessor ALU operations. (6502 is similar to Intel but doesn't have add/subtract without carry.)

Note that the Nova uses two additional instruction bits for the carry. Thus, the Intel instruction sets use two of the 8 opcodes for add with carry and subtract with borrow/carry, but the Nova doesn't. So it should be easier for the Nova to fit in additional useful ALU instructions. (Not to mention the Nova has 16-bit instructions.)

From your link there looks to be two functions spare, I guess you would need a new PROM to make use of them though.

The MIT Lisp Machine does just map microcode instruction bits onto the 74181 function pins but it has much wider microinstructions than the 32-bit Alto ones.

Is there documentation/examples for how to program the Alto's microcode?

The Alto hardware manual explains how the microcode works (see sections 2 and 9 and try to memorize Figure 1). For examples, see the existing Alto microcode. The subsystem manual p90 describes the MU microcode assembler and the syntax. See also RPRAM in the subsystem manual that describes how to load microcode into control RAM. I haven't seen anything like a howto/tutorial for microcode in the Alto documentation.

http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/... http://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/... http://www.mirrorservice.org/sites/www.bitsavers.org/pdf/xer...

If you want to try this stuff out for yourself (and don't have an Alto handy), use the ContrAlto emulator: https://github.com/livingcomputermuseum/ContrAlto

An option is to use the BITBLT instruction which could be called from BCPL:

ftp://bitsavers.informatik.uni-stuttgart.de/pdf/xerox/alto/BitBLT_Nov1975.pdf

Dan Ingalls showed how to implement the Game of Life and how to rotate bitmaps using this instruction in a SIMD style. While BITBLT implemented all 16 possible boolean functions, not all were equally fast.

To be fair. I'm impressed it's able to do it at all.

I compiled a "hello world" in C staticly on my laptop the other week as a demo of how things have grown; to my horror it wouldn't have even fit in memory of my first computer.

Well, I got SHA-256 running on a 1960s punched card machine with 16K of memory so the hardware requirements aren't too much.

http://www.righto.com/2015/05/bitcoin-mining-on-55-year-old-...

Some people still care! Chuck Moore's colorForth has this inplementation of an IDE driver in just five lines of code:

  bsy 1f7 p@ 80 and if bsy ; then ; 
  rdy  1f7 p@ 8 and if 1f0 a! 256 ; then rdy ; 
  sector 1f3 a! swap p!+ /8 p!+ /8 p!+ /8 e0 or p!+ drop p!+ drop 4 * ; 
  read 20 sector 256 for rdy insw next drop ; 
  write bsy 30 sector 25 6 for rdy outsw next drop ;

comments

  p@ read 8-bit port 
  p!+ write 8-bit port, increment port 
  insw read n words from port 
  outsw write n words to port 
  /8 shift right 8 bits
  bsy wait till busy bit clear 
  rdy wait till data-ready bit set 
  sector set logical sector and command 
  read read 256 sectors 
  write write 256 sectors

https://web.archive.org/web/20160304043631/http://www.colorf...

SHA256 doesn't require all that much storage nor code --- a few KB at most for a simple, not very fast implementation.

same environment other than memory constraints?

... I'd think this wouldn't even work at all

I wonder about Ryzen's new SHA1/SHA256 instructions, not only for Bitcoin but also things like SHA1 collisions.

AMD's and Intel's SHA256 instructions are utterly useless to compete with ASICs: they use approximately 10 000 times more energy (4 orders of magnitude!) than a 16nm Bitcoin mining ASIC per hash: 1000 J/GH vs 0.1 J/GH.

Source: I wrote one of the first GPU miners, founded a Bitcoin mining ASIC system integrator company, etc.

From your perspective, how should an individual with a non trivial sum of money ($20k for example) get started mining BTC? Do you favor mining or investing by purchasing?

Large professional miners spend on average $0.05/kWh on their mining ventures, including all other non-electrical overheads. So as a small miner with virtually zero overhead, you should only mine if your electricity cost you $0.05/kWh or less. If you do, buy an Antminer S9.

But personally I prefer simply investing in BTC.

It's probably not economical to compete with large mining operations as an individual, since they get much more favorable deals on electricity.

Hmm. In contrast to a GPU / ASIC implementation, where thermal load is spread equally across the die, I'd guess that coin-mining usage levels will lead to local overheating and thus throttling - or worse, if there's no thermal sensor for this area, even permanent damage.

Intel's chips have those too - but I highly doubt the speedup will provide even close to gpu power efficiency.

Only Goldmont Atoms I think.

Cannon Lake is supposed to bring them to Intel desktops some time 2017 or 2018.

The performance of these is in the 2-3 cpb range per core on Zen.

They're using the British Cruddy Programming Language? Don't they have the Mesa compiler up?

BCPL is about halfway between assembler and C.

Still working on getting Mesa running...

BCPL isn't as primitive as I expected. It's surprisingly similar to C, except lacking types. C's structs, unions, bitfields are almost a direct copy of BCPL, along with the ternary ? operator. C's lvalues, rvalues, and pointers are also just like BCPL.

BCPL has way more control flow statements than C: if EXP do STATEMENT, unless EXP do S, test EXP then S1 or STAT2, test EXP ifso S1 ifnot S2, while EXP do S, until E do S, S repeatwhile EXP, S repeatuntil EXP, S repeat, switchon EXP into CASES, etc. The C language trimmed out a lot of the redundancy. BCPL's switchon statement is just like C's with fall-through cases unless you use a break.

Does it run DOOM?

I know this is a joke, but the Alto (IIRC) was the first computer to have a 3d maze like game - I believe they even played it over LAN!

Reply on news.ycombinator.com