How would you know this fact?

Edit: restored message from crash
The alternative theory is that he was an "experienced programmer" with an equivalent of black-belt in billable hours padding. That doesn't preclude being "good programmer", just puts in the background to the primary goal.

Yet another alternative theory is that initial coding was done by Satoshi's contractor, not Satoshi himself; and that later on they split for whatever reason.

Those then segue to the whole group of theories that Satoshi was an employee of some government spying agency. Those theories further split into two subgroups:

a) intentional covert work for which Satoshi was normally paid
b) after-hours personal project that unexpectedly grew, possibly affecting negatively his normal duties.

There's nothing to debug at the transistor level that is process-independent. In fact, even the transistor model changed from BSIM3 to BSIM4-family when you move from cheap to expensive processes.

The general topology of the models is already well known and open sourced:

http://bsim.berkeley.edu/models/

What is secret? The parameter values of those models. And even if you use MOSIS/Europractice or similar program you won't be able to publish those secret values. Without those you can't optimize in any sensible way beyond "sandbag the hell out of it and keep your fingers crossed". KnC did that already.

Here's the example of what can be optimized with the transistor-level knowledge.

SHA-256 has 64 rounds that when unrolled have values that once computed have to be used in 16 different places (fanout of 16). For this example lets simplify and assume that there are only 2 inputs and 6 outputs.This can be optimized to:The optimization is that the same value is computed twice, but in different physical locations on a die and the signal needs shorter routes from the source to the destination. Here's more in-depth explanation:

https://en.wikipedia.org/wiki/FO4

Note that the above optimization is the opposite of the ASICBOOST "optimization".

We know that recent Bitmain chips are have capability to work both in regular way and boosted with ASICBOOST (with theoretical maximum of about 25% savings). We also know that when used in the boosted configuration they need to be clocked much lower and have lower overall performance (and probably lower yield of chips that could work in boosted modes).

If Bitmain was capable of accurately simulating their chips they wouldn't waste their resources on that exercise because 25% is lower than the normal manufacturing tolerances on the process nodes they were using. Transistor-level simulation is nowadays more accurate than the manufacturing variance and one could actually simulate the performance at the various process corners.

From the above we can deduct that they don't have any sort of transistor-level design, they just use standard cells and sandbagging the design with wide safety margins. That is the same thing that KnCminer did years ago.

The other possibility is that Bitmain did implement their chips dual-capable (both boosted and un-boosted) for some non-technical, political or personal reasons. But that would mean that their chips are even less optimized than they could be without wasting space on the unused boosting logic.

This is where I disagree, people are just looking for a wrong kind of design house. They need to look for designers experienced and interested in mixed-signal and power-electronics designs. This is significantly different than the predominant industry practice in digital logic design.

Technically there are 3 main points where Bitcoin mining chip differs from the typical modern digital IC:

1) SHA-256D is practically a fully self-testing circuit
2) SHA-256D has very high signal toggle rate (0.5, only 3dB below the theoretical maximum of 1.0 for a ring oscillator)
3) there are practically no external design requirements (like timing closure) the chip is 100% limited to either thermal/power (when over-clocking) or self-switching-noise (when under-volting)

The standard tool chains used in digital logic design fail to produce efficient designs with the above requirements:

1) heuristic layout optimization algorithms fail to converge on a design where each bit of the output depends on each bit of input, so the designers force round unrolling to achieve convergence
2) the methodology is mostly designed for timing-closure or test-driven-design, when this is completely not an problem here
3) the approximations made by the toolchains are very inaccurate in the interesting problem space (very high toggle rate and no timing demand whatsoever)

The end result is that standard tools produce designs that are way too conservative in terms of individual reliability of gates and flip-flops: they are way too reliable at the local-logic level and then trade this off for noise tolerance on the very long and high fan-out interconnections.

Well, I haven't spoken with a Professor recently, but I did in the past. From that experience I can surmise that work on a Bitcoin miner could be a career-limiting move for a scientist in the current prevailing climate at the engineering schools.

If you are going to ask around here are the two good questions to ask:

1) why nobody considers plain old serial adders/subtractors for the most common operation in SHA-256D? One can add two 32 bit numbers with a few XOR gates and a D flip-flop with absolute minimum of power spent. It will just take 32 clocks, but who cares? Why such an obsession with parallel adders and complex carry-look-ahead logic when there's no real timing constraint?

2) why nobody considers the old trick of using differential logic (like ECL vs TTL) when the signal toggle rate is at 50%? The complementary logic gives great power saving provided that the toggle rate is much less, the closer to zero the better. This is of
no benefit here whatsoever.

So if you guys are looking for either commercial design houses or semiconductor design professors avoid the mainstream. In addition to the two categories above I could also suggest asking about past experience with GaAs or other exotic processes, which exercised less explored corners of the design mind-scape.

Remember, BitFury's original design may have been done on a kitchen table or in a garage, but they did not unroll and decisively beat all the experienced CAD-monkeys despite using much older fabrication process.

I'm curious: what are you trying to show?

100k flip-flops in ripple counter configuration? I presume that by ripple counter you mean "asynchronous divide-by-two counter". When connected serially that would be a divide by 2 to the 100,000 power. This doesn't make sense, most of the flip-flops would be constant during the lifetime of the universe.

Then what would that be? 100k of divide-by-two circuits in parallel? What for?

Then what is the the point of comparing two asynchronous counters clocked with two different clocks, each of which presumable registered and compared in parallel?

Could you please describe your benchmark design with less ambiguous language? Maybe something that could could be described with just fingers of one hand? And you can even assume that I have less than 5 fingers.

You've piqued my interest, but your use jargon is overwhelming to the point of sounding like baloney.

Thanks in advance.

Yeah, with Solidity the context-free grammars are the proper tool-set to for the problem domain.

You'd really will have to discuss this with your scientific advisor at your school. They will need to help you select a project with the proper difficulty level for your school and your degree. My advice is: prepare a palette of possible projects, some too trivial (like your original idea), some too complex, and have have a discussion with the a teacher at your school who knows you and who will grade your coursework.

The context-free grammar is trivial, just a concatenation of lexical elements (alphabet symbols). All the expressive power is contained in the context (in this case, the contents of the stacks). It is equivalent to a simple RPN (reverse-polish notation) calculator, it doesn't even use parentheses for disambiguating the order of operations.

Since you've mentioned "university course": the formal languages aren't a good tool to analyze simple stack machines like the one in Bitcoin. You would just waste time trying to analyze it at this level. Search for another, more productive, subject for your coursework.

OK, it seems like all parts are available now for a total of 131.62GB. Google seems to be throttling download to below 100 megabits per second, so I get the ETA of over 3 hours. I'll post again when its done, but otherwise it looks good: JDownloader recognized all 9+1+2 parts, correctly recognized their sizes and availability.

Maybe not as fast as that "axel" mentioned by the other poster, but otherwise seems flawless.

Edit: OK, I forgot about this download. It finished properly, uncompresses properly without password, there wasn't any strange files in it and the Bitcoin client started off this directory properly and resumed syncing without problem.

Also a reminder: decompression utilities restore the files in a fairly fragmented state. Defragment the uncompressed directory to improve overall performance.

Part 11 seems to be missing from the 3rd link.

The lack of interest you observing is probably related to your choice of protocol (GNUtella). Bittorrent is way more popular and I could nearly always seen somebody downloading the torrents that are published in various threads here. Currently there are about six leechers in the swarm. I never bothered to keep accurate statistics, but I would estimate that my old computer would push around 1TB (terabyte) per month in various Bitcoin torrent throughout this year. My statistics are very approximate because that old machine also seeds other things, but Bitcoin torrents are by far the biggest and nearly constantly active.

Also, don't forget about "rpcport"!

Guys, Linux is a multiuser system.

Just create additional user accounts, one each for each coin. They won't step on each other files. The only thing you will have to worry is to set each of the Bitcoin forks to run on a separate network ports, because each of them will try to claim ports 8332 and 8333 for themselves.

If you are thoughtful about setting up user permissions you will be safe even if you accidentally install trojaned software, because they will have no access to each other wallets.

No need to play with tar files or other non-default installation methods.

Same thing is true for Windows and macOS.

So what? It is and it forever will be a proper subset of the valid data. This torrent is sufficient to reliably trigger bugs in certain popular/cheap flash storage devices. This alone would make it an useful test case for at least decade, maybe more.

Also, there are (non-English language) papers that use this torrent for performance comparison of various file systems, alternate storage engines and file/partition layouts.

This is just your personal limitation that you can't or won't understand why separating over-the-WAN download from over-the-LAN initialization is and will be useful troubleshooting and testing tool.

Please don't close it. Lots of people with unreliable hardware or network problems are still better off downloading separately from initializing the blockchain storage.

There are many people with non-flat-rate network hookups or with over-the-radio hookups with shared IPv4 addresses that continue to download the torrents from this thread.
 

I hope you'll not delete my post. The reason why technical arguments are important in a political discussion is that they are the simplest way to do distinguish between empty politicking and true long-term planing. Even non-technical people can understand those arguments.


This is the type of gang-warfare argumentation: LevelDB-s contra RocksDB-s.

It is my understanding that -ck was involved in the Linux kernel development. Long time ago Linux was mired in the internecine warfare of various gangs of fanboi-s for the various file systems. The strategic choice wasn't to choose one over the other, it was to implement an abstraction layer for any file system underneath: https://en.wikipedia.org/wiki/Virtual_file_system . That's because there isn't a single universal best file system, there are however best filesystems for various usage scenarios.

The same approach is the correct one for any Bitcoin client implementation: there is a need to implement an abstraction layer(s) for the blockchain and transaction storage. And remember: mempool is also a database, although rather trivial.

Some supporters of segwit2x (and other proposal) make political arguments about decentralization of Bitcoin client development. It could be fairly easy to see if they really support decentralization by asking them about their stance about abstracting the storage engines used by the Bitcoin clients.

The rest of the technical arguments will be in a parallel thread: https://bitcointalk.org/index.php?topic=2006262.0 .

No way. Blockchain isn't stored in LevelDB. It is stored in raw data files (blk*.dat) and raw undo files (rev*.dat). LevelDB is used only to store indices into those raw files. "Just switching" wouldn't change the situation much, it takes rather substantial rewrite to change the storage engine in Bitcoin Core.

What a dumb comparison!

Bitcoin is, for better and for worse, effectively married to BerkeleyDB. It is used to operate on the keys stored in the wallet.dat. It will have to be supported probably forever, at least in the read-only mode, to safely import the content of legacy wallet.dat into some more modern storage layer that is both better designed and easier to integrate with.

Dumb fanboism and upgrade treadmill is a job safety trick that the open source people learned from the best ones in Redmond and Cupertino. Not that BerkeleyDB is perfect, but it is stable, and will have to be supported practically forever, even if only in a separate legacy import module.

The BerkeleyDB is a special case for compatibility of their binary files. Having the correct version of source code doesn't make the binary files fully compatible. IIRC BerkeleyDB intentionally stores somewhere a hash of concatenation of sizeof's of certain structures. That hash value is very dependent on the exact compilation flags and other details of the compilation environment. Since the official Bitcoin Core client is not built in the default environment but in Gitian, the default BerkeleyDB (utilities and shared libraries) available in the Linux distribution will not be fully compatible with the one build under Gitian.

To achieve full compatibility with the user's code the Bitcoin Core distribution should probably distribute their own internal Gitian build of BerkeleyDB (utilities and archive libraries) in a separate, optionally downloadable file. Single zip file would do for all platforms built with the Gitian, it is of somewhat limited interest, only for a subset of developers.

Trying to operate on BerkeleyDB binary files with the default shared library and default utilities creates some hard to understand and debug special cases/problems in the 3rd party software. The number of hidden ways to shoot yourself in the foot is bewildering. Even before Oracle acquired them SleepyCat made some unusual decisions in their design. My best guess is that instead of binary compatibility their optimized for minimum size of the executable code.

Trying to undo those SleepyCat decisions would probably require maintaining a separate fork of BerkeleyDB somewhere in the Bitcoin Core's source tree. This would somewhat parallel the situation with LevelDB, where separate fork is being maintained to improve its ACID resilience from hardware/OS crashes.

In summary, I agree with the decision to "proceed with caution". I definitely think that using the distribution's default build of BerkeleyDB is not the "best" way. The Linux distributions (or MacOSX builds) are made that way to optimize/minimize total disk and memory footprint of the entire distribution. Bitcoin Core is such a special case that for the sake of safety it is better to optimize for another goal and don't rely on the pre-distributed code (source and binaries).

Yeah, I can confirm it "works", i.e. downloads in full and restores correctly.

The question is "how much effort is required to use it on a clean computer, especially Windows?" When somebody doesn't already have Google Chrome and payware RAR utility this isn't so easy.

Depending on the country the attempt to use of directory-level Google Drive link in Microsoft Internet Explorer one ends up with either a hang (described above) or a prompt to upgrade browser.

I don't know if payware RAR utility is smarter, but the freeware unrar restores those directories in a heavily fragmented state. It doesn't make sense for anyone to pay for full RAR license (or lookup the ever-popular cracks) when all that's required is a one-time uncompressing. With heavily fragmented store Bitcoin Core client works much slower then when it would do the download itself.

Yeah, but it makes everything go much faster, especially for users of the ISPs which don't have fully routable IP addresses but have to use to use CG-NAT-ed shared IP addresses. Google Drive doesn't seem to do per-IP throttling unlike e.g. Mega.nz .

Yours has a distinction of actually working. The one posted lkloon123 don't seem to work. They seem to hang on: Preparing download: zipping 1 file: progress circle gets stuck below 25%. In a dedicated Google Drive download utility they show as "files offline".

So maybe keep your until somebody confirms successful use of the other links?

Edit: Further research shows that barto123 posted hyperlink to a file, but lkloon123 posted link to a directory of subdirectories (named with a date) that contain the actual RAR files. Google Drive must have different special cases for different browsers. I managed to start download of lkloon123's post by starting it in "Google Internet Explorer Chrome", pausing the download and then copy-pasting the end-file link to a browser not approved by Google.

Pain in the neck, but it could be made to work. I'll update one the RAR download finishes and passes verification in unrar.