Bitcoin Forum
April 23, 2017, 11:53:20 PM *
News: Latest stable version of Bitcoin Core: 0.14.1  [Torrent]. (New!)
  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 ... 103 »
1  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: Today at 09:14:29 PM
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.

So your stance is that 20% more or less efficiency doesn't matter in the electronics industry.  I have my doubts about that.  As I told you already, I think you are confusing the standard deviation on an individual chip, and the fact that the average over a lot of them, shifts.

I would agree with you that if the technique, used to gain 20% more efficiency, would INCREASE the dropout rate by 20% or more, then, yes, this is not a good idea.  But if you get the same per-wafer dropout (even if it is 20%), and your *average* efficiency increases by 20%, that's something that, in most competitive markets, wouldn't be neglected, I'm sure.  If all else equal, there's no reason NOT to profit from 20% more efficiency.
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.

2  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: Today at 08:45:05 PM
You do understand that the propaganda was coming from the side that claimed to be a victim, right ?
But I agree with you that such a scheme is hardly going to hold up in court, as I outlined: it is too close, in my opinion, to standard techniques of key schedule re-usage.
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:
However development priorities are not very unified, as noted by one observer:

    When I joined this forum I was completely wrong calling the Bitcoin core development team "Bitcoin bunker". Now that I understand the situation better I know that there's no single bunker. There are numerous one-or-two-person cubbyholes that may occasionally form the aliances to shoot at the occupant of another cubbyhole. The situation conforms better to the distributed paradigm inherent in the design of Bitcoin.
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".
3  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: Today at 06:02:42 PM
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.

You seem to confuse "average" and "standard deviation".   You could just as well say that mining with a higher efficiency doesn't make any sense, because the standard deviation on what you are doing is of the same order than your efficiency (for a Poissonian stream).  This is not true of course, because ON AVERAGE you win more, even though your fluctuations are larger than the gain.

Suppose that you win, on average, 10% of the blocks (you have 10% of the total hash rate).   It means you have a probability of 0.1 to win a block.   The standard deviation of "winning one block" is also 10%.  You might say that upping my hash rate from 10 to 15% doesn't make much sense, because the 5% extra is smaller than the variation of my single process chance, 10%.   But of course, in the long term, my revenue has increased with 50% !

BTW, I already explained why I "explain" stuff here: I write out my proper understanding of the thing, and look at the technical arguments against it, to learn from it, which is the sole reason why I am here.
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.
4  Bitcoin / Bitcoin Discussion / Re: Why ASIC BOOST is necessary. on: Today at 04:49:24 PM
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 items1245816
Gain in percent0.0012.5018.7520.0021.923.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.
5  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: Today at 02:52:52 PM
FWIW, I would not expect any non-trivial program to be completely bug free unless it had a very vigorous validation framework around it that was substantially larger than the code itself; or unless it had something on the order of one man day of review per line of code by at least two different persons and at least a moderately good validation framework around it.

There has been a lot of broken crypto code out there used for generating keys, a lot of it due to underlying broken bignum implementations. There is a reason the tests in libsecp256k1 are as extensive as they are. Smiley
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:

but I wasn't considering it for "submission" due to the array use which is not sidechannel-resistant (and I thought it was a "requirement").
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.
6  Bitcoin / Development & Technical Discussion / Re: how long bitcoin core stores different branches for the case of reorg on: April 20, 2017, 10:37:45 PM

Check the code servicing 'getchaintips' RPC call.
7  Alternate cryptocurrencies / Marketplace (Altcoins) / Re: Does anyone have large qty of fpga collecting dust? on: April 12, 2017, 06:31:34 PM
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.
8  Bitcoin / Hardware / Re: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs on: April 12, 2017, 12:41:16 AM
Ok, AB allows for somewhat faster processing of a possible hash by being able to internally come up with a new hash to work on vs getting new work from a pool/server right?

But - since most of the power is consumed when the ASICs actually clock to crunch the numbers, where does energy saving come in? When they are twiddling their thumbs waiting for new work power consumption drops quite a bit. so I would think it rather evens out, no?
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 items1245816
Gain in percent0.0012.5018.7520.0021.923.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
9  Bitcoin / Hardware / Re: [ANN] Spondoolies-Tech - carrier grade, data center ready mining rigs on: April 12, 2017, 12:09:49 AM
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?

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

10  Bitcoin / Bitcoin Discussion / Re: Miner cartel, Bankster cartel, or an altcoin? Your choice? on: April 08, 2017, 05:52:43 PM
Or more simply it was written by Nash who wasn't an experienced coder.

This argument that an expert group (of the global elite or whatever) coded Bitcoin doesn't make any sense. Unless they tried their best to make it look like the code was created by amateurs. Did they try to pin this on Nash's back on purpose? But then why does Nash refuse to talk about Bitcoin when asked about and instead basically answers in a cryptic way by saying gold and silver wouldn't work.

Nash was expert in theory, and had to do the coding by himself in order to keep it secret.

Simplest explanations are the best according to Occam's Razor.
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.

11  Bitcoin / Bitcoin Discussion / Re: Miner cartel, Bankster cartel, or an altcoin? Your choice? on: April 08, 2017, 04:39:18 PM
While a long-standing hypothesis, I don't think it fits.  Nash was too smart to be Satoshi.  There are too many silly ideas at the foundations of bitcoin for it to be invented by a guy like Nash ; unless Nash meant it to be a testbench of ideas, and that the thing got out of hand.
--- 8>< --- snip --- 8>< ---
In other words, for Nash to be Satoshi, Nash would have to be less smart than we think he was, or would have been much less honest and open in his real intentions than Satoshi claimed to be.  In other words, if it was Nash, he created a monster by being stupid, or he did it on purpose and was a bastard.
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.
12  Bitcoin / Hardware / Re: ASIC fabrication tools on: April 03, 2017, 06:24:14 PM
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.

13  Bitcoin / Development & Technical Discussion / Re: C and Posix expert opinion needed: popen, fork, makefifo, signals on: March 25, 2017, 10:04:16 PM
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.
14  Bitcoin / Development & Technical Discussion / Re: C and Posix expert opinion needed: popen, fork, makefifo, signals on: March 25, 2017, 08:50:02 PM
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.
15  Bitcoin / Technical Support / Re: Core 0.14 bug? Wallet becomes invisible on: March 12, 2017, 05:23:54 PM
No, I already said this is not the typical "not responding" situation. Also notice how I said that you can still click on the menu, and the menu opens (see pic). When a window is in "not responding" mode, you can't click anything. Also the fact that I just need to close the window and open it again and it works is not typical "not responding" behavior. I will check the debug later im at the office now.
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.
16  Bitcoin / Technical Support / Re: Core 0.14 bug? Wallet becomes invisible on: March 11, 2017, 12:48:37 AM
What are you talking about? Tightly integrating the GUI to the rest of the code is not a design decision made by the current Core developers. It is a holdover from the Satoshi days when Satoshi originally release Bitcoin as a Windows-only Gui-only software. They have done a ton of work to separate out and modularize everything.
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.
There is no closed source release. What the hell are you talking about? The Core devs aren't out to make everyone's lives terrible. If there were a closed source version that was much better, they would release it. Also, Core dev is an extremely nebulous term, and there really is not a formal "team" that people join.
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:
17  Bitcoin / Technical Support / Re: Core 0.14 bug? Wallet becomes invisible on: March 10, 2017, 11:47:54 PM
Im on Windows 7 64 bit, the CPU is some quadcore from 2008, 8 gigs of ram, average 7200 rpm 2 TB hard drive.

Like I said before, im fixing it by closing the window and opening it again by clicking on the taskbar (notice closing the windows does not mean actually closing bitcoin core and re-opening again which would be insanely annoying)
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.
18  Bitcoin / Mining software (miners) / Re: OFFICIAL CGMINER mining software thread for linux/win/osx/mips/arm/r-pi 4.10.0 on: February 28, 2017, 09:17:40 PM
Is there a way to use CGMiner on a ZedBoard with Zynq FPGA+ARM?
I have the hardware and really want to start mining.
can you give me a hint where to start?
The introductory project and code is in the official Xilinx marketing materials "Xcell journal" from 3rd quarter of 2013.

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.
19  Bitcoin / Technical Support / Re: Brute forcing wallet.dat? on: February 22, 2017, 03:09:12 AM
Had I not found my saved passphrase there is no way I would have been able to recover it. Unfortunately no amount of meditation would help me remember 24 completely random characters.
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.
20  Bitcoin / Technical Support / Re: Brute forcing wallet.dat? on: February 22, 2017, 01:08:21 AM
I don't understand is a line feed not a specific character?

EDIT: NVM I got it. Thank you so much guys for the help. I thought I was going to be sick but now I'm relived.

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.
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 ... 103 »
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!