I agree with the 2 last sentences in the quote above. But I also feel that you didn't get why experienced investors feel as very repelling: you are one of the tailors that keeps claiming that the suit fits.

But at the opposite side of your work you perpetuate completely flawed JSON-RPC protocol with "long polling" addition where successful use is indistinguishable from a DDOS. All that while the existing financial software development community has almost 20 years of experience with protocols like FIX which are both more efficient and more resistant to DDOS attacks.

If the Bitcoin was the 20-million company the shareholders would remove you from your seat on the board of directors.

What you writing about unrolling is both 100% true and 100% not on the subject of digital design.

What you write about SHA-256 implementation is simply incorrect. The full SHA-256 of the fixed 256-bit string takes exactly 64 rounds, not 80. This is the minor thing. The most important thing is that all the published rolled designs are sub-optimal in that they aren't fully pipelined.

Example: 32-way unrolled single SHA-256 they always take 2 clocks between taking and delivering the results, 16-way: 4-clocks; 8-way: 8-clocks; and so forth.

What I remember from my digital design class was the example of Seymour Cray. At that time it took 3 clocks to do a floating point add. Everyone was convinced that to add N floating point numbers it will take N*3 clocks. Well, Seymour Cray proved them wrong: his Cray-1 machine added 64 floats in 66 clocks and made the history.

It seems like Bitcoin hasn't yet met somebody with full understanding of the digital design. There was a guy who came and went with only 8 posts without openly publishing his FPGA design:

https://bitcointalk.org/index.php?topic=9047.msg454555#msg454555

So the Bitcoin is still waiting for somebody to fully exploit the apparent parallelism in its hashing algorithm.

On the other hand I think that the "weakest hands" in the bitcoin system are the developers. And this happens because miners are strangling the developers.

Bitcoin as an invention is one thing. Bitcoin as currently implemented is one of the most dysfunctional open source projects that ever existed. The not-invented-here mentality combined with the misanthropic attitude towards integration with the existing financial and accounting software is on the par with some of the worst-run government-subcontracted software projects. The result is glacial pace of progress in the actual software implementation.

So you may rant about the "weak hands" of the investors. But any smart investor will explain why "you don't ask the tailor if the suit fits". The platitudes about "smart people working here" aren't cutting it anymore.

Over the last couple of months I wrote several post with detailed problem explanations, so you'll have to review my posting history for the arguments.

Good luck in the search for greater fools!

This isn't that obvious to me. It seems like ArtForz choose suspiciously small value for the scratchpad size when parametrizing scrypt() for TeneBrix: 131583.

Converting that to bits gives me slightly over a megabit. This is well within the BlockRAM resources for the Xilinx chips that are currently popular among miners. It isn't out of the realm of possibilities why a custom microcoded implementation of ArtForz's scrypt() would be necessarily slower that on the common CPUs. The requiring mixing array should fit with the FPGA "cache". Here "cache" means it would not require going off the FPGA to an external RAM.

Besides, ArtForz is known to be crafty that way and has a very specific sense of humour.

Thank you for your input. I resolved to stop using my 4GB RAM machines for any serious future work. Because of my stupidity I installed the FPGA design software on a laptop that cannot be upgraded beyond 4GB. I need to re-think my planned computer purchases.

This is a link for future reference:

http://www.xilinx.com/ise/products/memory.htm

I wish I read and understood it before I rushed to install the Design Suite.

Did you run 4 smartXplorer iterations on a same CPU taking advantage of the quad-core? Or a single iteration took 16GB of RAM to implement a single Spartan-6 design?

Thanks for the encouragement. I managed to do an implementation on VLX240T with LOOP_LOG2=1 on my 4GB laptop. It has about 33% utilization of SLICEs, design strategy was "Runtime reduction with multithreading" and the swapping wasn't that bad.

So the next question I have is: would I be able to keep comfortably doing my trial VLX240T designs if I upgrade my laptop to 8GB of RAM? Or would the experienced people rather suggest that I dedicate a desktop machine with 8-16GB RAM and a PCIe slot for my ML605 experiments? Xilinx says that the ISE_DS will be nodelocked to the actual Virtex-6 chip, I presume through the USB cable, right?
 

For the future reference: running ISE_DS' fpga_editor on Ubuntu Lucid requires the following magic incantations:

1) install old versions of libstdc++ from Ubuntu Hardy:
    libstdc++5_3.3.6-15ubuntu4_i386.deb libstdc++5_3.3.6-15ubuntu4_amd64.deb

2) install libmotif3 and libmotif-dev for your main architecture. If your Ubuntu is 64-bit then
    you may also want to install the 32-bit versions, as the Motif libraries aren't built with multilib:
    libmotif3_2.2.3-4_i386.deb libmotif-dev_2.2.3-4_i386.deb

3) change the DISPLAY environment variable to use the non-multiscreen format
    DISPLAY=:0

Instead of fighting with whatever user-firendly package management tools you are using you have an option of instaling the few releveant *.so and *.a by hand:

a) mkdir temp; cd temp
b) ar xv ../whatever.deb
c) tar xzvf data.tar.gz
d) sudo mv usr/lib/*.{so*,a} /usr/lib (when installing libraries matching the system)
e) sudo mv usr/lib/*.{so*,a} /usr/lib32 (when installing 32-bit libraries on the 64-bit system)
f) cd ..; rm -rf temp

Seems like 64-bit FPGA editor isn't starting cleanly on 64-bit Ubuntu and gives the following dynamic linking warnings:

.../bin/lin64/_fpga_editor: Symbol `_XtperDisplayList' causes overflow in R_X86_64_PC32 relocation
.../bin/lin64/_fpga_editor: Symbol `_XtGetPerDisplayInput' causes overflow in R_X86_64_PC32 relocation

but it appeared to operate correctly during my short inspection. I nonetheless installed the required 32-bit libraries on my 64-bit system and the 32-bit FPGA editor starts without any complains.

Oh, and the last thing: ISE seems to have hardcoded the Acrobat as a PDF reader. The quick workaround is:

cd /usr/bin; sudo ln -s evince acroread

No need to restart the Project Navigator.

I have a quick question for those familiar with Xilinx Virtex-6 chips:

I have a different application that requires double SHA256 of a 256-bit string, thus the typical mining optimizations don't apply. Would the fully unrolled all-combinatorial-logic hasher fit into the XC6VLX240T-1FFG1156 that is included in the ML605 evaluation board? Please disregard any speed issues. At this moment I'm only concerned with the correctness of the implementation and being able to use my old VHDL files. The goal is to reproduce the defects in some faulty silicon of historical value.

With quite a difficulty I installed evaluation ISE_DS on my Ubuntu 10.04.3 and even managed to start the Xilinx FPGA Editor that uses old Motif libraries. But attempting to do any implementation on Virtex-6 device on my 4GB RAM laptop is hopeless; it goes deeply into swapping storm.

I tried to understand the modifications that somebody made to get this miner run on ML605. It apparently had 3 hashing cores, but I'm unclear if the DSP48E1 use was a requirement or choice. I'm also unclear if the 3 hashing cores were 3*single-SHA256 or 3*double-SHA256.

Thanks for any pointers you may have.

The SHA256 isn't really a big intelectual property development. To me it seems like a single-semester student project in microcoding. Off-the-shelf SHA256 cells are ususally designed for fast streaming. And the various designs published (or alluded to) here looked like they were unrolled and limited by the signal propagation over the long interconnects. I haven't seen anyone doing the opposite extreme: packing a lot of slow but small hash cells into a single chip.
 
Maybe not "fell off a truck", but a straight "dumpster diving" at some research or test facility. I have no current knowledge of the foundry business, but in they days past I've met people selling analog and mix-sig ICs that were mismatched or half-operational rejects. One person's trash was the other person's treasure.

OK, this thread is fascinating. So I'm placing a bet with myself on how this device might work:

1) They optimized the SHA256 hashers for a different objective: maximum hash per sec per square millimeter using a heavilly rolled design, possibly even microcoded custom CPU. This would be unlike anyone else here on this board who did maximum unrolling for the maximum hash speed with no chip space constraints.
2) They filled some very expensive FPGA device with a sea of thos ultra-compact hashers and they are working on the distribution/collection logic.
3) They sourced some small quantity of defective FPGA devices of the type above and working on a suitable test vectors to identify those of them that can still be profitably employed despite only a portion of the chip operating correctly.
4) They need to grind-off any chip markings that would allow identifying their source for the defective chips.
Because of the grey-market chip source and the need for grinding the whole operation makes sense only as a small-time hush-hush enterprise.

So this is my hypothesis. Is there anyone here who's really familiar with the current black-market for the defective and out-of-spec silicon? If so, please post your speculation with a new account through Tor or some other proxy.

Dude, far out. You could've just written: sorry, I had a thinko. Now you've proven that you don't understand the basics of the global convergence of the Bitcoin protocol. I guess I now better understand the plight of Gavin and other core developers that simply clam up and don't discuss any changes in the core protocol. One one hand miners are essential to the overall security, but on the other hand miners most likely don't understand what makes that network stable.

I normally cut the quotes, but this one is worth preserving in full.

It is as true as: 'Schizophrenic: "A Self-Contained Human Being"'.

One thing that Bitcoin has in common with schizophrenia: seems like nobody had analyzed the implication that the currency exchangers have two streams of income: one in bitcoin and one in fiat. They can use one to cross-subsidize transaction fees in the other.

The whole "mining pools" as a business entities are the proverbial giants on clay legs.

I'm thinking of the future will bring the interesting battles between terahash dinosaurs and the little mice that can survive by scratching both sides of the coins.

I don't think that would converge globally. With frequent adjustments each pool would distrust blocks from the others and the network would split into islands. Infrequent adjustments decrease the probability of network splits. 2016 may not be optimal, but seem very safe to assume that in two weeks a clear maximum difficulty leader will stabilize globally.

Yeah, totally out of place. What Bitcoin needs is nothing less than silver-bullet-oriented programming. I mean what is the better proven stable store of value: the silver quarter minted in 1960 still buys you a gallon of gasoline. And silver is the best conductor of electricity thus assuring the success in the modern world of fast-paced e-commerce.

But seriously: CS curricula everywhere need to be extended to include mandatory satire-writing classes. It is just a requirement for a well-rounded education in computer science.

It isn't fine even now. The latency over Tor's 6-hop hidden service connections is significantly higher. I was under impression that Bitcoin from the start was designed to be tolerant of higher-latency networks like Tor.

Something else. Hughes uses http://en.wikipedia.org/wiki/Carrier-grade_NAT , thus you have no hope of accepting incoming connections.

It makes me wonder: have any of the pool operators tried to implement long poll with Twitter?

I kinda understand their pain: how to implement a reliable multicast when seemingly the only tool available is a massive abuse of unicast?

Well, the financial dynamics is somewhat different. mybitcoin looked like small-time scam. If OKpay is involved in money laundering they will go out of their way to offer very good deals to the non-laundering customers to create a legal cover and detraction from their primary moneymaking enterprise. If they have 10%-30% margin on their laundering revenue they can plow some of it back to the side bets that provide the cover.

I remeber the days when money laundering was done through the prepaid long distance calling cards. Some of the best deals one could get were offered by the shadiest outfits. One could just call the customer service number and ask for credit for bad quality connection and they would give that over and over, practically with no limits for a single person making phone calls.

It is probably one of the many Russian money laundering outfits. Incidentally Slashdot had an article recently about that industry:

http://mobile.slashdot.org/story/11/11/10/2131233/how-cell-phone-money-laundering-works

With friends like these Bitcoin doesn't need enemies.