You've spent too much time arguing with dumbasses and marketroids which caused you to start believing in your own bullshit.

Almost from the inception people understood the importance of distributed node network, even if under centralized control:

1) ability for nearly anyone and relatively cheaply audit (in the accounting sense) the totality of the system.

2) distributed node architecture makes it easy and cheap to hide the actual expensive nodes (either due to mining or transacting/exchanging) from both attacks launched over the network.

3) not currently implemented by Core, but possible, the broadcast architecture makes it possible to use non-Internet methods of communication with super-extreme bandwidth asymmetry (high download but little upload).

Dinofelis, you clearly seem to have some academia background. But it must have been some theology school (or something equally anti-scientific) to be so unwilling to actually refer to the available references and verify your own assumptions.

I have following comments:

1) split profits and costs with the owner of the property. Offer to help maintain the property in a sellable/rentable condition: some cleaning and maintenance, especially windows, roofs and air ducts.

2) upgrade security. I don't know what exactly "abandoned" means in your case. You'll need to make sure that the location wasn't used by squatters, for warehousing some dangerous/toxic materials or is infested with some vermin.

3) recheck the fire safety regulations: alarms, access roads, etc.

4) make sure that you are actually dealing with an actual owner/deed holder, not some "defective lease holder"

The general idea is that when you'll bring your equipment into a location you want to be sure that it is going to stay there and work for you. You want to avoid the possibility of accidental destruction, theft or repossession in lieu of past debts.

Ah! Greetings retired IBM-fanboi! In the IBM-universe I'm not a big MVS fan, I'm was more into running multiple copies of MFT or CMS under VM/370.

Let me start from the last paragraph. The reason I'm writing and responding to you is standard one for me: I know that for 1 poster here there are at least 10 readers who will read yours and mine posts with understanding. So when I'm personally addressing you (delicopsch56) it is more of a rhetorical device to address the plurality of you (named and unnamed readers of this thread).

In particular I'm writing for the benefit of young readers, who are still ahead in their life. They can still use their school time to "learn", not to "have fun". They can still avoid having "successful career" where maintaining employment was only possible with the help of regularly obliterating their own brain with alcohol (or other addictive substances or behaviors). I used to work in the entertainment industry and I can immediately recognize a bitter burnout. I've been on the meetings where people would small-talk about addiction rehab facilities like most of the employed people discuss vacation destinations.

There isn't much technical and mining-related to address in your reply. You've however very clearly and beautifully underlined the perils of technical fanboism. Most of the technical forums have fanboi discussion threads like Intel vs. AMD, ATI vs. NVidia, etc. delicopsch56 is an example of a dinosaur fanboi, from the days when various IBM-designed machines were bought under the assumption of "nobody ever got fired for buying IBM". IBM may even had "fastest horse" trophy for awhile, they still sell them under "z/Arch" moniker, but lots of people got fired for continuing to "buy IBM" where different, better, cheaper, faster solutions were available.

The simplest, easiest way to avoid burnout and being perpetually perplexed is to keep your mind open. Even if you don't have time or money to pursue a formal degree you can still greatly benefit from clicking around the "See Also" links in Wikipedia. And when you choose to "have fun", choose the activities that do as little as possible damage to your brain.

I want to personally "thank you" to all those people who gave the similar advice when I was young student in school. You most likely won't read it. All I can do repay it is to repeat it in an updated way, with modifications to match the changed technological landscape.

I avoid this type of argumentation (back-end, physical) not because it is inherently bad. I avoid it because historically in the Bitcoin milieu most bullshit was using this type of argumentation. Some of it was intentional, profit-motivated bullshit meant to deceive. Some of it was plain dumbassery and fanboism with no actual ill intentions, just mostly lack of introspection and inquisitiveness. The profit-motivated bullshit has now shifted to other crypto-coins with various discussions of "ASIC-proof", "memory-hard", "branch-heavy" and other post-Bitcoin bullshit.

The reality of year 2017 is that it takes about $99 (for Digilent Arty FPGA experimenter board) and about month's worth of free evenings to learn and understand all the requited basics of crypto-coin mining. For Bitcoin the heydays of profitable FPGA mining are over, but all the technical concepts are still valid. All the required software (and knowledge) are either open-source or available for free from the FPGA vendor under chip-lock license. It clearly isn't a replacement for a full graduate degree in a related engineering discipline. But it is more than sufficient to quickly and clearly recognize bullshitters posting here and in other venues.

You may not like my answer, but I will be short and frank.

The primary reason has of your inability to understand has nothing to do with old age, not following the recent trends, etc.

You've simply received a horrible education and know nothing about the digital technology advances from made in the middle of 1950 decade.

You seem to only be aware of https://en.wikipedia.org/wiki/Von_Neumann_architecture first published in 1945 and you seem to try to translate everything into it, even if clearly the implementation uses different conceptual model. Bitcoin mining is a perfect example of problem better handled by https://en.wikipedia.org/wiki/Mealy_machine (from 1955) or https://en.wikipedia.org/wiki/Moore_machine (from 1956). Any discussion involving concepts like: caches, branches, CPU, I/O, threads, cores, etc. only shows that the person writing it doesn't know the technological advances from the middle of the previous century. In my school these are discussed in the 2nd or 3rd semester of education, literally during couple of of first lectures in the digital logic design (both theory and lab practice)

The primary advances in the power efficiency of the Bitcoin miner were:

1) to implement it as fixed program Moore machine on an FPGA. The FPGA device is itself reprogrammable, so it is still wasteful
2) to have the same fixed program Moore machine implemented without the waste of supporting reprogramming and take advantage of the fact that Bitcoin's 2*SHA256 is essentially self-testing, so even the standard chip-testing circuitry is not required.

Personally, I see no point of discussing advanced electrical engineering stuff without understanding of the basics.

When I was in school it was a common understanding that students with absolutely no contact with any computer are doing noticeably better than students who gained experience of computers via some horrible "home computers" programmed in BASIC with plentitude of GOTOs. There was this seminal paper "GOTO Considered Harmful" written in 1968 by Edseger Dijkstra and published same year by the Communications of the ACM.

I presume that you (and other otherwise educated people) suffer from some version of the above problem: lack of proper basic education in computer architecture. Sometimes I wonder how those people graduated with any real degree (not from a degree mill). But then I have to remind myself that nowadays there are plenty of accredited, real "humanistic/psychological/human-oriented" educational institutions that do grant real degrees.

It is neither too complex or too expensive. The opposite is true: it is remarkably simple and remarkably cheap. The main problem facing the Bitcoin mining hardware manufacturers is that they cannot obtain proper design expertise, neither as employers or as contractors. Simply speaking: nobody really knowledgeable wants to work for/with them.

From my past discussions:

1) extreme short-termism and insistence on pushing contractual terms that are not technically appropriate for the product
2) psychological/social problems dealing with Bitcoin mining entrepreneurs: a strange mixture of pyramid/multi-level-marketing outlook with sectarian/religious fervor (imagine mixing AmWay with Scientology)

ASICminer people were the only ones willing to admit to difficulty hiring/contracting and only did that briefly and to Chinese-only audience.

Well, what I had in mind was not ADD/MUL instructions but addition and multiplication in a commutative field. From the way the posters in this thread use the word endomorphism, I presume that they were vaccinated for it and have immunity.
 
It is more or less a software re-implementation of what CPU hardware does when accessing cache lines. Except that the hardware also does ECC check after read and re-computes ECC before write, even on the cheapest processors. (ECC being an Error-Correcting Code.)

Also this code looks like a good candidate to try use the new BMI (Bit Manipulation Instructions) available in the newer x86 processors.

It is more of a view from your chair, where you don't see the necessity of easy vectorization. As an outside observer, not personally involved in the current battles, I can immediately think of two areas:

1) mining/pool server code is very much likely to benefit from vectorization (possibly variable-length vectors)
2) code embedded in portable/dedicated hardware or otherwise subject to either random hardware faults or intentional fault injection to extract secrets. In that case fixed-length vectors are the savior:
2a) 2-way SIMD where the payload consists of a one new signature and one known signature (from the list of benchmark/test problems). This is the best way to operate in the presence of random faults.
2b) 4-way SIMD where they payload is double of the above, each signing operation duplicated and then verified for equality at conclusion. This is the best way to detect intentional tampering via hardware faults.

I will not break too many NDAs by stating that many of those secret, highly secure processors are internally looking like "Z80 with SIMD" as a way to make the hardware and its programs hard to crack. For anyone working with no NDAs, targeting ARM with NEON is an excellent benchmark for writing and testing their code.

I don't disagree with you, but I've observed that there were many unexplored avenues for further hardware-dependent optimization. In particular everyone seems to be sort of stuck at essentially one representation, where all the words of the a bignum are next to each other in memory. From my experience doing the two matrix transposes (one before and one after the actual EC computation) could possibly be a net gain. The intermediate representation would then have all the least significant words of bignums next to each other in memory)
Thanks for a very interesting data point and its explanation. By necessity I mostly work with for-pay compilers, not with GNU tools.

Okey, let me try to fetch from drafts. I also got PM from "Guest" with what looked like your reply during composition. Post if you want to continue editing it, then I will delete the "Bitcoin Forum" quote below.

Edit: elided 2nd copy of my post now that Theymos had restored the accidentally deleted original.

Well, then don't claim here to learn when what you do is stirring the shitstorm with glee. You'll end up like cypherdoc, they kept edging him on until he lost cool and was quite legitimately censored.

If you can't live without propagandizing at least switch to something more defensible like "ASICBOOST is meh" or "ASICBOOST overpromises and underdelivers" or "How I learned to stop worrying and love the ASICBOOST".
 

I don't want to get into word games. I understand your concerns, but I mostly disagree with emphasis in your statements:
a) stressing human/manual work over machine work
b) stressing verification/validation over automated/algorithmic generation of the high-level code

We are getting into the deep paranoia territory covered by Ken Thompson's "Reflections on trusting trust". If somebody wants to break your high-level code he can always sneak the required breakage into the build toolchain and build process.
 
I think a miscommunication occurred here. I was trying to say that one can use any abstraction, e.g.

a) ..... a1,a2,a3 .....
b) ..... a[1],a[2],a[3] .....
c) for (i = 1; i <= 3; ++i)
      ..... a[ i ], .....

so long as the compiled code has exactly same memory access patterns, regardless of the actual values stored in the a* variables. I am not claiming that the semantics cannot be changed by suitably abusing debugging or optimization flags in the compiler, dynamic linking or thread-local storage, or some other runtime mechanism like paging MMU, SMM, TSX, etc.

Basically what I'm saying is this: assume i is in range from 0 to 1

Wrong:
x) r =a[ i ];
y) if (i) r = a[1]; else r = a[0];
z) if (i) r = a1; else r = a0;

Good:
a) r = i*a1 + (1-i)*a0;
b) r = i*a[1] + (1-i)*a[0];
c) for (j = 0; j <= 1; j++) r += (j == i)*a[j];

Again, I'm assuming no build-time shenanigans like compiling C code with C++ compiler with operator[] overloaded, etc.

Well, you definitely have a point here, especially about ADD/ADC and SUB/SBB, which I used in the past when re-implementing RSA. I also learned very early in school about keeping register pressure low and keeping vector units busy when porting Cray code to cheaper hardware and porting MATLAB prototypes into self-standing C. To me it is so natural that I keep forgetting that library like secp256k1 was not designed for easy SIMD-ification.

eg. hard for the compiler to vectorize:
      ECsign(signature *,message *,secret_key *,nonce *)
      each argument points to a single object of particular type

vs. easy for the compiler to vectorize:
     ECsign(int n,signature [],message [], secret_key [],nonce [])
     each argument points to a vector of n objects of the particular type.

I just looked in the github at the actual header file and have one more question to ask: why not using "restricted" C pointers? In my experience that was one of the simplest and cheapest gains to achieve by switching the C pointers to non-overlapping FORTRAN semantics. It was standardized so long ago that nowadays everyone supports it.

Not it "got centralized". It always "was centralized", "is centralized" and the "central controlling authorities" are resisting the pressure to decentralize.

Also, changes happened and will continue to happen to the protocol. Protocol is being kept intentionally vague, under-defined, long standing bugs aren't getting fixed. This is a normal, regular way to keep the current authorities in continuing control.

Perhaps you've earlier fallen for the past propaganda of "Bitcoin is set in stone" or "Bitcoin is defined by mathematics"?

Now you know first hand how does it feel when you fall hook-line-sinker  for propaganda and become and "useful idiot". This is exactly what you did and yet you persist in spreading the propaganda.

The real way to recover out of it is to admit that you have been had and cease to participate in propaganda operations. Any further arguments that continue to "ASS U ME" (made an ASS of U and ME) will show that you seriously lack introspection.

Edit: start by changing the title of this thread to something less authoritative.

Look, I'm not Shelby Moore. You've spent too much time trading simplistic arguments with him, I will not be easily bullshitted.

Firstly, don't repeat the propaganda number of "20+%" gain. This is a pure marketing bullshit. Tightly coupling 16 pipelines will greatly reduce the maximum possible clocking rate or lowest possible supply voltage. Additionally the yield of useable chips will be lower. From my general observation of modern semiconductor devices the optimum number of coupled pipelines would be 2,4 or 8, hard to tell. 16 would be past "diminishing returns" and into a "diminishing" territory. I've seen full simulation and analysis made for a different chip (not related to mining) and after doing some substitutions I arrive at the first guess of "-2%", i.e. small loss from synchronous 16-way hashing.

Secondly, by the very fact of using "standard deviation" in you argument you show the depth of your misunderstanding. It is hard for me to guess what you don't understand. My two best guesses are:

1) you may be thinking in terms of some unimodal distributions, where in reality they are always bimodal or multi-modal.

2) you continue to use simplistic textbook statistical models in your estimates. "In statistics, a trial is a single performance of well-defined experiment (Papoulis 1984, p. 25), such as the flipping of a coin,..." This maybe a good approximation of one hashing pipeline pass, where one trial block header is processed in microseconds at the cost of probably nano-dollars. Yet you seem to use it completely exchangeably with chip manufacturing workflow that takes months and costs kilo-dollars or mega-dollars.

Please upgrade your arguments to something more professional. Thanks in advance.

Your mistake here is repeating the thinking about "side"s or even "two sides" or adversaries like in a civil lawsuits.

I'm going to quote recent thread by chopstick quoting me from 2012:
I shouldn't have used the word "propaganda", I should've used "marketing" before value. It would not imply less of "taking sides", and more of general "selling".

Look, all your arguments are true, but pointless. Ultimately, Bitcoin mining is about money, and if you reformulate all your argumentation is terms money-gained per money-spend-to-achieve-the-gain-in-the-numerator, you'll reach the same conclusion as I did.

What gmaxwell did with his covert-asic-boost post and BIP was a test balloon smeared with shit. The test was "how many flies can we catch with it" and on this measure it was a great success. It is greatly valuable in discovering who will write about it without having a foggiest understanding of electronic device manufacturing and operation.

I understand that you consider yourself more of a pure mathematician and scholar than a "in the trenches" operator. I'm sorry that I had to tell you that you've felt for the oldest trick in the electronic device manufacturing business. But you've fell so deeply for it that I felt sorry for watching you making a fool out of yourself. Please have some self-respect even if you don't respect me or anyone else here.

The technical value of this asicboost patent is exactly "chicken scratch". It is only valuable as a legal bargaining chip for cross-licensing and as a propaganda device. This is the same for many other patents in the electronic and computer engineering business.

This thread is a good bud sad example of what happens when people don't know what they don't know.

You guys keep writing about ASICBOOST like some godsend. But the best achievable boosting gains are still lower than the manufacturing tolerances in the commercial semiconductor fabrication.

From the AB whitepaper:

	Number of colliding work items	1	2	4	5	8	16
	Gain in percent	0.00	12.50	18.75	20.00	21.9	23.4

So the maximum theoretically achievable gain for a 16-way boosted chip is 23.4% provided that the chip can only work boosted and is no longer capable of mining non-boosted because the 1-way (non-boosted) logic was removed.

Guy Corem of Spoondolies posted his very optimistic estimate that the achievable ASIC gain from boosting is 15% in a chip than can mine both non-boosted and boosted. I consider his estimate to be super-optimistic, in the past he was always giving bombastic predictions.

I'm no longer under any NDA and my experience with semiconductor fabbing relates to the processes now obsolete. The normal commercial manufacturing tolerances then were between +/- 10% and +/- 20%, with the clear trend up: each newer process started with wider tolerances than the previous generation at their inception. So lets make a scientific wild-ass guess that the current acceptable tolerances are +/- 30%.

Note +/- above. Even in the most optimistic assumptions the gain from boosting is within the margins of normal manufacturing variation.

You guys keep making completely wild extrapolations from your initial bad assumption.

The reality is that if the guy at the fab does something like eat phosphorus-rich food (e.g. fish) (Ph is a n-dopant for Si) and neglects the customary crouching when sneezing in the fab, he is apt to more affect the mining chip performance than the ASICBOOST. When some gal at the fab doesn't wash down her aluminum-containing makeup (Al is a p-dopant for Si) before entering the clean rooms at the fab she will have more effect on the mining that what you are discussing.

I can't say that you are spewing bullshit, because the typical bullshitters are aware that they are bullshitting.

But the net-effect of your discussion is quite similar. Please have mercy on us and yourself. We are drowning in whatever you are spewing.

Unnecessarily grim assessment, IMHO.

We are living in XXI century. Machine-generated and machine-verifiable codes are the way to go. In the XXI century even the pure mathematicians are willing to accept machine-made proofs, provided that the "machines" involved are reasonably cleanly designed.

On a related issue:

Why would use of an array preclude side-channel resistance? Use absolutely any high-level abstraction in your code, so long as the memory access patterns (both code fetch and data access) aren't depending on the actual input data, only on its size (which in this case is constant). Ultimately, your code is executed by a Von-Neuman machine which is contained in an array of memory cells.

I actually haven't read your code, just scrolled through it. Personally, I would avoid using raw assembly mnemonics and use processor-dependent intrinsics. It is more work initially (because you have to review the generated assembly), but less work in long-term maintenance.

Forever.

Check the code servicing 'getchaintips' RPC call.

Ask around medical offices doing MRI and other high-end medical imaging procedures. Many of them have their machines down due to various technical and organizational issues. Those machines always have a cabinet-full of FPGAs for sensor data pre-processing. Communication with FPGAs would have to be done through JTAG, as they will not let you modify their hardware in hopes of re-selling it or putting it back to (medical) service.

ASICBOOST whitepaper computes savings purely by counting one-bit logical operations (gates) in a purely combinatorial (fully unrolled) implementation. That's how they arrived at their numbers:

	Number of colliding work items	1	2	4	5	8	16
	Gain in percent	0.00	12.50	18.75	20.00	21.9	23.4

I have no non-bullshit information about any actual implementation. I presume that in a pure-ASICBOOST chip the savings would come from less combinatorial logic. In a mixed, switchable chip (that can mine both raw and boosted) the power savings would come from disabling clock on a portion of circuitry that computes terms that are common under boosting.

Edit: added table formatting