This is just a symptom of pathetic system administrator ineptness to allow the file system corruption upon a power fluctuation.

Any "farm" scale computer operation has to be run with read-only file systems, configurations fetched via bootp (67&68/udp), error logging via syslog (512/udp) and monitoring via SNMP (161&162/udp).

I presume that Spondoolies initially hoped to be able to still make profit while pandering to the individual miners that are mostly ignorant of the proper network and system administration practices. And their move away from serving that market is to realize the savings from serving the markets where one can demand certain standard of computer literacy.

Even if by strange happenstance one was forced to use mining controller with a hardware fault that causes SD card corruption the sensible managerial solution is to keep only the controller on the centralized low-power UPS not all the power-hungry mining chips.

This is why all the companies serving the "retail" markets have those calling centers in India with personnel trained and prepared to deal with the complete ignorant.
 

Can't you enable swap? With swap enabled Bitcoin Core doesn't seem to have any significant problem dealing with the current flood. The overall server response time does increase but nothing crashes, although I haven't tried running 32-bit versions on the mainnet in a while.

Using uninterruptible power for coin mining never makes sense. All the past threads are just a proof of that: UPSes get installed only when the coin mine owners cannot retain the engineering talent required for the proper maintenance of the mine.

UPSes are only needed for small (but critical) subset of the equipment of the mine: security systems, temperature and climate sensors, fire alarms, edge IP routing. The borderline case is internal in-mine IP switching, probably only few core switches would benefit from UPSes.

One could even make a reverse case: if a coin mine installed UPSes then it is an early symptom of fraud occurring at the highest management levels in the organization.

Thanks for the explanation.

So this situation in California is somewhat similar to the historical cross-border empty beer bottles trade between East and West Germany. Enterprising German kids would buy beers in East Germany, drink it, wash the bottles to remove East German labels, affix some torn/fake West German paper labels and redeem the bottle deposit in the West. The arbitrage would not only pay for endless beer supply but also cover the fuel required to drive cross-border twice.

Germans took care of this crime by dismantling The Wall. I don't know what Californians will have to do.

I wonder how this current Bitcoin legal situation compares to how the regulation of pawnbrokers and swap-meets evolved in the USA. I can't even find out if the pawnbrokers are regulated federally or locally by the states/counties/municipalities.

I've drawn a blank in my circle of friends with legal education.

I couldn't find anything sensible on http://www.nationalpawnbrokers.org/ nor on http://www.californiapawnbrokers.org/ , the top two results from the search engine.

Edit: I've found something on Wikipedia (copied from Encyclopedia Britannica) under
https://en.wikipedia.org/wiki/History_of_pawnbroking . It seems that explicit licensing under common law started in 1785, so in effect USA imported their laws from UK.

On the related note about "martial law in the United States": not long ago I returned about 24 empty beer bottles to claim the deposit. I didn't have to sign anything to receive money, but I've noticed that most people (who were returning much larger quantities) had to sign something. Does anyone know what kind of fraud could be perpetrated on the recyclers?

This checkerboard pattern is not "making life easier at the silicon level". It is a symptom of using completely invalid approximate model of parasitic components and then using those approximated, but not really existing, parasitics as an additional power decoupling filter.

It seems like despite the claims of "full custom" Spondoolies is still using only a very approximate all-digital low-power models. They are essentially invalid because they are used outside of their range of validity (in terms of self-induced noise and dissipated power).

I'm not sure if I understood your 2nd paragraph. It seems like you think I proposed using two different pad pitches: one denser for the chip and one coarser for the board. What I intended to convey is using the same pad pitch on both chips and board.  The power traces are bundled in the way similar to https://en.wikipedia.org/wiki/Litz_wire .

The bundling and spacing is wider to so that simple faults like shorting two neighboring pads doesn't create board-level and circuit-level fault.

I'm not up to speed with the most recent digital EDA tools, but I don't believe that their low-power all-digital tools can properly model the skin-effect and long-transmission-line-effect for those types of pad and board layouts. To get accurate models one has to drop to the all-analog or nearly-all-analog modeling.

How would I know? It is not for me to judge, I'm just an observer.

In the past, in the case I was sort-of-involved by being the company insider, it took around 7 years from the time certain executive made certain sales projections to that executive being sentenced for breach of the fiduciary duty. Of that 7 years the company was defunct/bankrupt for 5-6 years.

The difference between the sentenced executive and the other one who weren't charged was, as far as I could tell, only that he was the most secretive whereas the other always kept giving interviews and co-authoring published scientific papers.

The way the lawyers explained it to me is that there's wide gray area between investing and gambling. Obviously there's no such actual charge as "criminal optimism", but it is an useful shorthand to how the courts decide in similar cases.

This is very grim when we can't assume an intelligent designer even in the Spondoolies' thread.

I was sort of OK, when the Chinese mining chip vendors weren't able to hire or contract the actual design talent. China is undergoing a period of extra-fast growth and there are plenty of competing opportunities there.

But I'm getting scared if a Jewish company can't find an intelligent Jew to stay with them even part-time to tell the ins-and-outs of hardware engineering.

What does it mean for Bitcoin if the really intelligent Jews avoid it and the only Jews that deal with Bitcoin are the ones that skew towards being criminally optimistic?

Crazy stuff! Where did you get such information?

The soldering difficulty is way overstated for the mining chips. It is true that the BGA packages have hundreds of contact points. But with a halfway-intelligent design those BGA pads can be easily made quadruple-redundant with double spacing of no-contact pads in-between.

Then the expensive precision placing & soldering & x-ray testing will not be necessary.

All this of course assumes an intelligent designer.

Bad pinout example:
Good pinout example:

I have nothing against steam locomotives. But there are two kinds of steam locomotive engineers:

1) the ones that only know how to shovel the coal from the back tender to the front boiler;

2) the ones that could explain to you various kinds of https://en.wikipedia.org/wiki/Valve_gear and why https://en.wikipedia.org/wiki/Walschaerts_valve_gear is the most popular.

As a kid I was fascinated by the steam locomotives and had a good fortune of meeting the 2nd kind of railroad engineer.

It is the key difference between education and training and it has been known for a long time:

https://en.wikipedia.org/wiki/Hacker_koan#Enlightenment

A novice was trying to fix a broken Lisp machine by turning the power off and on.
Knight, seeing what the student was doing, spoke sternly: "You cannot fix a machine by just power-cycling it with no understanding of what is going wrong."
Knight turned the machine off and on.
The machine worked.

It is EISA not ISA. The interface to the SHA-256 miner really wants to be 32-bit wide. As far as I know those are still being made as "passive backplane" industrial control computers. If somebody is dead-set on the TTL implementation EISA is the way to go because of sufficiently high IO voltages and sufficiently low IO clock speeds. I would think that meeting the PCI-X timing requirements using raw TTL logic may require some significant skills.

For the sane educational project probably the best kit would be something like http://zedboard.org/ which is Xilinx Zynq (ARM Cortex A9 & Kintex 7Artix 7^?  FPGA on the same chip with all the required interfaces).

For still sane but really budget-stressed project the $10 Cypress PSoC http://www.cypress.com/CY8CKIT-059 would be another sensible learning choice. It is ARM Cortex M3 with 24 CPLD-like Universal Digital Blocks. And the whole development toolchain for it is free from Cypress Semiconductor without the need to be affiliated with an educational institution.

In my opinion soldering 74-series chips by hand is a skill about as useful as knowledge of the railroad engineer on how to operate a steam locomotive. We have 21st century now. Search for "Xilinx ISE schematic capture" and get on with the program...

http://uhaweb.hartford.edu/kmhill/suppnotes/iseschem/index.htm
http://www.digilentinc.com/Data/Documents/Tutorials/Xilinx%20ISE%20WebPACK%20Schematic%20Capture%20Tutorial.pdf

Edit: grammar fixes

I don't know what your psychological disability is, so I can't help you.

The information required to solve all the technical problems to implement hardware SHA-256 miner is all available here on this board. Multiple people did their own implementation using the sensible learning technology of the XXI century: FPGA development kit. It takes between a week or a month to do it from scratch, depending on the student's aptitude. Simple FPGA development kits cost less than $100, many schools can get them for free.

For the problem you posed I think you misunderstood the description of Ki constants in the FIPS-180. FIPS describes how to derive them to show that those are "nothing-up-my-sleeve" numbers. Any hardware implementation will simply store those constants in ROM or other storage device.

The whole point is that rolled (not-unrolled) SHA-256 will require less gates than the serializer plus deserializer and the sequencers required to interface with anything less than 32-bit wide.

SHA-256 is essentially a 16-position shift register that is 32-bit wide. The fancy hashing feedback is mostly 32-bit wide adders and some bit twiddling that in hardware can be implemented mostly with wires and very few gates.

The above 32-bit circuit will be trivial to interface to the computer provided that  the computer has a 32-bit bus like EISA or PCI-X.

With any narrower bus more gates will go into the required sequencing logic than into the actual hash computation.

Show me any USB chip that can put-out or latch-in 32 bits in parallel.

All this doesn't require decades of engineering experience. Even completely cursory understanding of the evolution of the PC-compatible computers is sufficient to understand that the wide ribbon cables and long edge connectors disappeared from the computers only very recently. In the TTL days of SSI/MSI chips all interfaces were parallel and as wide as people could afford.

You all guys deserve an F for your TTL logic design proposals involving serial interfaces.

Y'all need to hit the books and get a refresher on why all early computer interfaces were parallel: printers, disk drives, floppies, everything had wide cables: ribbons or Centronics or other SCSI connectors.

The serial interface revolution was made possible only by the cheap LSI ICs.

I don't remember Intel part numbers off hand, but go lookup the early Zilog parts from the Z80 family: PIO vs. SIO. And those were 8-bit parts. You will need at least 32-bit wide interfaces to sensibly implement in TTL the key component of SHA-256: 32-bit carry-look-ahead adder using 74181 and 74182, which are 4-bit slice parts.

And how would you interface it with a computer with a network interface? I mean without using more TTL chips for the interface than for the computation core?

It is my understanding that removing this restriction is a high priority task item for the Bitcoin Core developers. I don't exactly follow their progress, but many people expressed interest in having both pruning and wallet working at the same time.

I should've quoted this portion of your original message in my reply.


Yes, this can be done for BerkeleyDB but not for LevelDB. Apparently there exist code that is LevelDB-compatible and fully multiuser/multitasking but it is only available from Google for money and NDA.

Probably the easiest way is to run Bitcoin Core with -privdb=0 flag and reopen the wallet.dat in a shared mode. You'll still have to make RPC calls to populate addresses, but at least transactions can be queried live through BerkeleyDB API.

Well, I would really advise you to investigate markings on all chips on the board and see if any other contains something LM75-compatible. It should be fairly easy and safe to do the tests by touching the plastic cap of the chip with a soldering iron and look for any temperature readout to rise sharply.

The continuing popularity of an obsolete chip like LM75 was perplexing to me. Apparently it is still being used as in the last-resort over-temperature protection circuits. When not programmed in any way it will power-up as an over-temp protection set to trigger at 80 degrees Celsius.

On this miner it may be wired up to shut it down when the in-cube ambient temperature goes over 80C, which will serve as a sort of pre-fire-protection circuit even if the programmable controllers are hung or disconnected.

Well, the LM75 physical IC is for sure a local sensor only.

On the other hand, if you are looking at the code commented as "reading from LM75" there is a whole bunch of "LM75 register-compatible" ICs that could be using both local and remote sensors.