Bitcoin Forum
February 21, 2018, 09:43:48 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
  Home Help Search Donate Login Register  
  Show Posts
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 105 »
1  Bitcoin / Development & Technical Discussion / Re: Why did satoshi develop bitcoin in windows? on: February 11, 2018, 12:00:43 AM
More notable thing that probably nobody noticed is that Satoshi's hard drive was using NTFS compression, most likely on whole partition. This is very untypical to have NTFS compression enabled on whole partition upon manual formatting.
How would you know this fact?
2  Bitcoin / Mining speculation / Re: SHA256d IC design question on: January 10, 2018, 08:31:13 PM
Your idea about starting at a larger node is a good one, you would certainly want to debug on a cheap process.
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.
3  Bitcoin / Mining speculation / Re: SHA256d IC design question on: January 10, 2018, 08:11:53 PM
I'd like to learn a little more about this transistor level implementation, I'm having a hard time picturing what could reasonably be exploded or minimized in the hash core.  Xor?  It's just flops and wiring otherwise, I would be surprised if the flop was exploded, but maybe - if you have any links to check out, it would be an interesting read.
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.
Code:
a<=
b<=
c<=
d<=
e<=
f<= x + y;
This can be optimized to:
Code:
a<=
b<=
c<= x + y;
d<=
e<=
f<= x + y;
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.
4  Bitcoin / Mining speculation / Re: SHA256d IC design question on: January 10, 2018, 01:12:08 AM
The problem is you won't find a design house willing to work that way.  They have their tool sets and their work flows and they aren't going to diverge from it.  So you will need to buy your own set of design tools and find a team of borderline Asperger's cases to do the transistor design.  
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.

Somebody should really fund a Professor to do the design work under an open hardware license.  One the transistor design for SHA256 is done you just have to bring that into the fab's design tools and optimize for placement.  Conductor losses are becoming dominant at these process nodes so that is where the biggest optimizations will be found.
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.

5  Bitcoin / Mining speculation / Re: Intro: U.S.-based ASIC design group w/ patent on reducing electrical consumption on: December 11, 2017, 02:03:03 AM
OK, brass tacks time.  Try this.  Put 100k of your flops in a ripple counter configuration.  Tie each one's power supply and ground pins to the next with 20 milliOhm to simulate resistive drop in your metal lines.  I'm generously estimating your power rail metal as a big fat 2um run in a 20-50 nm process.  I'm OK with you tapping in higher metal every few thousand gates, but you can't cheat on via resistance.  50 Ohm/via at least.

Now take your 100k ripple counter and clock it at 1Ghz.  Take it's output and build yourself a simple compare - Xor is fine, but you've got to remember the supply resistances in this stage as well.  Compare the 1GHz counter with the output of a second counter running at a non-evenly divisible frequency, say 77MHz.  Then clock this compare result into one final register at 1GHz as well, and for extra points you'll want to buffer the clocks between the two counters - your real chip would be a big ass tree, so no ideal wires in the clock lines.

Tell me how many times you get a false match running at ~300mV noise margin.  The 2^N transitions on your fast ripple counter are going to demolish your rail, easily dropping 150-200mV and completely corrupting any noise margin you think you have, even at this tiny scale.  Then re-sim at 125C.
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.
6  Bitcoin / Development & Technical Discussion / Re: Bitcoin Script language grammar? on: November 18, 2017, 08:09:46 PM
Thanks for your explanation, do you think it'll be worth trying to do it for the ethereum solidity language ??
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.
7  Bitcoin / Development & Technical Discussion / Re: Bitcoin Script language grammar? on: November 18, 2017, 07:02:05 PM
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.
8  Bitcoin / Development & Technical Discussion / Re: Whole Bitcoin Core 0.15 blockchain database on Google Drive on: October 28, 2017, 07:47:35 AM
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.
9  Bitcoin / Development & Technical Discussion / Re: Whole Bitcoin Core 0.15 blockchain database on Google Drive on: October 28, 2017, 04:55:58 AM
Part 11 seems to be missing from the 3rd link.
10  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: October 28, 2017, 04:27:21 AM
From what I can tell there isn't much interest in downloading bootstrap.dat or a pre indexed blockchain. I had my indexed blockchain directly downloadable for a time and I only got a couple hits a week and that was free of charge!
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.
11  Bitcoin / Development & Technical Discussion / Re: Bitcoin core and Bitcoin ABC on the same Linux machine on: September 22, 2017, 05:32:26 PM
Thank you. What is the correct config line in bitcoin.conf to set a different port than 8333? Can't seem to find it.
Later edit: found it, it is port=12345... Smiley
Also, don't forget about "rpcport"!
12  Bitcoin / Development & Technical Discussion / Re: Bitcoin core and Bitcoin ABC on the same Linux machine on: September 19, 2017, 07:01:37 PM
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.
13  Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin blockchain data torrent on: August 22, 2017, 10:59:08 AM
You do realize, that data in torrent are WAY outdated and new node need get lots of data anyway?
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.

It is NOT good way to bootstrap node.
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.
14  Bitcoin / Bitcoin Discussion / Re: [ANN] Bitcoin blockchain data torrent on: August 18, 2017, 07:43:29 PM
This topic can be closed? Some people still asking about thing that is not need for like year.
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.
 
15  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit2x agreement with >80% miner support. on: July 06, 2017, 04:13:27 PM
Now you're seriously offtopic in my opinion (and since this is my thread my opinion gets final word). Complain all you like about the core code (I'm not a fan of its performance either), but do it elsewhere please. Let's stick to segwit2x discussions or I'll start deleting posts.
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.

Even then I still don't get why they are stuck with LevelDB, RocksDB is clearly far superior.

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 .
16  Bitcoin / Bitcoin Discussion / Re: The Barry Silbert segwit2x agreement with >80% miner support. on: July 06, 2017, 04:28:57 AM
Saves at least 10-20G out of a 150G blockchain just by switching.
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.
17  Bitcoin / Development & Technical Discussion / Re: Berkeley Database version 4.8 requirement unsustainable on: June 26, 2017, 08:32:41 AM
@2112:
The issue isn't really one of distribution as much as it's an issue of usage. Reliance upon a library that is antiquated (even by the library's own standards) is pure nonsense. It's akin to a major car company using the seats of the 1923 model of someone else's truck in their 2018 model sports car. Undecided
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.
18  Bitcoin / Development & Technical Discussion / Re: Berkeley Database version 4.8 requirement unsustainable on: June 25, 2017, 03:01:11 PM
Secondly, I'd like to point out that: 3 years and 5 major versions of Core after that quote, we're still stuck with trying to make a version of BDB from 2010 work in a 2017 operating system (despite the fact that both Core and BDB have had dozens of releases since that time); I'd say there's definitely no one "rushing into it".  Roll Eyes
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).
19  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 23, 2017, 06:30:27 PM
I tested the link plus installing it into new wallet on different PC, should work if you have winRAR
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 .
20  Bitcoin / Bitcoin Discussion / Re: **Download the blockchain here, updated regularly ** on: June 23, 2017, 01:48:33 AM
Does anyone require this link anymore? We currently have duplicates, probably not necessary.
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.
Pages: [1] 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 ... 105 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!