Hey Guy!

Please post how you arrived at "15% power savings". What are the components of the practical loss versus theoretical gain? How much worse is the highest achievable overclock or lowest achievable undervolt? How much worse is the useable manufacturing yield?
 
Edit:

One more question I forgot: would ASICBOOST require additional testing circuitry on the chip? Raw Bitcoin mining is essentially self-testing.

I don't buy a "genuine inexperienced coder" postulate. I would only agree with "experienced coder with no experience in C++". I extensively reviewed early Bitcoin code and I see patterns of writing style and design that aren't congruent with a genuine lack of experience in coding.

I hold no opinion on who Satoshi is, but my professional opinion about the code base is (either, equiprobable):

1) experienced programmer or manager from an organization that used older languages (like COBOL, MUMPS, FORTRAN, SIMSCRIPT, etc. ) doing his/her first project in C++;

2) very experienced consultant well versed in multiple languages intentionally doing hard to maintain codebase as a job security move;

And please don't bring "expert groups" into my argument, I haven't postulated this, and you just straw-manning. The "pretend naiveté" is a main selling tactics for the consultants like in my point (2), this isn't some advanced elite strategy, it is a common-folk knowledge independently discovered by many working programmers.

At least the programming mistakes in the Bitcoin design and code can be easily explained: whoever Satoshi was he used services of a software consultant experienced in padding billable hours.

Nearly all problems with Bitcoin codebase are typical of the projects using consultants billing by time. It has all the classical symptoms of intentionally bad programming: e.g. mixing up the abstraction layers of local storage with other, use of particular internal representation of large integers used by particular compilation flags of OpenSSL that is neither little-endian or big-endian, etc.

The current maintainers of Bitcoin Core continue in that fashion: storage engine is still not abstracted, moreover they imported their own fork of LevelDB into Bitcoin Core. And now "mempool" is made persistent by a technique straight from 1960-ies: checkpointing.

So if you are trying to make an argument "Satoshi wasn't Nash because code is too stupid" it is a weak argument because the contra-argument would be "code was actually written by or advised by an extremely street smart and deceptive software consultant". Nowadays entire large consultancy corporations exist through providing such deceptive advice.

Web links to the free tools are included in the references of the textbooks about ASIC design. Every textbook author has their own preferred toolchain that he/she will use. There's no point in trying to use anything else unless you are already very advanced.

Additionally, there's no point in using design tools without access to the models of the actual semiconductor devices that would be laid out. And those models are always secret and proprietary, even for the old, obsolete processes. Nowadays even the intentionally fake, unrealistic models are kept secret by their authors, because those fake models are typically used for grading homework of the students of ASIC design.

Basically you have two options:

1) if you have some formal engineering background education, enroll or at least audition an university level course in your nearest college. They always have free access to all the required design software for their students.

2) if you are autodidact, buy a cheap FPGA design kit. They always come with one seat free license to an almost full design toolchain that is chip-limited to whatever is on your experimental board. Playing with that you will quickly learn whether you have what it takes, or if you are just another wannabe.

You don't have to spend any significant money if you affiliate yourself with some educational or research institution. The "over 100k$" prices are only for for-profit commercial entities, not for amateur dabbler as yourself.

Here are my comments to your elaboration:

1) pipes (both anonymous and named) are a write-blocking calls beyond something like PIPE_MAX bytes. So of you are thinking of using them to avoid long blocks then you will be disappointed. IIRC this is something on the order of 16 kB.

2) while I understand your reservations about multithreading programming, I want to remind you that your architecture just pushes the problem up to multitasking programming. You may be pushing against the maximum number of processes per OS image (something like PROCESS_MAX in Posix.) You may also find yourself to be RAM-constrained in your multitasking solution earlier than in an equivalent multithreading solution. In your solution multitasking is just a more expensive way of achieving multithreading by sharing less resources and having more isolation.

Edit: I don't know the further specifics of your solution. In my case (F5 load-balancer with mixed operating systems: Linux plus proprietary TMOS (Traffic Management Operating System)) the net result of it was that high-end F5 boxes were pushed to their knees by a single rather low-end office Windows boxes with Pentium 4. The F5 solution forced multitasking architecture by their mixture of proprietary software and hardware whereas on Windows I would just use standard multithreaded primitives in the Microsoft-proprietary libraries plus whatever gains were available from the hyperthreading in Pentium 4.

curl (program) has a way of passing arguments through a file instead of a command line. Something like "curl -d @filename ...". I recall being able to easily pass megabyte-long JSON-RPC queries without a problem by writing them first into a temporary file. This wasn't anything Bitcoin-related, it was for a closed-source load-balancers from F5 Networks.

Your architecture certainly looks original, but I probably just don't understand your constraints well enough. popen() is just a wrapper around pipe(), fork() and exec() calls, seems like using them directly would make the whole thing easier to understand.

I'm writing this on a decidedly non-POSIX tablet, so I can't even look up my old notes.

You've described "not responding" as "crash", but it is never a "crash". more like "hang" or "latency". Also, people tend to report "menus working" where in fact the UI thread is responding to the events from long time ago, not the current actions of the users.

My bet is still on nothing wrong being with the Bitcoin-Qt task but some general computer problem, e.g. failing disk or disk controller, bad non-ECC RAM, or one of those "power saving" graphic card issues when the computer has two graphic controllers (one Intel/AMD on the chipset for "low power", one discrete AMD/Nvidia for "high speed") that are supposed to serve same screen, but sometimes lose the mutual synchronization.

The fact that the problem tend to disappear when you minimize and restore the program window would tend to point at the graphic controller problem (hardware or software) e.g. one of those "Movie Color Enhancement" utilities that try to optimize color palettes in each window to make them look "prettier". IIRC 0.14.0 started using window composing within the Bitcoin-Qt window where it dims the most of the window and pops up other unmovable window in the center of main window to display the estimate of how much time is going to take to resynchronize the blockchain. Particularly dumb "Color Enhancement" utilities would then go to endless (or near endless) loop trying to optimize the appearance of Bitcoin-Qt window.

Don't bullshit us. There was a lot of activity but very little action in modularization. And don't blame the tight integration on Windows. It was and it is a conscious decision to integrate everything tightly to have an appearance of nearly-linear development without branches.
I think you are just too naive to understand the open-source poker and how it is played.

Neither you nor I could really know what does Blockstream and their consultants sell behind the closed door and NDAs. I'm positive that the three most visible mining software developers (-ck, kano, Luke-Jr) have private builds available with significantly less interlocking and much faster response times for the paths critical to mining. I see absolutely no reason for this to disappear, this was and is a primary money-making opportunity for both consultants and venture-financed firms.

Here's the link to my post from 2012 about the issue:

https://bitcointalk.org/index.php?topic=94453.msg1046848#msg1046848

On Windows this typically doesn't require anything to be done to fix itself. It is most likely caused by the UI thread getting bogged down and not responding promptly to the UI events.

You can check this yourself by opening the "Resource Monitor" from within the "Task Manager". On the "Overview" or "CPU" tab the "Status" column will show "Not responding" in red instead of the typical "Running" in black. If that's the case then you don't need to do anything for the situation to resolve itself, the UI thread will sooner or later catch up (it may even take several hours if the backlog is immense).

This isn't as much a "bug" as a "design decision". Bitcoin Core is very tightly integrated by design. Properly modularized Bitcoin client wouldn't be so easy to keep under tight control of a single development team. I wouldn't expect them to ever fix it in the open source release. They may have a closed source release without the extra-tight interlocking, the same thing that large miners do for their "bitcoind" daemons. The 0.14.x is much worse in the "not responding" symptom than the older releases, e.g. 0.10.x.

The introductory project and code is in the official Xilinx marketing materials "Xcell journal" from 3rd quarter of 2013.

http://www.xilinx.com/publications/archives/xcell/Xcell84.pdf

Obviously, this was over 3 years ago, it is now competitively obsolete. But it is a good educational starting point for porting the modern mining code.

https://bitcointalk.org/index.php?topic=262195.0

I don't want to discourage you, but I've been to long on this forum to take "completely random" at the face value. Too many people here thought that they have "random number generators", but the real entropy was significantly lower (e.g. under 15 or 31 bits). It has been a common problem and frequent reason of the thefts: it looked random but it wasn't.

Since you've admitted to using Excel I just hope that you didn't use the builtin functions to generate those "completely random characters". In fact, I wanted to encourage you to read this forum and re-check the source of your randomness. In the past people here discussed the flaws in various tools (commercial and free) that purport to generate random numbers.

Yeah!

For password/pass-phrase recovery the key to success is the right frame of mind. In the original btc-recover thread somebody made a good post about how to meditate to get into that state of mind one had at the time of entering that password first time.

Microsoft Windows is particularly nasty with this regard because it is well known that the automatic driver updates may change the behavior of the keyboard/mouse/video card combination.

Only you can really answer your question. Some people cut and paste it directly to bitcoin-qt. Other cut and paste it to a command prompt window using "bitcoin-cli walletpassphrase ..." . It is a common problem for the users of non-US-English Windows that various things typed on the keyboard result in different characters feed to the program. Now that you mentioned a program from the Microsoft Office suite I'm also aware that those programs in particular are known for creating problems by automagically changing entered texts to make them look better: e.g. "smart quotes", auto ligatures (ffi, etc.) and other traps for unwary.

That would be typically related to entering the pass-phrase from the keyboard vs cutting&pasting from a text editor vs entering it from command prompt/shell prompt. It also happens oftentimes when people work with several keyboard layouts and delay lifting the finger off the AltGr/Option key: the first Enter/Return gets ignored.

You may have also physically switched the keyboards between then and now and the new keyboard has different tactile feel, or maybe you cleaned or dirtied you keyboard. This problem mostly happen to the touch typists who don't look at the keyboard and/or screen when typing.

Once you really think about how you typed the pass-phrase you may probably find other variables that you originally didn't notice. I'm glad that you've learned this without paying the price for the lost data and/or coins.
 

If anyone cares and for posterity:

1) I downloaded the files from mega.nz bunch of times to configure and test the new network hardware. I also torrented it between known good nodes. The data checks out correct.
2) It seems to be correct Bitcoin blockchain synchronized with 0.13.2. There's also partially synchronized testnet blockchain.
3) The files contain unmodified 0.11.1 software release for Windows 64 bit. I presume this is an accident, the important executable files are unchanged, there's no way to verify the dynamically generated uninstaller executable.
4) UnRAR decompresses files into heavily fragmented state, unlike the files created natively by the Bitcoin Core which at least makes an attempt at minimizing fragmentation. If you want to really use the downloaded files to save time: defragment the decompressed data before using it.

The reliable solution to your problem is to periodically restart your Bitcoin Core client.

I'm assuming that you have one of those PPPoE or PPPoA services that force PPP session renegotiation every 24 hours if you not renegotiate earlier on your own. In that case the best solution is to write a script that periodically:

1) shuts down bitcoin{d,-qt} using bitcoin-cli
2) forces PPP session disconnect and reconnect
3) restarts bitcoin{d,-qt}

This has been working reliably for many users for years now, they get decent bandwidth and transaction propagation.

Depending on the specifics of your ISP this script has to be either:

a) run at fixed time of day with a short (e.g. 1 minute) pause between disconnect and reconnect
b) run on a rolling schedule every 22 (or so) hours
c) run twice daily on a fixed schedule (or better twice nightly)

The other possibility is to see if your ISP may be supporting mixed IPv4/IPv6 deployment (oftentimes it just needs appending something in your PPPoE login e.g. "you@yourisp.eu" changes to "you@yourisp.eu/ipv6". In that case the PPP session can stay up for weeks or months at a time and oftentimes reconnecting your PPP session doesn't change the assigned IPv4 & IPv6 addresses. The usual consumer-level dual-stack deployments have limitations on IPv4 connectivity but will give you nearly permanent /64 (or /56) of IPv6 address space. Your incoming Bitcoin connection will be then over IPv6.

It depends on the ISP. Many ISPs use CG-NAT ( https://en.wikipedia.org/wiki/Carrier-grade_NAT ) and the lame network control code in Bitcoin easily bans them. Other ISPs use native IPv6 with limited IPv4 ( https://en.wikipedia.org/wiki/DS-Lite ) and again Bitcoin Core can't deal with that. I'm betting that OP was in the 1st group because of the radio-link ISP.

Even with a regular IPv4 ISP the download speed from your IP depends on how many other Bitcoin clients are in the same /16 subnet (or some such, I haven't looked in the at the code recently).

Bittorrent clients typically, when properly configured, have no such limitations and restrictions. If they are subject to limitations they deal with them much more efficiently.

OK, I see the OP removed his torrent.

It seemed to be legitimate Windows RAR file in 41 parts. It was just seeded from a Windows machine through some dicey/hooky radio Internet provider with some misconfiguration somewhere on the link. Now wonder that this provider got recently delisted from NASDAQ.

I did not test anything in the mega.nz link as they always attempt to push some Javascript that attempts to install trojans and/or malware and and/or spyware. From a properly configured machines the mega.nz link just redirects to the "update your browser" screen or simply hangs.

Maybe someone with properly safeguarded Windows in a virtual machine could test the mega.nz links? I don't want to play on my Windows 7 machine, both of the links reliably crash Internet Explorer 11 that is current on patches.

Not profitably for Bitcoin or Litecoin, but for other coins that are minable by the FPGA-s.

To start you have to find out the exact part numbers for the FPGA chips and what kind of JTAG interface is available on the boards (used in testing and verification).

Partially yes. In a sense that complete wearout will happen after, say, 3 years instead of after 2 years.

The main problem I see that when flash devices wear out they tend to fail completely. E.g. you start getting errors, device partially works. At this moment people tend do troubleshooting by doing a full reset by power cycling, and the device never comes up or comes up completely scrambled.

This is in contrast with hard drives that fairly rarely get complete failures. They tend to just develop more and more bad blocks, but the data that was not rewritten is typically still available although the disk will not accept any more writes. The hard drive recovery programs also do tricks like copying everything backwards (from the end to the beginning) that frequently help in recovering data that is not readable the normal way. I haven't seen anything similar available for recovering flash media. On spinning hard drives the standard trick of keeping multiple copies of the most critical files (wallet.dat) works rather well. Just partition the hard drive accordingly with multiple small backup areas. On flash that is rarely successful.

The SD devices maintain their rated specifications only when formatted exactly as the special "SD formatter" utility would do it (it is available on their web site for Windows & MacOSX). And that program only does FAT and exFAT.