That's more of a networking/firewall problem to solve - nothing related to bminer. It's completely dependent on your networking setup (LAN, DNS, WAN, etc). Too many variables to solve via a forum post...

Try changing the `api` parameters to


Change 1880 to whatever port you want to listen on. 0.0.0.0 should mean that it binds to all available network interfaces/IPs, or at least it does usually.

Simply put, it sits in the middle between your miner(s) and your pool(s), in an effort to consolidate multiple miners/rigs through a single connection to the pool. Your miners connect to to the proxy, and the proxy connects to the pool (just once, even for multiple miners), resulting in a single difficulty for all connected miners.

Without a proxy, your miner connects directly to a pool. There's nothing wrong with this, generally speaking - but with miner crashes/restarts due to overclocking or bugs, the miner has to reconnect to the pool. This can mean that your miner is seen by the pool as 'new' after reconnecting, which is generally considered a bad thing (you can lose out on shares/sharerate as you might be treated as a pool hopper). It's important to note that there are multiple factors involved, and over time pools are likely trying to get better at detecting pool hopping more precisely.

With a mining proxy sitting in the middle, the proxy maintains the connection to the pool on miner disconnect, the proxy keeps track of current difficulty and mining job, etc. When miners reconnect, they receive those same values - essentially picking up where they left off. The pool doesn't see any disconnects, and so any impact from pool-hopping isn't attributed to your account.

In the past, others have stated that a 20% improvement in sharerate/shares/reduction in stale/invalid shares have been achieved through the use of a proxy. I'm interested whether this still holds true, assuming that miners and pools have actually improved over the last couple of years, which may not be that true... 🤔

Just to make sure we're on the same page here - this is a mining proxy, not the GPU/CPU mining software itself. Its primary purpose is have multiple mining rigs (each rig running mining software like ewbf, dstm, bminer, etc) proxy pool network communication to a) reduce network requirements and b) stabilize share rates.

Given that it is non-blocking by nature and virtually all operations are networking (ie. I/O-related), it should handle a decent number of rig/miner connections without impact, and overall help both miner share rates and reduce pool resources. There have been claims in the past of 20% improvement in shares just by using a pool proxy like this - but keep in mind that there have been a lot of improvements in protocols, miners, and pools in the past couple of years.

Edit: I would say there are benefits to running a proxy like this in a single rig environment as well - when your miner software crashes or restarts, the proxy will maintain the connection to the pool, difficulty, etc. The pool doesn't see your miner drop its connection, which (can?) affects your sharerate stats, whether you're considered a pool jumper, etc.

I'd appreciate testing and feedback!

I just announced new equihash mining proxy software, see the BCT post here: https://bitcointalk.org/index.php?topic=3179895

Open source, no devfee, multi coin/algo, just aiming to help miners out. Building it has been a great learning experience in the mining technology ecosystem. I appreciate the feedback - happy mining. Spread the word!

I just announced new mining proxy software, see the BCT post here: https://bitcointalk.org/index.php?topic=3179895

Open source, no devfee, multi coin/algo, just aiming to help miners out. Building it has been a great learning experience in the mining technology ecosystem. I appreciate the feedback - happy mining. Spread the word!

reserved for version/release notes

aiostratum-proxy is a new, open source stratum protocol (and altcoin derivatives) mining proxy. Its focus on being extensible/modular is one of its greatest strengths: users can create new aiostratum-proxy coin/algos 'plug-ins' or 'modules' without having to modify aiostratum-proxy itself.

Originally built as a learning exercise to better understand stratum protocol(s) and the mining ecosystem, I now think that others will benefit by making aiostratum-proxy available for everyone to use.

The goal for aiostratum-proxy is to make it the easiest solution for any coin/algorithm pool proxying needs, via the creation of JSONRPC (the stratum base 'language') modules.

More information available at the aiostratum-proxy Github repository.

Current Status:

As mentioned, aiostratum-proxy is new, and is looking for some testing beyond what I've thrown at it. Current coin/algo support is Equihash-only (more to come, given community interest). Constructive feedback is needed and appreciated.

Donations:

There is no dev fee. However, I eat food and need to support those around me - devs need to make money too. Consider it incentive to maintain and continue developing aiostratum-proxy. So if you use this proxy, donate using the addresses below:

• BTC: 1BS4QYAFiya4tsjyvHeY945biKnDj6bRA4
• LTC: LTN1LPGnJjHMKq4DcuQYifQgLfT4Phmn9d
• ETH: 0x4B005e68D323bdABD8eeD1D415117Ff1B57b3EC5
• BTCP: b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg
• ZCL: t1eoqTqyatJzL2rErW83waZLQHZLKuipMbi

Don't have any of the above? I'll look into getting an address in your choice currency.

Features:

The intention for aiostratum-proxy was to be feature-comparable with existing mining proxies, yet extensible without forking to add support for other coins.

• Configure multiple proxies to run at the same time (ie. mine same/different coins on same/different pools)
• Each proxy configuration supports multiple fallback pools
• Each proxy supports up to 65536 miner connections, each mining a separate nonce space (dependent on coin & miner support)
• Supports plaintext and secure connections (TLS/SSL) for both miner and pool connections
• Easily implement new coin/algorithm JSONRPC 'stratum-like' protocols as dynamically-loaded (via config file), external Python3 modules

Supported Coins/Algos:

• Equihash
• ... it's a bit lonely here, let's add some more maybe?

How you can help:

• Test!
• Create coin/algo modules (submit pull requests)
• Find bugs (File them on Github)
• Donate (see above!)
• Spread the word to coin dev teams, pool operators, other miners
• ... share your ideas for improvement

Requirements & Compatibility:

aiostratum-proxy is written using Python3's non-blocking async/await syntax - so Python 3.5 or greater is required.

It runs on Linux and macOS, and should work on Windows (send in reports, please).

Installation:

Read all of the Installation and Usage sections before proceeding with installing.

It's best to always refer to the aiostratum-proxy Github repository for source code and updated installation and usage instructions - but for the eager miners out there... installation is pretty simple:


... but you probably really want to use Python virtual environments to contain the installation, rather than installing globally:


As you can see, installation creates a new command-line shortcut called aiostratum-proxy.

Usage:

A YAML config file is needed for the proxy to run (learn more about YAML); you can generate one:


Open and edit the generated proxy-config.yaml in a text editor. To run aiostratum-proxy, pass it your edited config file:


While you probably should always generate and edit your own config using the above instructions, here's a couple of sample configs for mining Bitcoin Private (BTCP) - to show you how simple they can be. Remember to modify addresses, usernames, passwords to use your own:


The above uses the included Equihash support, defines a single unsecured port for miners to connect to and a single pool to proxy to. Simple, but not very secure or robust. Let's try again, adding in secure connections and a fallback pool:


The above uses the included Equihash support, defines 2 ports for miners to connect to (1 of them being SSL/TLS secured) and 2 pools to proxy to (the second being the fallback).

Authorization Setting Notes:

Handily, aiostratum-proxy will automatically extract the worker name from each miner's authorization (when it connects) and appends it to the account_name config setting before authorizing with the pool. This allows you to continue per-miner hash/share rate tracking at the pool level. (Thanks Doftorul for the feedback!)

Step by step explanation:

• Miner connects to aiostratum-proxy with randomletters.worker1
• aiostratum-proxy extracts worker1 from the miner's auth
• aiostratum-proxy appends worker1 to the config file pool account_name setting giving us b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg.worker1
• aiostratum-proxy requests authorization from the pool for b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg.worker1
• Miner is authorized, stats are tracked at the pool as desired

Note that you CAN optionally put a worker name in the config file pool account_name setting (ie. b1CACK65UTwzmHGw2VvyozdPsRLMb8utGLg.worker1, but this will cause miner-specific worker names to be ignored. You might want this in a larger farm setup, perhaps.

Release Notes:

1.0.2 2018/07/13

• Fixing keepalive issue
• Added debug statement to help detect miner/proxy misconfiguration

1.0.1 2018/07/12

• Adding in worker socket keepalive configuration

1.0.0 2018/03/22

• Initial release

Future Ideas/Thoughts:

This section contains some ideas that may not get implemented - it depends on community feedback.

• Improve documentation
• Consider immediate reply to miner share submissions instead of waiting for pool response
• Complete mining.set_extranonce support
• Consider additional authentication improvements (currently miners aren't authenticated)
  
  • authenticate miners locally within proxy via config
  • authenticate miners via passthru to pool; would require per-pool mappings of username/password for fallback pools in config?
• Add HAProxy PROXY protocol support
• Collect stats (for console display/API purposes)
• Create stats JSON API endpoint
• More coin/algo support
  • Complete Bitcoin/Litecoin/etc stratum module (aiostratum_proxy.protocols.stratum.StratumPoolProtocol & aiostratum_proxy.protocols.stratum.StratumWorkerProtocol)
  • Ethereum (ETH) protocol(s) support?
• ... share your thoughts/ideas

I'd be cautious regarding anyone claiming to continue supporting ZClassic without hearing it from the former ZCL (current BTCP) team directly. Seems like an easy way to scam people into downloading a 'new' wallet/software that lets others steal ZCL balances, etc.

However, if I can add to this on somewhat of a tangent, it would be good if the (ZCL replacement dev team) selection process was made to be transparent. So the public can see who's submitting proposals - in fact, if the proposals were written up as public Github repos/issues/gists, that would be ideal. Keeps all parties honest - otherwise, the BTCP team can just say that 'no one submitted quality proposals' and let ZCL die. Not cool.

With the dstm miner, I was achieving similar hashrates with that card:

+200 core
+1050 mem
115Watt

So, a little more efficient, I think? I was doing 490+ a card, but my wattage was jacked up - very inefficient, so I dialled it back to this.

Don't pools (that support this) allow this through the password field or something like that?

I've moved back to dstm for now - not because of performance (I think there are both positive and negative reports with bminer, so many variables, etc) but because there's not really enough transparent communication. I was super keen and supportive here, but I'm pulling back. I didn't notice any particularly nefarious activity, for those who are wondering.

bminer seems like a solid & stable miner, and I suspect that realbminer thinks he/she's been open and transparent enough, but it's obviously not open enough; people have real questions that aren't being answered. Maybe the random connections are all about devfees and are legit, but then again, maybe not. There have been valid concerns raised by others that I don't feel have been adequately addressed.

I'll definitely keep tabs on this project though. Lots of potential. Good luck with the community management, realbminer! I think if there's improvement on that front, you'll see a major uptake on bminer.

Pardon? There is no 20% founders fee for ZCL. Maybe you misread something?

There is an FAQ page posted with details on this, and literally thousands of people have quoted it wherever some asks this question.

2 hours for me, from Bittrex to Electrum.

If you hold ZCL in a personal wallet like Electrum ZCL, you'll be fine. As your quote above said, you'll need to take an additional step to actually claim your BTCP (using your ZCL wallet private key in the BTCP Wallet, when released). Regardless, in the personal wallet scenario, there's no rush to do anything as you're not particularly time limited.

If holding in an exchange, you'd better make sure it supports the fork, or you won't get the equivalent BTCP at all. Exchanges are taking a while to perform withdrawal requests, so if you need to get it out before the snapshot, you'd better get cooking. If the exchange DOES support the fork, then absolutely no effort is required on you part, apart from being patient! It will take a while before you get your BTCP in this scenario, as I understand it.

While I'm really hoping Bittrex announces support, I've decided to be realistic: I've moved my ZCL to a personal wallet (using Electrum ZCL - remember to do your own research on wallets and decided whether to trust some internet rando's link to a wallet!)

I'm no pro, but I've done a fair bit of digging into protocols, miners, proxies and pool source code. I think that you shouldn't expect to see the exact same adjustment in share submissions when difficulty changes. Think of difficulties as representing submission speed 'brackets'. You'll be set to difficulty X if you submit between n and (n+m) shares - once you exceed (n+m), you'll be set into the next difficulty bracket Y. That sort of thing.


I'm not positive, but it looks like flypool (zcash at least?) isn't vardiff-enabled (variable difficulty)? Meaning, it doesn't dynamically adjust the miner's difficulty, although it allows you to set your own difficulty on miner startup via the password field (defaults to 2000). Can someone correct me if I'm wrong?

Either way, I'm not sure on this. I do know that you shouldn't try to calculate stats on only a minute or two, however. All the advice I've seen is to run a 24+ hour test - even that isn't precise unless you can it on the same hardware at the same time! 


As I mentioned, I'm not sure on flypool being vardiff... I'm interested to hear what you find out, as you dig though!


These are good questions! Keep asking them!

You can't compare share counts/frequency from the miner itself. Depending on a variety of factors (mostly the speed at which you send shares to the pool), the pool will increase the difficulty for your connected miner. Increased difficulty means you find fewer shares, BUT the shares you do find are 'worth more' to the pool (because they were more difficult to find). The overall value of the shares you submit ought to be the same, and the payout the same in those circumstances.

If a miner is better at finding solutions (like dstm is, compared to ewbf), its difficulty will be raised such that it submits fewer shares (lowering the networking requirements) - I'd say this is why when visually comparing ewbf to dstm, you'll see fewer shares being submitted by dstm.

Sounds like it's pretty common? Maybe Remote Desktop uses the GPU itself as well. (see https://www.reddit.com/r/gpumining/comments/7eattb/mining_causes_poor_remote_desktop_teamviewer/)