Bitcoin Forum
March 23, 2017, 04:29:56 PM *
News: Latest stable version of Bitcoin Core: 0.14.0  [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 / 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.
2  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:
3  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.
4  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.
5  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.
6  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.
7  Bitcoin / Technical Support / Re: Brute forcing wallet.dat? on: February 22, 2017, 12:32:53 AM
That makes sense. I believe I created the password in excel and copied it over to my BTC wallet but how do I enter this into the passphrase of my bitcoin client?
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.
8  Bitcoin / Technical Support / Re: Brute forcing wallet.dat? on: February 22, 2017, 12:01:02 AM
The issues is it is indicated that a line return character was the missing character. How would that even be entered into the passphrase? Really appreciate any help!
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.
9  Bitcoin / Bitcoin Discussion / Re: i make a torrent with bitcoin blockdata update to 2017-2-12 on: February 21, 2017, 10:05:39 PM
If anyone cares and for posterity:

1) I downloaded the files from 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.
10  Bitcoin / Technical Support / Re: Dynamic IP change - incoming connections drop on: February 19, 2017, 07:47:55 PM
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. "" changes to "". 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.
11  Bitcoin / Bitcoin Discussion / Re: i make a torrent with bitcoin blockdata update to 2017-2-12 on: February 15, 2017, 10:08:58 PM
You can't FINISH the download with 5800 sources ... for the blocks ?
It depends on the ISP. Many ISPs use CG-NAT ( ) and the lame network control code in Bitcoin easily bans them. Other ISPs use native IPv6 with limited IPv4 ( ) 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.
12  Bitcoin / Bitcoin Discussion / Re: i make a torrent with bitcoin blockdata update to 2017-2-12 on: February 15, 2017, 08:47:10 PM
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 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 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 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.

13  Bitcoin / Mining speculation / Re: X ray or mri machine I want to use for mining on: February 08, 2017, 03:05:39 AM
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).
14  Bitcoin / Development & Technical Discussion / Re: Running a node on a low spec notebook computer. on: February 01, 2017, 10:58:59 AM
Could this be mitigated by copying (most) new blockchain data to the cheap flash from a desktop machine?
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.
15  Bitcoin / Development & Technical Discussion / Re: Running a node on a low spec notebook computer. on: February 01, 2017, 03:30:20 AM
You are suggesting that I use an USB stick rather than an SD card, and thanks for that observation. USB sticks are easier to use and to store, so that looks to be the option to use. Can you see any problems in keeping the blockchain on a USB stick?
Bitcoin chain storage using database engine is putting high stress on the flash storage media (SD, USB, etc.) in terms of wear and tear. It is close to worst possible access pattern: write-ahead-logging causes many rewrites with almost no reads. Cheaper flash media would fail before you complete the whole blockchain synchronization.

The same thing was tried by somebody else on cheap Dell laptops with cheap SSD in the days when the main blockchain database was still Berkeley DB. They would reproducibly permanently fail during initial synchronization. The current LevelDB is less bad than BerkeleyDB, but still far from being flash-optimized.

To be really reliable you would need two separate hardware storage pieces: one for the main OS and important files like wallet.dat and one for constantly rewritten data that is really throwaway: blockchain storage and log files.

Edit: One thing that I forgot about: many SD card media have controllers that are internally optimized for FAT or exFAT file systems and don't perform well when formatted with NTFS. NTFS security and reliability features are pointless for blockchain storage. This is one more reason to have split devices when specifying cheap flash storage media.
16  Bitcoin / Hardware / Re: 55nm Bitfury chips - Direct 220V Project on: January 27, 2017, 09:11:39 PM
I think , that power part of the design is not going to be bottleneck , here.
The SPI will be pain in the ass, You will have to use some kind of level shifting.
RPI is too much of  a mess for my taste too
Well, Bitfury (corporation) and Punin (person) promised to release the specifications for their communication controller/level shifter/differential transceiver chip.

Bitfury Designs released under CC-BY-SA

Maybe sidehack has some information in English now? I vaguely remember seeing some posts in Russian that are now deleted, and I'm only quarter-literate in Russian.
17  Bitcoin / Hardware / Re: 55nm Bitfury chips - Direct 220V Project on: January 27, 2017, 08:32:46 PM
One thing is for sure it's far from 2) there is no fun in standard designs (just copy paste and recalculate), but the chip is also not standard Wink
No coin miner is ever standard. The main fun is that they invalidate all standard design flows: they either lead to failure or vast over-specification and under-performance.
See my previous post - the chip speed and consumption depends on the clock which is internally generated and voltage dependent, so we have this for free
As far as I know several people tried to use the internal self-clocking and reported problems with them: not always starting reliably and humongous jitter. My experience (not with mining, but with somewhat similar digital-but-nearly-analog chips) is that you are better off forcing your own external clocking and very frequently run short test mining jobs with known answers (like once every second feed the chip a job that requires just a few increments to find the golden nonce).
For protection against spikes a choke and inrush current limiter before the capacitor should be enough: ~400 chips string may survive spikes up to 600V DC, but then the current is 3.5A, so if limited to 2A the transistor should take that load and just in case planning to add a 400V transil in addition.
This is where I disagree with you the most. The failure modes of MOS devices are really strange, silicon has negative temperature coefficient and is prone to creating hot spots, where the device fails way below their normal rated specifications when the dI/dt or dV/dt was too fast. Hopefully you'll get your 55nm Bitfurries really cheap so you won't regret skimping on the safeties. But speccing and acknowledging the need for parallel transil is a good start.

My school had a program sponsored by International Rectifier (, we could burn power semiconductors for free (provided that we documented the conditions of the burn) and I still have some fond memories from that time.

I've seen your "back of the envelope" calculations and basically I suggest that you get a bigger envelope and make some more calculations. In particular, don't always assume that Vpeak/Vrms = 1.4, it varies widely with the load.

Or maybe just want want to go for the shock value and use one farad capacitors in your ripple filter, the ones that are used by the bass-heavy car audio enthusiasts.  Wink
18  Bitcoin / Hardware / Re: 55nm Bitfury chips - Direct 220V Project on: January 27, 2017, 05:01:15 PM
To both 2112 and RadekG

The idea is exactly the opposite - use simple diodes rectifier and transistor current limiter.
I am not a noob and know how the rectifiers work and in the calculations above 220 * 1.4 is simplified for  220 * sqrt(2).
Many people said that it won't work and that's why this (crazy / hobby) project - to prove it does!

I have a working design at 24V DC and the built-in current mirror in the chips is working and balancing (almost) perfectly the voltage. I have made extensive test with the chips previously and this project will be a miner around the 55nm Bitfury chips, not a standard miner design. The chip survives 1.5V with proper cooling and it's voltage drop depends mostly on the current passing through it.
So transistor current limiter should be more than enough and 1.5V per chip is 420V AC, which won't happen and at that voltage the current is over 3A, while i will limit it to 1.5A or 2A max. This equals to about 0.88V per chip, because it's internal resistance when hashing is 0.44 Ohms based on my tests.

There are two other problems concerning me - the SPI speed (my next post) and the ripple/capacitor size (the next next post)
Yeah, it will most certainly work, when designed correctly. I'm still perplexed why you were concerned about few percentage point of RMS voltage variation (220-235V or 205-265V) while your main concerns should be ripple and protection against spikes.

Ripple itself on a single-phase system would be around 40% (25%-50% if I remember correctly) unless you drastically over-design the ripple filter and your rectifier diodes conduct only during few percents of the mains cycle. I'm unclear what is the purpose of your design: (1) show that it is possible using ridiculous over-specification or (2) an experiment in a proper power electronics design that could be practically scaled up and deployed later.

In case (1) you just don't worry about inductive spikes in the mains voltage because you ridiculously over-specified capacitors.

In case (2) you have to have proper protection against spikes. I don't have specific information about Bitfury's chips, but in metal-insulator-semiconductor chips the over-current protection is typically not enough. The breakdown is not only thermal, it involves electromigration of metal over insulator and insulator under metal. Electromigration is both irreversible and cumulative. In normal industrial practice you will need parallel over-voltage shunt to extinguish the inductive spikes coming from the mains. Relying on over-current protection is only acceptable for bipolar-junction devices where the junction breakdown is reversible and non-cumulative.

In case (1) you just don't worry about power factor and accept that the diodes conduct only during top few percents of a cycle.

In case (2) you'll have to use 3-phase power and polyphase rectifier design to have acceptable power factor and diodes that conduct current around 60 degrees of the 360 degrees cycle.

Again, I don't have a specific knowledge about Bitfury's chips and their communication protocols, but some power electronics designs deal with 100% ripple by resetting the devices at 100Hz or 120Hz during the zero-crossings of the mains power. It probably wouldn't pertain to Bitfurries, but you still may consider modulating your mining clock rate during each half-cycle of the ripple. Over-clock when the chip are over-volted on the average and under-clock when the chips are under-volted on the average. The required additional power in the controller is next to nothing when compared with the power losses in the full, actively stabilizing regulators. Adjusting the clock rate several hundred times per second shouldn't be a problem for properly designed controller.

I'm sorry my first response took you for a noob. I simply didn't consider the case of (1), a design like one would do to settle a bet. In the past I had to deal with many people who were digital design experts but relatively ignorant in power electronics design. They would advocate type (2) designs with flaws obvious to anyone who had to experience beyond stabilized/regulated benchtop power supplies.
19  Bitcoin / Hardware / Re: 55nm Bitfury chips - Direct 220V Project on: January 27, 2017, 12:13:35 PM
I don't think that you understand how a rectifier works. 220V is an RMS voltage (root mean square). This means that unloaded bridge rectifier produces on output 220 * sqrt(2) or about 311V. The output under load will be lower depending on the exact design of your ripple filter.

You need to actively monitor angle of conduction in the rectifier to operate you mining string safely. This means that you can't use diodes in the rectifier but SCRs (thyristors) and actively control when to turn them on in each cycle (not difficult at 50Hz or 60Hz). For experiments (to learn) you can use diodes in the rectifier and an artificial resistive load (like incandescent light bulbs) in parallel with your string of chips.

Have fun!

Edit: In practice people using unregulated rectifiers use multi-phase rectifiers (typically 3 or 6 phases), not a single phase rectifiers. See comments about rectifiers in .

Edit2: For fun (to play and learn) use a welding rectifier (with a transformer or an auto-transformer) for testing. Just remember to disable the arc-start circuitry, the one that briefly produces higher output voltage to make it easier to spark the arc for welding. You will need less chips in your string.
20  Bitcoin / Bitcoin Discussion / Re: Bitnodes Incentive Program on: January 22, 2017, 05:13:26 AM
Its a config option[1], did you happen to log the IP?

The crawler maintained by Bitnodes connects from these IP addresses:,, 2a01:4f8:212:3b1f::2

Thank you for your suggestion. I had the firewall set for logging only blocked connection attempts. I enabled logging of the successful IPv6 connections and I see 2a01:4f8:212:3b1f::2 as the source address. So the connections are coming from the same monitoring server. They are kept open for exactly one minute and one second.

Do you happen to find the URL for seeing the testnet results?
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!