Bitcoin Forum
December 06, 2016, 12:14:41 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
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 »
  Print  
Author Topic: (OLD) BFGMiner: modular FPGA/GPU, GBT, Stratum, RPC, Avalon/Lnx/OpnWrt/PPA/W64  (Read 244993 times)
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 20, 2013, 06:06:35 PM
 #541

WAIT means it's waiting on new work from the miner core, which suggests the work producing thread is getting stuck somehow. Can you make a debug log?
Code:
bfgminer all your options first --debuglog 2>debug.log
It would also be helpful to try versions in between (start with half way in between) to narrow down the range of changes that could be responsible.

Is there something indicator that I can search for in the log? Typically it runs for several hours until the mining tasks stop working.
If I knew that, I wouldn't need to get a debug log Smiley

Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481026481
Hero Member
*
Offline Offline

Posts: 1481026481

View Profile Personal Message (Offline)

Ignore
1481026481
Reply with quote  #2

1481026481
Report to moderator
1481026481
Hero Member
*
Offline Offline

Posts: 1481026481

View Profile Personal Message (Offline)

Ignore
1481026481
Reply with quote  #2

1481026481
Report to moderator
1481026481
Hero Member
*
Offline Offline

Posts: 1481026481

View Profile Personal Message (Offline)

Ignore
1481026481
Reply with quote  #2

1481026481
Report to moderator
purelithium
Hero Member
*****
Offline Offline

Activity: 504



View Profile
January 20, 2013, 08:43:04 PM
 #542

Would that be http with port 3333?

exactly.

Like my post? 1H7bfRYh7F89mfmFgsRCdn4awDaUHQmYqY
mezzomix
Legendary
*
Offline Offline

Activity: 1596


View Profile
January 20, 2013, 09:53:46 PM
 #543

WAIT means it's waiting on new work from the miner core, which suggests the work producing thread is getting stuck somehow. Can you make a debug log?
Code:
bfgminer all your options first --debuglog 2>debug.log
It would also be helpful to try versions in between (start with half way in between) to narrow down the range of changes that could be responsible.

Is there something indicator that I can search for in the log? Typically it runs for several hours until the mining tasks stop working.
If I knew that, I wouldn't need to get a debug log Smiley

There is no error in the log, but it seems that the GPU clock and voltages is sometimes going down and in the end it stays low. Seems to be a power management problem. I already set DPMS to false in my xorg.conf but there must be other power managent switches to keep the GPU running at full speed.
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 20, 2013, 10:00:04 PM
 #544

WAIT means it's waiting on new work from the miner core, which suggests the work producing thread is getting stuck somehow. Can you make a debug log?
Code:
bfgminer all your options first --debuglog 2>debug.log
It would also be helpful to try versions in between (start with half way in between) to narrow down the range of changes that could be responsible.

Is there something indicator that I can search for in the log? Typically it runs for several hours until the mining tasks stop working.
If I knew that, I wouldn't need to get a debug log Smiley

There is no error in the log, but it seems that the GPU clock and voltages is sometimes going down and in the end it stays low. Seems to be a power management problem. I already set DPMS to false in my xorg.conf but there must be other power managent switches to keep the GPU running at full speed.
Does it work fine if you disable --auto-gpu and --auto-fan? Finding the first version with this problem is probably crucial...

mezzomix
Legendary
*
Offline Offline

Activity: 1596


View Profile
January 20, 2013, 10:17:15 PM
 #545

I found that even with DPMS=false the screen blanker was enabled. I tried to set 'xset s noblank' and 'xset q' shows now 'prefer blanking: no'. Since I switched this parameter I did not see a single line in the log with the lower GPU frequency. Now I let the miner run and see if it is still working in 24 hours.

I have no idea why this problem did no show up with the old version.
mezzomix
Legendary
*
Offline Offline

Activity: 1596


View Profile
January 20, 2013, 10:22:20 PM
 #546

Does it work fine if you disable --auto-gpu and --auto-fan? Finding the first version with this problem is probably crucial...

I don't know if this is working with my system (AMD E350 single chip CPU/GPU). Most of the GPU parameters are read-only. Control is very limited with this mobile chip.
kano
Legendary
*
Offline Offline

Activity: 1918


Linux since 1997 RedHat 4


View Profile
January 20, 2013, 11:25:48 PM
 #547

I thought it relevant to point out here since Luke-Jr is again spreading lies about his cgminer clone code - in the cgminer thread.

Firstly he made this comment
...
Feel free to make comparisons on the BFGMiner thread.

To which I replied in cgminer:
https://bitcointalk.org/index.php?topic=28402.msg1465045#msg1465045

But specifically he lied about it here in his reply to my comment (above) in cgminer:
...
Clone: Stratum code, copied from cgminer, Scrypt code, copied, GPU code, copied, pool & work scheduling, copied, API, copied, Icarus, BFL, Ztex, driver code, copied. Even the code that makes the CM1 work properly, copied.
More FUD and lies again, kano? Let's try a table:
CodeBFGMinercgminer
...
Icarus driverOriginalCopied, heavily modified and known buggy
...
Ztex driverOriginalCopied
...
...
Of course note the question mark he used above ... which is relevant since of course he is incorrect.

Again as usual I will actually prove what I say, rather than the usual fact that Luke-Jr just lies about this stuff all the time and never proves his lies .. since they are lies and he cannot prove them.

Firstly my answer to the Icarus lie:
Firstly note, I'll only waste my time doing this with one source file rather than spending hours sorting through it all.
This one shows so well how much bullshit his post it.

So ... I just now git cloned his clone miner to a directory on my computer
Code:
git clone https://github.com/luke-jr/bfgminer.git

and then ran this command:
Code:
git blame driver-icarus.c | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3

and the clone result right now (that anyone can run if they like) is
Code:
     5 ckolivas  
     10 Con Kolivas
    526 Kano      
    381 Luke Dashjr
    175 Xiangfu    

and in my cgminer git
Code:
     5 ckolivas    
     18 Con Kolivas  
    698 Kano        
      8 Luke Dashjr  
      3 Paul Sheppard
    180 Xiangfu      

The main changes to the clone code he copied from me (why it says he wrote more than 8 lines in the clone, but still less than me) are CM1 code
They're not in the cgminer version, the cgminer version only supports a CM1 with an Icarus bitstream and no extra CM1 commands that aren't necessary anyway - but the work division, fpga count, baud rate and timing code necessary for the CM1 were written by me.

I'll also point out that there is a file in his git called icarus-common.h that says he wrote every line - but of course I wrote most of the code in there.

i.e. in cgminer the driver-icarus.c file has ALMOST NO CODE from Luke-Jr.
He then copied FROM CGMINER to his clone and modified it and still there is more code in there written by me than by him in his clone.

But also as I point out above at the end of the quote - he has quite literally taken code I wrote and in his clone put it so that it says he wrote it - in the case of icarus-common.h
Even his git lies.

But I will also do the above again for ztex where he posted a lie again saying it was his code in the clone where in fact nelisky wrote most of it originally in cgminer:

Code:
(git blame driver-ztex.c ; git blame libztex.c ; git blame libztex.h) | perl -n -e '/\s\((.*?)\s[0-9]{4}/ && print "$1\n"' | sort -f | uniq -c -w3

In this clone:
Code:
     8 ckolivas    
     92 Con Kolivas
    168 Denis Ahrens
    160 Luke Dashjr
    759 nelisky    
    236 Peter Stuge

So I guess he's also trying to claim he wrote nelisky's code now - damn he lies so much.

... and BTW ... in cgminer the above numbers are:
Code:
     8 ckolivas    
    111 Con Kolivas
    184 Denis Ahrens
      6 Kano        
     18 Luke Dashjr
    864 nelisky    
    228 Peter Stuge

Anyone feel free to check the other lies in his cgminer table post - proving 2 above of the lies is enough for the moment.
https://bitcointalk.org/index.php?topic=28402.msg1465962#msg1465962
Quote
CodeBFGMinercgminer
ScryptCopied, known bugsOriginal
getworkCopiedOriginal
GBTOriginalOriginal, known bugsOne reported possible bug
StratumCopied, plus many bugfixes because of problemsproblems in his clone, not cgminerOriginal
Share submission and stale detectionOriginalCopied, modified, with the share submission code recently done by Kano and ckolivas also copiedOriginal
RPC APICopied, useless "features" hiddenOriginal
Device driver interfaceOriginalCopiedOriginally committed to cgminer now much modified
BFL driverOriginalCopiedCopied, Originally committed to cgminer then heavily modified and about-to-be heavily modified again
CM1 driverOriginalCopied (and modified) from Kano's Icarus codeNon-existent
Icarus driverOriginalMostly Kano's Icarus codeCopied, heavily modified and known buggyOriginal - Xiangfu's original cgminer code heavily modified by Kano
ModMiner driverOriginalCopied, heavily modified and his cgminer version didn't even work until it was modified by Kano!
OpenCL driverCopied, with minor low-level improvementsOriginal
X6500 driverOriginalNon-existent
Ztex driverOriginalCopiedCopiedOriginal
VCOM USB interfacesOS-provided with performance problems and reported device sharing problemsCustom

Pool: https://kano.is BTC: 1KanoiBupPiZfkwqB7rfLXAzPnoTshAVmb
CKPool and CGMiner developer, IRC FreeNode #ckpool and #cgminer kanoi
Help keep Bitcoin secure by mining on pools with Stratum, the best protocol to mine Bitcoins with ASIC hardware
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 21, 2013, 01:05:59 AM
 #548

Hey Luke-Jr

Any idea why I can't log on to bitminter using stratum?
I am trying to connect using:
stratum+tcp://mint.bitminter.com:3333/
and all I get in return is
"No servers were found that could be used to get work from"

I initially tried bfgminer-2.10.* but Doc Haribo says try it with 2.9.* as it worked for him.
Went into this looking to fix some bugs, but I think it's actually a case of confusion between pool docs and miner Smiley
BitMinter's stratum is on eu1.bitminter.com, not mint.bitminter.com ; that is, stratum+tcp://eu1.bitminter.com:3333 should work (and does for me)
You can also use http://mint.bitminter.com:8332 and let BitMinter redirect you to stratum when/if they prefer it (they seem to at the moment).

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 22, 2013, 12:44:25 AM
 #549


NEW VERSION 2.10.3, JANUARY 22 2013

Human readable changelog:
  • Current block display shows end of the previous block hash and (when GBT or Stratum servers are active) the next block's (that you're looking for) height.
  • miner.php and RPC API updates from Kano, including multiuser support for miner.php
  • Finally fix long-standing scrypt difficulty and u-hashrate calculation bugs.

Full changelog
  • Revert "x6500: Whenever we get a hardware error, purge buffers just in case of read/write desync"
  • Bugfix: libblkmaker: Check that zero-padding on base58check input matches output (needed to properly reject addresses with too many or too few prefix/pad '1's)
  • Bugfix: Free bin2hex output in __update_block_title
  • Bugfix: Allocate space for the terminating null byte on new current_hash
  • Display tail end of prevblock hash rather than start+32bits
  • Try to extract block height from coinbase scriptSig, when mining stratum
  • Display next block height when using GBT
  • Use suffixes for target-difficulty also, in share accept/reject loglines
  • Bugfix: Implement common target_diff function, fixing scrypt-specific bugs in and simplifying common code shared by set_blockdiff, calc_diff, and share_diff
  • Set DISPLAY to :0 by default (on non-Windows)
  • Bugfix: Reset pool bytes received when zeroing stats
  • miner.php trim trailing zeros on some of the STATS numbers
  • Semi-Cherrypick: API stats - include pool network bytes + in miner.php
  • Best Share readme
  • API zero - zero statistics - all or bestshare - with optional on screen summary
  • api.c pgaenable not re-enabling the device - plus related debug
  • diffexactone pool diff1 used for share value calculation is ffffffff... not 100000000... :P
  • miner.php user/pass fix 'usr' is readonly
  • miner.php optional user/pass login restrictions
  • zero (most) API stats
  • Remember best share per pool and return in API pools
  • ztex: precheck the secondary solutions to avoid hw errors the ztex bitstreams gives back the latest checked nonce and its hash7 value and two possible solutions.
  • Bugfix: configure: if blocks require at least one command, so fill with true
  • Bugfix: Only log stratum resume if it was actually "idle" before
  • Zero the best share string memory when zeroing stats.
  • Change the pool stratum socket buffer to new cgminer implementation, to allocate it in a grow-only fashon and reduce virtual memory fragmentation at the expense of CPU time.
  • Differentiate socket full from sock full.
  • Allow stratum to startup without notify but check it is valid before creating stratum work.
  • Do not try to generate stratum work unless the notify command has succeeded.
  • Document Mac OS X configure usage with Homebrew pkg-config path
  • Clean up post-configure display of compile environment
  • Bugfix: If native ncurses detection fails, print "none?" result before moving on to try AC_SEARCH_LIBS scan
  • Fix more printf-format non-compatibilities
  • Update windows-build.txt

Fiyasko
Legendary
*
Offline Offline

Activity: 1428


Okey Dokey Lokey


View Profile
January 22, 2013, 02:48:32 AM
 #550

BFGminer=Total freaking ripoff of CGMiner with some personal tweaks

http://bitcoin-otc.com/viewratingdetail.php?nick=DingoRabiit&sign=ANY&type=RECV <-My Ratings
https://bitcointalk.org/index.php?topic=857670.0 GAWminers and associated things are not to be trusted, Especially the "mineral" exchange
crazyearner
Legendary
*
Offline Offline

Activity: 1512



View Profile
January 22, 2013, 05:40:48 AM
 #551

bug still present showing mining in GH/s and not MH/s

.BITSLER.                 ▄███
               ▄████▀
             ▄████▀
           ▄████▀  ▄██▄
         ▄████▀    ▀████▄
       ▄████▀        ▀████▄
     ▄████▀            ▀████▄
   ▄████▀                ▀████▄
 ▄████▀ ▄████▄      ▄████▄ ▀████▄
█████   ██████      ██████   █████
 ▀████▄ ▀████▀      ▀████▀ ▄████▀
   ▀████▄                ▄████▀
     ▀████▄            ▄████▀
       ▀████▄        ▄████▀
         ▀████▄    ▄████▀
           ▀████▄▄████▀
             ▀██████▀
               ▀▀▀▀
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄             
▄▄▄▄▀▀▀▀    ▄▄█▄▄ ▀▀▄         
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▄       
█  ▀▄▄  ▀█▀▀ ▄      ▀████   ▀▀▄   
█ █▄  ▀▄   ▀████       ▀▀ ▄██▄ ▀▀▄
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█  ▀▀       ▀▄▄ ▀████      ▄▄▄▀▀▀  █
█            ▄ ▀▄    ▄▄▄▀▀▀   ▄▄  █
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
█ ▄▄   ███   ▀██  █           ▀▀  █ 
█ ███  ▀██       █        ▄▄      █ 
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀   
▀▄            █        ▀▀      █   
▀▀▄   ███▄  █   ▄▄          █   
▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀     
▀▀▄   █   ▀▀▄▄▄▀▀▀         
▄▄▄▄▄▄▄▄▄▄▄█▄▄▀▀▀▀               
              ▄▄▄██████▄▄▄
          ▄▄████████████████▄▄
        ▄██████▀▀▀▀▀▀▀▀▀▀██████▄
▄     ▄█████▀             ▀█████▄
██▄▄ █████▀                ▀█████
 ████████            ▄██      █████
  ████████▄         ███▀       ████▄
  █████████▀▀     ▄███▀        █████
   █▀▀▀          █████         █████
     ▄▄▄         ████          █████
   █████          ▀▀           ████▀
    █████                     █████
     █████▄                 ▄█████
      ▀█████▄             ▄█████▀
        ▀██████▄▄▄▄▄▄▄▄▄▄██████▀
          ▀▀████████████████▀▀
              ▀▀▀██████▀▀▀
            ▄▄▄███████▄▄▄
         ▄█▀▀▀ ▄▄▄▄▄▄▄ ▀▀▀█▄
       █▀▀ ▄█████████████▄ ▀▀█
     █▀▀ ███████████████████ ▀▀█
    █▀ ███████████████████████ ▀█
   █▀ ███████████████▀▀ ███████ ▀█
 ▄█▀ ██████████████▀      ▀█████ ▀█▄
███ ███████████▀▀            ▀▀██ ███
███ ███████▀▀                     ███
███ ▀▀▀▀                          ███
▀██▄                             ▄██▀
  ▀█▄                            ▀▀
    █▄       █▄▄▄▄▄▄▄▄▄█
     █▄      ▀█████████▀
      ▀█▄      ▀▀▀▀▀▀▀
        ▀▀█▄▄  ▄▄▄
            ▀▀█████
[]
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 22, 2013, 12:27:12 PM
 #552

bug still present showing mining in GH/s and not MH/s
Really? I made sure to fix this in 2.10.3, and verified it by mining on some scrypt server someone on IRC let me use... :/

mezzomix
Legendary
*
Offline Offline

Activity: 1596


View Profile
January 25, 2013, 07:47:53 AM
 #553

I found that even with DPMS=false the screen blanker was enabled. I tried to set 'xset s noblank' and 'xset q' shows now 'prefer blanking: no'. Since I switched this parameter I did not see a single line in the log with the lower GPU frequency. Now I let the miner run and see if it is still working in 24 hours.

Noblank did not help. What worked was to switch the pool (from eligius/GBT to btcguild/stratum). Now, 2.10.2 is running since 48 hours without the GPU miner threads going into the WAIT state.
ocminer
Legendary
*
Online Online

Activity: 1568



View Profile WWW
January 25, 2013, 11:07:41 PM
 #554

I have one x6500 where only one fpga works, bfgminer fails at this board giving a core dump:

 [2013-01-25 23:59:06] Probing for an alive pool
 [2013-01-25 23:59:08] Long-polling activated for http://us.eclipsemc.com:8337 (getblocktemplate)
 [2013-01-25 23:59:10] Long-polling activated for http://pit.deepbit.net:8332/listenChannel (getwork
)
 [2013-01-25 23:59:11] XBS 0.1: Flushed 1 nonces from buffer at init
 [2013-01-25 23:59:11] XBS 0.1: Frequency set to 200 MHz (range: 2-250)
 [2013-01-25 23:59:11] XBS 0: JTAG detect returned -2
 [2013-01-25 23:59:11] Thread 0 failure, exitingSegmentation Fault
root@TX1XP:~/bfgminer-2.10.2#

On my other boards it seems to work...

MPBM simply ignores the non working FPGA and runs with the resuming FPGA, can bfgminer do the same ?

suprnova pools - reliable mining pools - #suprnova on freenet
https://www.suprnova.cc - FOLLOW us @ Twitter ! twitter.com/SuprnovaPools
Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 26, 2013, 01:50:28 AM
 #555

I have one x6500 where only one fpga works, bfgminer fails at this board giving a core dump:

 [2013-01-25 23:59:06] Probing for an alive pool
 [2013-01-25 23:59:08] Long-polling activated for http://us.eclipsemc.com:8337 (getblocktemplate)
 [2013-01-25 23:59:10] Long-polling activated for http://pit.deepbit.net:8332/listenChannel (getwork
)
 [2013-01-25 23:59:11] XBS 0.1: Flushed 1 nonces from buffer at init
 [2013-01-25 23:59:11] XBS 0.1: Frequency set to 200 MHz (range: 2-250)
 [2013-01-25 23:59:11] XBS 0: JTAG detect returned -2
 [2013-01-25 23:59:11] Thread 0 failure, exitingSegmentation Fault
root@TX1XP:~/bfgminer-2.10.2#

On my other boards it seems to work...

MPBM simply ignores the non working FPGA and runs with the resuming FPGA, can bfgminer do the same ?
Looks doable. Let me see if I can figure out a way to reproduce the crash here...

coinotron
Legendary
*
Offline Offline

Activity: 995


View Profile
January 30, 2013, 01:16:37 PM
 #556

I'm pool operator at Coinotron.com. I recently introduced support for Stratum for an "exotic" Terracoin coin. TRC is basically BTC with few tunings. You can mine for TRC using the same miners as in case of BTC.

I have observed very strange behavior of some miners using BFGminer 2.10.2. When new block is solved by network pool creates new block template and emits it to all subscribed miners using mining.notify rpc.

The issue is: very often those BFGminer miners keep submitting shares for previous block (stales) for quite a long time (several seconds)

In example below Client 52 asks for transactions after he received mining.notify number 946, and almost 3 seconds later submits work belonging to previous block (945). 2 sec later the same situation occurs.
I'm sure that miner received mining.notify 946 message because 150ms later he asks for transactions for block template 946

Can you please look into it?

[2013-01-29 06:47:18.505] Coin: TRC, New block on network detected: 60023
[2013-01-29 06:47:18.505] Coin: TRC, BlockTemplate created: 946, For block num: 60024, in: 0ms
[2013-01-29 06:47:18.505] ClientId: 52, Outbound message: {"params": ["946", "xx", "xx", "xx", ["xx"], "xx", "xx", "xx", true], "id": null, "method": "mining.notify"}
[2013-01-29 06:47:18.646] ClientId: 52,  Inbound message: {"params": ["946"], "id": "txlist946", "method": "mining.get_transactions"}
[2013-01-29 06:47:21.391] ClientId: 52,  Inbound message: {"params": ["ClientId: 52", "945", "xx", "xx", "xx"], "id": 145, "method": "mining.submit"}
[2013-01-29 06:47:21.391] ClientId: 52, Outbound message: {"id": 145, "result": null, "error": [21, "Job not found (=stale)", null]}
[2013-01-29 06:47:23.294] ClientId: 52,  Inbound message: {"params": ["ClientId: 52", "945", "xx", "xx", "xx"], "id": 146, "method": "mining.submit"}
[2013-01-29 06:47:23.294] ClientId: 52, Outbound message: {"id": 146, "result": null, "error": [21, "Job not found (=stale)", null]}

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
January 30, 2013, 01:37:15 PM
 #557

I have observed very strange behavior of some miners using BFGminer 2.10.2. When new block is solved by network pool creates new block template and emits it to all subscribed miners using mining.notify rpc.

The issue is: very often those BFGminer miners keep submitting shares for previous block (stales) for quite a long time (several seconds)

In example below Client 52 asks for transactions after he received mining.notify number 946, and almost 3 seconds later submits work belonging to previous block (945). 2 sec later the same situation occurs.
I'm sure that miner received mining.notify 946 message because 150ms later he asks for transactions for block template 946

Can you please look into it?
Can you provide a test stratum URI that I can reproduce this with?

coinotron
Legendary
*
Offline Offline

Activity: 995


View Profile
January 30, 2013, 01:48:22 PM
 #558

Can you provide a test stratum URI that I can reproduce this with?

Yes. Just create account at coinotron.com, create worker  (type must be TRC).
Uri: coinotron.com:3333

Luke-Jr
Legendary
*
Offline Offline

Activity: 2086



View Profile
February 03, 2013, 09:01:22 PM
 #559

FWIW, I just came across a remote buffer overflow exploit in both cgminer and BFGMiner. It's unlikely that it can be used for anything other than a pool crashing the miner program, and I will have it fixed in the next BFGMiner release. Just in case (I'm no security expert), details are only available privately to persons with a good reason to know (like Con) until the fix is released.

twobitcoins
Full Member
***
Offline Offline

Activity: 144


View Profile
February 05, 2013, 09:30:28 AM
 #560

To prepare for the arrival of BFL ASICs, I built bfgminer 2.10.3 and tested it for solo mining with bitcoin-qt 0.7.2.  This is a report of various issues I encountered.


1. Build dependencies

The README file mentions package names for dependencies, but in some cases I had to use different package names on Ubuntu 12.04:

  • Instead of libncurses5-dev, I needed libncursesw5-dev.
  • Instead of libusb-dev, I needed libusb-1.0-0-dev.

I don't know if those are errors or just a consequence of differences between distributions.


2. SSL

I configured bitcoin-qt for SSL using a self-signed certificate as explained at https://en.bitcoin.it/wiki/Enabling_SSL_on_original_client_daemon, but bfgminer refused to connect due to the self-signed certificate.  At first, I fixed it by disabling certificate verification:

Code:
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYPEER, 0);

Later, I copied the certificate from bitcoin-qt and told bfgminer to verify using that certificate.  I also had to disable host name verification since I am connecting by IP address:

Code:
curl_easy_setopt(curl, CURLOPT_SSL_VERIFYHOST, 0);
curl_easy_setopt(curl, CURLOPT_CAINFO, "bitcoin.cert");

Is there some standard way this is supposed to work that I'm missing?  Maybe bfgminer needs settings to control these SSL behaviors.


3. getblocktemplate falling back to getwork

If I stop and restart bitcoin-qt while bfgminer is running, bfgminer detects that getblocktemplate failed and falls back to getwork from that point on.  I fixed it by patching pool_protocol_fallback.  There probably needs to be a way to force the use of getblocktemplate only.


4. Long polling

bitcoin-qt does not support long polling, and by default bfgminer only calls getblocktemplate every 120 seconds, resulting in an average of 60 seconds of wasted work per block, or 10% of the total work.  Without long polling, I'd prefer to call getblocktemplate more like every 5 seconds.  I tried "--expiry 5" but found that it decreases the reported hash rate substantially.  The GPU load is also significantly reduced, so the effect is real.  I haven't tracked down exactly what effect the expiry setting is having, but it should be possible to make a new call to getblocktemplate while continuing to do work based on the result of the previous call.  Or am I just not using the correct options?

I tried applying pull request 1355 to add long polling support to my bitcoin-qt.  It mostly works: hashing proceeds at full speed and new blocks are detected right away.  The long polling implementation in the pull request is not ideal though.  It only returns when a new block is found, not to update the set of transactions, so that means fewer transaction fees for the miner and slower transaction processing for everyone.  It may be better for getblocktemplate to use the same logic for long polling that it uses to decide when to call CreateNewBlock: if a new block was received or if new transactions were received and at least 5 seconds have passed since the last update.  I tried to simulate that by making getblocktemplate sleep for 5 seconds instead of waiting for a new block.  It seemed to work, and didn't have a major impact on the hash rate.  Trying to handle it on the client side with "--expiry-lp 5" had the same performance problems as "--expiry 5".

Another issue with the pull request: it prevents bitcoin-qt from shutting down promptly because the RPC thread is busy waiting for a new block.


5. --coinbase-addr

The --coinbase-addr option uses a single address for all mined blocks.  For privacy, it would be better for every block to use a distinct address.  That would require the user to supply a pool of addresses to bfgminer, and bfgminer would need to mark them as "used" in a way that is persistent across sessions.  I think it would be a nice enhancement.

My personal preference is for coinbase transactions to pay public keys rather than addresses, mostly because that is how it was historically done from the days of mining directly within the bitcoin client, but I admit it is of little practical importance.  It looks like most coinbase transactions pay addresses these days.
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 »
  Print  
 
Jump to:  

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!