Bitcoin Forum
February 25, 2017, 07:42:41 AM *
News: Latest stable version of Bitcoin Core: 0.13.2  [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 ... 102 »
1  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.
2  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.
Yeah!

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

Microsoft Windows is particularly nasty with this regard because it is well known that the automatic driver updates may change the behavior of the keyboard/mouse/video card combination.
3  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.
4  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.
 
5  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 mega.nz bunch of times to configure and test the new network hardware. I also torrented it between known good nodes. The data checks out correct.
2) It seems to be correct Bitcoin blockchain synchronized with 0.13.2. There's also partially synchronized testnet blockchain.
3) The files contain unmodified 0.11.1 software release for Windows 64 bit. I presume this is an accident, the important executable files are unchanged, there's no way to verify the dynamically generated uninstaller executable.
4) UnRAR decompresses files into heavily fragmented state, unlike the files created natively by the Bitcoin Core which at least makes an attempt at minimizing fragmentation. If you want to really use the downloaded files to save time: defragment the decompressed data before using it.
6  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. "you@yourisp.eu" changes to "you@yourisp.eu/ipv6". In that case the PPP session can stay up for weeks or months at a time and oftentimes reconnecting your PPP session doesn't change the assigned IPv4 & IPv6 addresses. The usual consumer-level dual-stack deployments have limitations on IPv4 connectivity but will give you nearly permanent /64 (or /56) of IPv6 address space. Your incoming Bitcoin connection will be then over IPv6.
7  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 ( https://en.wikipedia.org/wiki/Carrier-grade_NAT ) and the lame network control code in Bitcoin easily bans them. Other ISPs use native IPv6 with limited IPv4 ( https://en.wikipedia.org/wiki/DS-Lite ) and again Bitcoin Core can't deal with that. I'm betting that OP was in the 1st group because of the radio-link ISP.

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

Bittorrent clients typically, when properly configured, have no such limitations and restrictions. If they are subject to limitations they deal with them much more efficiently.
8  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 mega.nz link as they always attempt to push some Javascript that attempts to install trojans and/or malware and and/or spyware. From a properly configured machines the mega.nz link just redirects to the "update your browser" screen or simply hangs.

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

9  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).
10  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.
11  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.
12  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

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

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.
13  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 (www.irf.com), 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
14  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.
15  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 https://en.wikipedia.org/wiki/Polyphase_system .

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.
16  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?

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

[1] https://github.com/ayeowch/bitnodes/blob/cb23696fa355c2cddf2fc32a6933e00aabe13e5f/crawl.conf.default#L6
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?
17  Bitcoin / Bitcoin Discussion / Re: Bitnodes Incentive Program on: January 21, 2017, 02:54:26 AM
I'm not sure if Addy Yeow is still following this thread, but I noticed an important change.

My Bitcoin testnet nodes started getting incoming connections from clients calling themselves /bitnodes.21.co/ .

This is a standard signature that was used on Bitcoin mainnet monitoring tools available via https://bitnodes.21.co/ .

Does anyone know the URL to access the equivalent testnet website?
18  Bitcoin / Project Development / Re: Starting a Bitcoin Mine: Hiring the right people? on: January 16, 2017, 07:02:48 PM
Op is based in London so creating mining farm is UK will be a bit problematic due to high energy costs.
I'm going to move/repost something I wrote several months ago in regards to coin mining in London, UK. My original post was in the thread related to the then new Bitmain miner and didn't gather any responses because it happened to be far off the main topic of that thread. Maybe here in this thread we will get better discussion going?

Location - London, I doubt any mining farm could be located there
I don't know anything about this particular company. But I do happen to have some fresh information about the real-estate/property developers in Greater London area. There is plenty of freshly build/renovated residential and commercial locations that are looking for a buyer without any current tenants. Developers are again resorting to having fake occupancy by letting trustable people to live and use the facilities free of rent&utilities. Conditions typically are: be personally known to trusted people in the construction business, be able to move out on a very short notice (few days at most), be trusted and capable of leaving the property in the "as new" condition, don't look and behave like a chav.

The holy grail of the Bitcoin mining is free electricity. Paradoxically, it is easiest to get it in the areas that normally have very high rents and costs of utilities. You won't get it on the regular commercial/residential terms, only as a temporary fallback financed by the developers/bond holders/speculators. Certainly, you won't find them advertised anywhere.

From my broader experience I'm pretty sure that such conditions aren't limited to London, UK. So keep your eyes open for opportunities like that in the city near you.

Again, the above was a general information, not specific to any particular offer discussed above.

In the months passing since then I have one more data point: certain woman artist moved her ceramic workshop from far-our rural England to rather prestigious London location, including rather large custom electric kiln. She had lowered her monthly expenses taking advantage of the promotional deal offered by the property developer management. Obviously art studio isn't industrial-size coin mining, but is quite close as far as practical incidentals.
19  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Litecoin - a lite version of Bitcoin. Launched! on: January 03, 2017, 01:19:27 AM
You could be correct.

However, will you be the first to congratulate them if they do. Interesting observations though...what will they say about that?

Lets wait and see.
The question is "How could you tell if they did or did not successfully deploy it?" Can you just trust their say so? The current official Litecoin client has defect/problems/bugs related to network and hash-power splits. The Litecoin Core development group doesn't seem to be really interested into looking to this problem.

Anyone who already has a working Litecoin client can just quickly run a second copy on the testnet, just start it with a "-testnet=1" flag. The required disk space is just over 1GB and the bandwidth load is minuscule. There's enough seed nodes to download it quickly, but the problems of not propagating transactions and newly mined blocks will be obvious. It isn't like to reproduce the problem one needs some sort of complex environment. Just start a copy and wait till it hangs while having many open connections. To speed up the bug reproduction one could simply shut it down cleanly after downloading couple of months of blockchain and then try restarting the synchronization. The bug (or bugs) are very obvious and not hard to reproduce.

Likewise, to see the mining hash-power split one doesn't need dedicated Litecoin ASIC mining hardware. Even a single core on a multi-core CPU could theoretically produce blocks at the expected rate of about 2-3 minutes. But they just won't propagate as the most peer to peer connections get stuck in open state but "UNKNOWN" sync height.
20  Alternate cryptocurrencies / Announcements (Altcoins) / Re: [ANN] Litecoin - a lite version of Bitcoin. Launched! on: January 03, 2017, 12:06:55 AM
Litecoin Core 0.13.2 with SegWit coming out very soon...
Personally, I have doubts that you (plural 'you') will be able to deploy it successfully.

I'm basing this on my observation of Litecoin's testnet. It has again split into many different branches despite all of them using the original, unmodified, official Litecoin code. Nearly all nodes run 0.10.*, with majority at 0.10.4. The last major split of this type happened just before Christmas, at a height of 1013820. Right now the nearest one can get to 'official' main branch is at 1013879. The testnet hash rate stands at pitiful 152 H/s, yes, just over one hundred hashes per second.

I always espouses the opinion that the general traffic level and health on the testnet are a good indicators of the future health and traffic levels on the mainnet. Less than hundred blocks were mined over the holiday period on the testnet. What this really means is that nobody is doing any significant development, testing or deployment of the new Litecoin-related software and businesses. Even a single core decade old Intel/AMD CPU can sustain over 1 kilohash per second.

The problem of testnet splitting was reported here by me in the past and surely many more people are aware of it. The last time the Litecoin core developers simply decided to mask it by deploying a simple hidden mining pool backed by the ASIC miner. It wasn't a real solution to the propagation bugs, but at least masked them well enough to allow resumption of global Litecoin testnet operation. But the underlying bug clearly wasn't fixed since 0.10.2.2 days which anyone can observe today.

That "very soon" cannot be taken as a serious promise from a developer.
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 ... 102 »
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!