Bitcoin Forum
May 27, 2016, 12:19:01 AM *
News: Latest stable version of Bitcoin Core: 0.12.1 [Torrent]
 
  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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 ... 242 »
401  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 18, 2014, 08:36:41 PM
Hm, actually, benchmarking might be difficult in general since we don't know we're comparing apples to oranges.
For example, consider the following setup (remember, all within a single BFGMiner instance):
4 CPU cores (any algorithm)
4 GPUs (SHA256d, scrypt, Keccak)
2 DualMiners (SHA256d, scrypt)
2 ZeusMiners (scrypt only)
2 NanoFurys (SHA256d only)

In this case, what is the "performance" of each algorithm?
There's probably a number of different ways a multipool might want to react to this. :/
402  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 18, 2014, 07:46:14 PM
Performance means hashrate. What is important to give proper ratios - how much is algo1 faster than algo2, but you can clearly replace it pure speed. Measuring speed on pool side is out of the question, because miner has to be connected for a while, thus meaning that every restart of miner would cause pool first to "test" all algorithms for the miner (in case of having 10 algorithms this means 50 minutes of testing for speed).
Makes sense why the pool can't measure it, but most pools/miners only use one algo, and it isn't fair to waste 1 minute doing benchmarks of 60 algos when they only really want one...
Perhaps another solution is to add some way I can tell you the precise hashrate regardless of shares?

Yes, using performance parameter when sending mining.capabilities. The pool can then calculate exactly, which algorithm gives best profit according to provided performance ratios and current earnings for each algorithm.
I meant like stratum's (undocumented, maybe unspecified?) mining.get_hashrate method.
If BFGMiner supports 294234 different algorithms, it doesn't make sense to benchmark them all (wasting electricity) before we even know what the pool might possibly use.
Makes much more sense to let the pool do the benchmarking as needed... then the miner gets some credit (even if not ideal) during the benchmarking, and only benchmarks algorithms the pool will actually use.
403  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 07:41:19 PM
Performance means hashrate. What is important to give proper ratios - how much is algo1 faster than algo2, but you can clearly replace it pure speed. Measuring speed on pool side is out of the question, because miner has to be connected for a while, thus meaning that every restart of miner would cause pool first to "test" all algorithms for the miner (in case of having 10 algorithms this means 50 minutes of testing for speed).
Makes sense why the pool can't measure it, but most pools/miners only use one algo, and it isn't fair to waste 1 minute doing benchmarks of 60 algos when they only really want one...
Perhaps another solution is to add some way I can tell you the precise hashrate regardless of shares?
404  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 01:27:33 PM
only accepting shares from pool 0
what am i doing wrong ?!

Sorry, I just now noticed you're using the stratum proxy feature.
Stratum doesn't support this kind of thing, so the proxy ends up not doing any balancing at all right now...
405  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 01:06:59 PM
Regarding mining.capabilities:

The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])

In this case, for set_multialgo, we would use parameter list as following:

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])

This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.
Isn't this something you can have users configure on your website?
I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs.
I suppose it makes sense to tell the pool as well, so it can try to offer the best deal...

Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm.
How about we take your idea, but with some minor changes to these options?
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}})
This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option.

Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point Wink


As long as it doesn't bring any ambiguousness to future possible extensions of this method, it is fine for me. But I would still rather "group" all supported algorithms together.
So maybe:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}})

Also, what should be considered is the possibility to omit 'cost' - in that case, cost is considered as being 0. Following this logic, omitting performance, sets algorithm speed to 0 which means "don't ever send me jobs for this algorithm".
Well, that wouldn't work. Most of the time (at least right now, all of the time), cost and performance are unknowns - so BFGMiner has nothing to send for those.
In practice, I was thinking of sending:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":[],"SHA256d":[]}})

Another thing maybe we need to consider is how you would want to handle rigs that have a set of scrypt+SHA256d devices (CPU, OpenCL, maybe DualMiner in the future), and also SHA256d-only devices...

Miner should send mining.capabilities as soon as it establish connection with pool (before any other subscription or authorization) - that way, pool can properly assign miner for the first job already.
Yes, this is already the case.

If you send empty parameters without performance and costs, then pool cannot know what kind of performance of each algorithm is reached, thus cannot make decision which algorithm work to provide. Giving performance parameter is mandatory. I suggest to get performance by doing "benchmarking" of each algorithm prior actual connection to the pool - this is good also because people don't have to do manual measurements any more as they have to do it now. Cost should be still just optional and by default 0 - rare people actually set cost factors (looks like most GPU miners use free electricity).
Benchmarking prior to pool connection is IMO not reasonable.
What does "performance" even mean here, anyway?
If it's just hashrate, why not just measure it pool-side based on shares submitted?

When it comes to multiple miners that are capable of mining more algorithms at the same time; certain resource (let's assume GPU) is in most cases saturated 100% - if it is not, algorithm is not well coded. I suggest to simply run multiple instances of miners (one that takes CPU resource, one takes GPU resources,...) and establish multiple connections - of course, with each one having own list of supported algorithms with proper performance factors.
BFGMiner aims to support everything within one miner instance Smiley
Also note that generally, "memory-hardish" algorithms like scrypt can be run in parallel with SHA2, with only a minor performance hit on the SHA2 hashing...
406  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 12:42:05 PM
If the stratum arg is implemented correctly shouldn't the pool line display  have Diff:305u  +Strtm  Lu:[time]
 all I see is the "+" without Strtm.   Or a line that says Connected to multiple pools......
You're used to an older version.
He's connected to 5 pools, (pools 0, 1, 2, 3, and 4), with work update notification (the +).
Exact protocol being used isn't visible when there are multiple active pools.
407  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 12:31:35 PM
i'm trying to use --balance with --stratum-port <arg>
it dosn't balance shares between pools  Huh
only work with the first pool & discard the rest  Huh
Are the pools working on the same blockchain?
If not, are you using 4.99.0 and giving the pools separate goals?

same pool & blockchain with different login/worker only
using 4.10.0
Are you sure it's not being balanced?
Maybe the workers have different share difficulties (which would result in the lower diff getting that much more shares)?
What symptoms are you seeing?

only accepting shares from pool 0
what am i doing wrong ?!

My guess is your other pools have higher share diff than 305u.

it is same pool with different worker only same diff same IP:port & everything
the only thing is changed is the worker
Can you run with --log-file debug.log --debuglog and PM me a Google Drive ZIP of the debug.log file?
408  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 12:20:05 PM
i'm trying to use --balance with --stratum-port <arg>
it dosn't balance shares between pools  Huh
only work with the first pool & discard the rest  Huh
Are the pools working on the same blockchain?
If not, are you using 4.99.0 and giving the pools separate goals?

same pool & blockchain with different login/worker only
using 4.10.0
Are you sure it's not being balanced?
Maybe the workers have different share difficulties (which would result in the lower diff getting that much more shares)?
What symptoms are you seeing?

only accepting shares from pool 0
what am i doing wrong ?!

My guess is your other pools have higher share diff than 305u.
409  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 12:02:16 PM
i'm trying to use --balance with --stratum-port <arg>
it dosn't balance shares between pools  Huh
only work with the first pool & discard the rest  Huh
Are the pools working on the same blockchain?
If not, are you using 4.99.0 and giving the pools separate goals?

same pool & blockchain with different login/worker only
using 4.10.0
Are you sure it's not being balanced?
Maybe the workers have different share difficulties (which would result in the lower diff getting that much more shares)?
What symptoms are you seeing?
410  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 14, 2014, 11:56:31 AM
i'm trying to use --balance with --stratum-port <arg>
it dosn't balance shares between pools  Huh
only work with the first pool & discard the rest  Huh
Are the pools working on the same blockchain?
If not, are you using 4.99.0 and giving the pools separate goals?
411  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 13, 2014, 05:26:06 PM
Regarding mining.capabilities:

The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])

In this case, for set_multialgo, we would use parameter list as following:

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])

This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.
Isn't this something you can have users configure on your website?
I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs.
I suppose it makes sense to tell the pool as well, so it can try to offer the best deal...

Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm.
How about we take your idea, but with some minor changes to these options?
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}})
This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option.

Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point Wink


As long as it doesn't bring any ambiguousness to future possible extensions of this method, it is fine for me. But I would still rather "group" all supported algorithms together.
So maybe:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}}})

Also, what should be considered is the possibility to omit 'cost' - in that case, cost is considered as being 0. Following this logic, omitting performance, sets algorithm speed to 0 which means "don't ever send me jobs for this algorithm".
Well, that wouldn't work. Most of the time (at least right now, all of the time), cost and performance are unknowns - so BFGMiner has nothing to send for those.
In practice, I was thinking of sending:
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"malgo":{"scrypt":[],"SHA256d":[]}})

Another thing maybe we need to consider is how you would want to handle rigs that have a set of scrypt+SHA256d devices (CPU, OpenCL, maybe DualMiner in the future), and also SHA256d-only devices...

Miner should send mining.capabilities as soon as it establish connection with pool (before any other subscription or authorization) - that way, pool can properly assign miner for the first job already.
Yes, this is already the case.
412  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 13, 2014, 03:03:17 PM
Regarding mining.capabilities:

The second parameter is an Object with key/value option pairs. Wouldn't this be better (example how to tell about certain mining capability + give some parameters):

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : []])

In this case, for set_multialgo, we would use parameter list as following:

mining.capabilities(["notify" : [] , "set_difficulty" : [], "set_multialgo" : [ "scrypt-performance" : 1.0, "scrypt-cost" : 0.001, "neoscrypt-performance" : 0.3, "neoscrypt-cost" : 0.001 ]])

This way, miner can tell to the pool exactly what kind of algorithms it would like to work on and what kind of speeds (performance) it has and costs related to it - pool can then take these factors and make proper calculation and assign miner to algorithm that is best for the miner.
Isn't this something you can have users configure on your website?
I would think that when costs are known to BFGMiner, it (and not the pool) should be making the decision about which pool to be mining on based on costs.
I suppose it makes sense to tell the pool as well, so it can try to offer the best deal...

Perhaps more importantly: those options are independent of support for the set_goal method - they're parameters for each algorithm.
How about we take your idea, but with some minor changes to these options?
mining.capabilities({"notify":[],"set_difficulty":[],"set_goal":[],"scrypt":{"performance":1.0,"cost":0.001},"neoscrypt":{"performance":0.3,"cost": 0.001}})
This way if methods have specific parameters, they don't need to be duplicated, but each algorithm is considered an independent option.

Note it's set_goal rather than set_multialgo for a reason - I'm hoping to add support for non-blockchain non-PoW goals at some point Wink
413  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 11, 2014, 12:43:35 AM
Is supporting neoscrypt in BFGminer's future?
If someone contributes the code...
414  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 10, 2014, 10:54:38 PM
So after a ton of work, multi-blockchain and multi-algo support for BFGMiner is starting to shape up.
I would greatly appreciate if others interested in this field could contribute by testing and/or improving documentation as needed to make usage of new features easily accessible.
"Multipool" operators are asked to review the new stratum extension proposals to ensure they cover all desired use cases and/or help test them.
Front-end developers (or anyone using RPC) likewise are welcome to critique the RPC changes.
If anyone wants to get their favourite proof-of-work algorithm added for 5.0, now is the time to propose your code in a merge/pull request (sorry, I don't have time to write this code myself at the moment, so you'll need to bring-your-own-code).

DRAFT Human readable changelog:
  • Multi-blockchain support: BFGMiner can now be told which pools use the same "mining goals", and will track the blockchain independently for ones that don't. This allows you to mine multiple cryptocurrencies concurrently using any pool strategy (including balance and load-balance).
  • Multi-algorithm support: BFGMiner is now capable of hashing on both scrypt and SHA256d work at the same time, and you can assign the mining algorithm to use on a per-goal basis. As with multi-blockchain support, this works even in balancing strategies. Note that at this time, only CPU, OpenCL, and Proxy drivers actually support multiple algorithms at the same time (DualMiner must be preconfigured for only one, and GridSeed remains scrypt-only).
  • Stratum extensions for mining goals: New experimental methods mining.capabilities and mining.set_goal for Stratum allow you to expose control of the mining algorithm to the pool. These extensions are considered draft and may be changed based on the needs of multiblockchain pool operators.
  • RPC: Also extended for multiple mining goals/algorithms. Interface is subject to change.
  • Titan: Work flushing optimisations from KnCMiner.

The code is in git under the bfgminer branch (and tagged bfgminer-4.99.0).
Windows downloads are available from http://luke.dashjr.org/programs/bitcoin/files/bfgminer/4.99.0/
415  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 08, 2014, 01:24:24 PM
Creating a new session:
Session name:  Ronald
Working commit:  bfgminer-3.99.0
Broken commit:  bfgminer-4.10.0

[Start]

-----------------------------

On commit c4c06166a2ab6937d2d6e198842289ca83c67770
c4c06166a2ab6937d2d6e198842289ca83c67770 build failure (http://luke.dashjr.org/tmp/code/webisect/wr/c4c06166a2ab6937d2d6e198842289ca83c67770.log) - skipping

So wait for the next build...
416  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 08, 2014, 12:54:10 PM
Quote
Please use http://luke.dashjr.org/tmp/code/webisect/webisect.php to identify the regression.

sh: ./make-release: No such file or directory
I don't know what you're trying to say. It's expected that some builds throughout this process will fail, and it should automatically move on...
417  Bitcoin / Mining software (miners) / Re: BFGMiner 4.10.0: GBT+Stratum, RPC, Mac/Linux/Win64, Spondoolies SP30 on: November 08, 2014, 12:33:54 PM
Hehe Smiley the poll address is fake just intentionally, ok so I downloaded 4.10 ver for my windows machine and it acts the same when i'm trying to mine with my gpu, bfgminer-3.10.7-win64 works fine with the pool i use  , bfgminer-4.10.0-win64 does not. The same issue is on linux. May it be a pool is incompatible? I am mining there with dmaxl's cgminer but it's not updated anymore.
Please use http://luke.dashjr.org/tmp/code/webisect/webisect.php to identify the regression.
1. Enter anything random for Session name, click Go.
2. For "Working commit:", put bfgminer-3.10.7
3. For "Broken commit:", put bfgminer-4.10.0
4. Click "Start"
5. Wait for the webserver to build a CUSTOM version of BFGMiner (ignore the version it claims to be when you run it).
6. Download the custom build, and test if it works. Click the relevant button.
7. Go back to step 5 until it gives you a "verdict" on which change is guilty for breaking it.
8. Post the final result here.
418  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 06, 2014, 02:56:47 PM
Speaking of which, how would fees work here? The paper talks about how it's most beneficial to the miners to mine on every sidechain they can, but how do sidechains provide a reward? When users are using a sidechain do they need to provide fees to the network with their own bitcoins?
Yes, just like any bitcoin transaction...
Sidechains might also use things like demurrage to give miners a subsidy.
419  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 06, 2014, 01:45:40 PM
"First, the miner must assemble a transaction set for both block chains."
http://bitcoin.stackexchange.com/questions/273/how-does-merged-mining-work

So if I'm reading that right, merge mining would mean that miners would need to assemble a different transaction set for every sidechain and then mine them? Then for every successful block for any sidechain the miner would send that work to the sidechain.

I'm very confused about how the hashing calculation can be independent of both Bitcoin and the sidechain, I thought PoW built on top of a hash of the latest block, in which case the hashes from one blockchain can't be used to secure another blockchain.
The PoW algorithm for <sidechain> would include a Bitcoin block header in it.
But we're now somewhat off-topic for this thread, which is about sidechains, not merged mining...
420  Bitcoin / Development & Technical Discussion / Re: Pegged Sidechains [PDF Whitepaper] on: November 06, 2014, 01:23:22 PM
The small space available for configuring the SPV proofs, the ease of 51% attacks, the high resource costs, fairly high complexity, and few use cases ends up making me very skeptical that the thing should be in Bitcoin, but I think it's a neat protocol.
Uh, what "ease" of 51% attacks? Or high resource costs?
And only few use cases? O.o
Maybe I misunderstood, but I thought that this thing needed to have it's own hash-power in order to avoid attacks from the main blockchain. Therefore, unless the sidechain has enormous hashpower it would be trivial for a party to break away from the primary chain to do a 51% attack.
Merged mining solved this a long time ago.

I say it's few use cases because I'm not convinced that there are alot of uses that would be preferred to be in a sidechain, rather than a totally separate solution. Though I'm not financier or whatever, so I'm probably just ignorant of all the potential.
I can't think of any uses that would prefer a totally separate solution (other than scams).
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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 ... 242 »
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!