Bitcoin Forum
June 26, 2024, 01:19:05 AM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: [1]
1  Other / Beginners & Help / Re: Building BFGminer with --eneble-cpumining (tip) on: December 05, 2013, 08:02:16 AM
Stop. You shouldn't be mining with cpu, it'll probably die before you get 5$ worth of ltc.
Unless he is also aware of that for obvious reasons and is doing it for the fun or educational purposes, in which case a more constructive answer would be appreciated.
2  Bitcoin / Development & Technical Discussion / Re: Errors compiling BFGMiner under Windows (MinGW 4.8.1) on: November 25, 2013, 03:09:38 PM
New fixes by Luke-Jr fixed this problem somehow.
Thanks Luke!  Wink
3  Bitcoin / Development & Technical Discussion / [SOLVED] Errors compiling BFGMiner under Windows (MinGW 4.8.1) on: November 22, 2013, 03:58:26 PM
Hello,

I'm having a hard time compiling bfgminer under Windows x86 and x64 environments with MinGW 4.8.1.
There are a few things that are now a bit outdated in bfgminer git's windows build instructions. But anyway, here's what is going on:

1. mingw-get-inst-xxxxxxxx.exe is no longer maintained, although you can still get a copy from different places on the net.
The new version is mingw-get-setup.exe, which I personally find worst than the previous installer, minor detail anyway, I still went ahead and installed exactly as instructed, through mingw-get-inst-20120426.exe.

2. From there on, I followed every step of the instructions without a hitch... until bfgminer compilation itself.

3. Next step:
Code:
CFLAGS="-O2 -msse2" ./configure
outputs these errors as a result:
Quote
checking for pthread_cancel... no
checking for pthread_create... no
configure: error: Could not find pthread library - please install libpthread
 Sad

4. Now, getting pthread installed in MinGW... (not mentioned in the current build instructions)
Code:
mingw-get install pthreads
OK, this does the trick and the configuration is now able to proceed.

5. Now onto making...
Code:
make
...returns several errors related to missing header files.
In the 10+ times I tried compiling this program, under several builds of Windows, both x86 and x64, I have had this happen every time and not once is it mentioned in the build instructions, maybe something changed in the code since then, I don't know. Example:
Quote
miner.h:31:22: fatal error: blkmaker.h: No such file or directory
 #include <blkmaker.h>
Huh
blkmaker.h is located under bfgminer\libblkmaker, this is getting weirder by the second.

6. At this point I start adding libraries to the make command:
Code:
make CFLAGS="-Ilibblkmaker"
Despite that, it still gives me the finger a few steps bellow:
Quote
 CCLD   bfgminer.exe
bfgminer-miner.o:miner.c:(.text+0x1755d): undefined reference to `llround'
bfgminer-fpgautils.o:fpgautils.c:(.text+0x2ab8): undefined reference to `lowl_usb_attach_kernel_driver'
bfgminer-fpgautils.o:fpgautils.c:(.text+0x2bc4): undefined reference to `lowl_usb_attach_kernel_driver'
c:/mingw/bin/../lib/gcc/mingw32/4.8.1/../../../../mingw32/bin/ld.exe: bfgminer-fpgautils.o: bad reloc address 0x0 in section `.data'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [bfgminer.exe] Error 1
make[2]: Leaving directory `/home/Administrator/bfgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Administrator/bfgminer'
make: *** [all] Error 2

7. The build instructions mentioned libusb as optional, but it seems is now mandatory.
After installing libusb, I get another missing header file:
Quote
lowl-vcom.c:53:22: fatal error: usbioctl.h: No such file or directory
 #include <usbioctl.h>

8. The only places in my MinGW installation where usbioctl.h is present are:
  • C:\MinGW\include\ddk
  • C:\MinGW\mingw32\include\ddk
Since usbioctl.h in both of those folders is identical, I tried including one of their destinations in CFLAGS:
Code:
make CFLAGS="-Ilibblkmaker -IC:/MinGW/include/ddk"
...which unfortunately breaks on me once again:
Quote
 CC     bfgminer-lowl-usb.o
In file included from util.h:47:0,
                 from logging.h:33,
                 from miner.h:42,
                 from deviceapi.h:10,
                 from fpgautils.h:13,
                 from lowl-usb.c:20:
c:\mingw\include\ws2tcpip.h:38:2: error: #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
 #error "ws2tcpip.h is not compatible with winsock.h. Include winsock2.h instead."
  ^
In file included from util.h:47:0,
                 from logging.h:33,
                 from miner.h:42,
                 from deviceapi.h:10,
                 from fpgautils.h:13,
                 from lowl-usb.c:20:
c:\mingw\include\ws2tcpip.h:147:8: error: redefinition of 'struct ip_mreq'
 struct ip_mreq {
        ^
In file included from c:\mingw\include\windows.h:93:0,
                 from C:/MinGW/include/libusb-1.0/libusb.h:62,
                 from lowl-usb.c:18:
c:\mingw\include\winsock.h:315:8: note: originally defined here
 struct ip_mreq {
        ^
In file included from util.h:47:0,
                 from logging.h:33,
                 from miner.h:42,
                 from deviceapi.h:10,
                 from fpgautils.h:13,
                 from lowl-usb.c:20:
c:\mingw\include\ws2tcpip.h:390:13: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'freeaddrinfo'
 void WSAAPI freeaddrinfo (struct addrinfo*);
             ^
c:\mingw\include\ws2tcpip.h:391:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'getaddrinfo'
 int WSAAPI getaddrinfo (const char*,const char*,const struct addrinfo*,
            ^
c:\mingw\include\ws2tcpip.h:393:12: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'getnameinfo'
 int WSAAPI getnameinfo(const struct sockaddr*,socklen_t,char*,DWORD,
            ^
make[2]: *** [bfgminer-lowl-usb.o] Error 1
make[2]: Leaving directory `/home/Administrator/bfgminer'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/home/Administrator/bfgminer'
make: *** [all] Error 2


I'm at loss here...
I followed the steps in the build instruction flawlessly and even got pthread libraries installed but I can't seem to compile it.

If anyone has any ideas about why this won't compile, I'm all ears!
Thanks.
4  Other / Beginners & Help / Re: bitcoin-qt: "ghost" addresses moving from v0.4.0-beta to v0.8.1-beta on: May 14, 2013, 01:23:09 PM
Hello ner0

Did you see the text below the directory listing on
http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-0.4.1/
where there is a discussion of what sounds like your issue. And that 0.4.1 addresses it? The section titled MAJOR BUG FIX (CVE-2011-4447)

wallet encryption...

Ron
Hello,

I am not sure this is the same issue.
At least it only seems to mention the security issue related to the insufficient encryption quality.
The issue I explained was triggered in step 3 (listed bellow), and there is no mention to what might have happened in my case.

Thanks anyway.

Quote
1. Run Bitcoin and let it rewrite the wallet.dat file

2. Run it again, then ask it for a new bitcoin address.
 Bitcoin-Qt: Address Book, then New Address...
 bitcoind: run the 'walletpassphrase' RPC command to unlock the wallet,
  then run the 'getnewaddress' RPC command.

3. If your encrypted wallet.dat may have been copied or stolen, send
 all of your bitcoins to the new bitcoin address.

4. Shut down Bitcoin, then backup the wallet.dat file.
 IMPORTANT: be sure to request a new bitcoin address before
 backing up, so that the 'keypool' is regenerated and backed up.
5  Other / Beginners & Help / Re: bitcoin-qt: "ghost" addresses moving from v0.4.0-beta to v0.8.1-beta on: April 25, 2013, 03:13:36 PM
Thanks for your reply, Ron.
Well, for one thing I can't find bitcoin-qt v0.4.0-beta, only v0.4.1 and higher. Is there somewhere where I could find it?

Also the address to where I sent the 2BTC doesn't exist in my wallet.
I had been using bitcoin-qt for a whole afternoon after rewriting my wallet and it discarded that address as soon as I closed bitcoin-qt. I haven't been able to generate the same address ever since.
A developer told me that the bitcoin-qt pre-loads 100 wallet addresses and if the address validation command doesn't indicate that the address is mine, then I could forget about ever getting back that money.
The thing is that I replicated that "bug" and created around 10 "ghost" addresses on several attempts, none of which would return "ismine" as true when validating the "ghost" addresses.

Anyway, I did try what you suggested but nothing worked. v0.4.1 doesn't show the 2BTC on any transaction, although it correctly grabbed other transactions before and after.
In the same way, the latest version (v0.8.1) didn't either, it also lists transactions before and after but not the one I am missing.
Just as a side note, the bug that made me lose those 2BTC is still present in the latest v0.8.1 - I replicated it again.
In fact, probably anybody can replicate this if they take and old wallet.dat and use it on a newer version, the first time bitcoin-qt runs properly it will not save any changes to the wallet whatsoever, whether it is a pass-phrase change or any newly generated addresses. Even if this bug only affects you under specific circumstances like using an old wallet format that has to be rewritten, it still is a bug that has not been addressed.

Sadly I felt forced to stop using bitcoin-qt as a result. Although it is a very well crafted tool, it surely is not good enough since it can give you random wallet addresses that do not belong to you and clears them after closing the software. It is also my understanding that "validateaddress" is unequivocal, this is why I lost hope in getting that money back altogether. Would it be possible that it could tell me 'ismine' is 'false' for that address and yet still appear in my wallet? Isn't the passphrase the only crucial element for recognizing an address as own?

I appreciate your tips and if you think there is anything else I could try or any other approach, I'm all ears.
Despite being convinced that I will not be able to get that transaction back, I will do anything possible to try to.
6  Other / Beginners & Help / bitcoin-qt: "ghost" addresses moving from v0.4.0-beta to v0.8.1-beta on: April 11, 2013, 04:06:26 PM
The title itself is not self-explanatory so I'll have to get into the details of this weird thing. I'm not sure this is the right place but I'm restricted on other forums... Before that, just to sum-up what happened:
I used bitcoin-qt v0.8.1-beta with my wallet which was last used on v0.4.0-beta.
The first time I created new addresses bitcoin-qt lost them after closing it and 'ismine' function returned false on all of them.
I lost 2.00BTC because of this, mainly two reasons are involved, me being sloppy and me being victim of a random software bug.
In my attempt to avoid this happening to someone else (or to be the harbinger of bad news), I'll explain bellow how this happened:

1. Restored bitcoin-qt wallet backup from v0.4.0-beta;
2. Opened 'bitcoin-0.8.1-win32';
3. bitcoin-qt throws error message: "Wallet needed to be rewritten: restart Bitcoin to complete";
4. Opened bitcoin-qt again and created new address succesfully;
5. Closed bitcoin-qt (File > Exit);
6. Opened bitcoin-qt again and the previously created address is now gone;
7. Created new address again but the address was different from the one missing;
8. Closed bitcoin-qt (File > Exit);
9. Opened bitcoin-qt again and the previously created address is still there;


I've repeated the above process 10 times and in all of them the same thing happens. Also, when running 'validateaddress <address>' in the debug console for those ghost addresses 'ismine' returned false for all of them.
Any addresses created or passphrase change during the 1st run (2nd run if counting the wallet rewriting process) are not saved in my wallet.
This happens without any error or warning whatsoever, and also no significant or related entry on the debug log (http://pastebin.com/LFA1KJja).
Only after the 2nd run was bitcoin-qt able to retain the changes.


I'm not sure if this is a common error that might happen to any wallet in those conditions or if it is an isolated case. The fact that I didn't find any identical story tells me this is rather uncommon.
I'm convinced the 2.00BTC I sent to one of those "ghost" addresses are lost forever so I'm not hopeful of getting them back, but it would be nice if someone could track down the source of this problem and solve it.

Thanks
7  Other / Beginners & Help / Solution: How to re-hook video drivers after a Remote Desktop session on: December 23, 2011, 12:02:00 PM
Hello everyone,

A lot of people have problems when using RDP and GPU mining, for obvious reasons.
Although there are some who already have a workaround using a VNC client, others can have a problem with that, for one it might just not work (like for me) and then you also need to be able to set firewall and port forwarding rules for VNC.

What I propose is a solution that doesn't require for any change whatsoever, you will be able to run the GPU mining from a remote desktop session, although both will not run at the same time, it's technically impossible. Maybe this has already been discussed here, I'm not sure.

The problem:
If you establish a remote desktop session to the computer where you want to run the GPU mining you can't start the mining process because the RDP session has unhooked the hardware drivers and the mining software won't be able to read the GPU, showing an error similar to this:
clGetPlatformIDs failed: invalid/unknown error code

One might think that the solution would be to schedule the mining process to start after you close the RDP session, this won't work out of the box because you closed the RDP session but you didn't terminate it, so the video drivers are still unhooked. Apparently only by either physically logging in or restarting the computer one would be able to re-hook the video drivers again, but there is another way much more easier and faster, without VNC.

Let's cut to the chase...
For this you will need to run the mining process through the command line, then you have to create a small batch file that you will run while in an RDP session. This is the content of the batch file:
@echo off
tscon.exe 0 /dest:console
ping 127.0.0.1
start poclbm.exe -d 0 http://xxx.xxx

The batch file does the following:
1. Terminates the RDP session (allows for the video drivers to re-hook);
2. Pings the localhost (used to delay the beginning of the mining process);
3. Starts the mining process (in a second command prompt);

As soon as you run the batch file your RDP session will be terminated but the mining process will still start remotely, check your pool to see it working. I hope this is useful to anyone who can relate to this problem.

Cheers!
Pages: [1]
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!