Author

Topic: How do custom firmware collect their fees. (Read 516 times)

sr. member
Activity: 446
Merit: 347
January 30, 2022, 12:53:07 PM
#19
Come on, I'm nice, I'll do the work for you, here is the code that allows the S9 to define a frequency and a voltage! you will have no trouble deciphering this, and as you can see, I am not touching cgminer! this code is compatible with all S9 and S9 I/J version with multioption firmware.


Code:
#!/bin/sh

PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/bmminer
NAME=bmminer
DESC="bmminer daemon"
CONFIG_NAME="/config/asic-freq.config"
set -e
#set -x
test -x "$DAEMON" || exit 0

do_start() {
gateway=$(route -n | grep 'UG[ \t]' | awk '{print $2}')
if [ x"" == x"$gateway" ]; then
gateway="192.168.1.1"
fi
if [ "`ping -w 1 -c 1 $gateway | grep "100%" >/dev/null`" ]; then                                                   
prs=1                                               
echo "$gateway is Not reachable"                             
else                                               
    prs=0
echo "$gateway is reachable"
fi                   
sleep 5s
if [ -z  "`lsmod | grep bitmain_axi`"  ]; then
echo "No bitmain_axi.ko"
#insmod /lib/modules/`uname -r`/kernel/drivers/bitmain/bitmain-axi.ko
        insmod /lib/modules/bitmain_axi.ko
                memory_size=`awk '/MemTotal/{total=$2}END{print total}' /proc/meminfo`
                echo memory_size = $memory_size
                if [ $memory_size -gt 1000000 ]; then
                    echo "fpga_mem_offset_addr=0x3F000000"
    insmod /lib/modules/fpga_mem_driver.ko fpga_mem_offset_addr=0x3F000000
                elif [ $memory_size -lt 1000000 -a  $memory_size -gt 400000 ]; then
                    echo "fpga_mem_offset_addr=0x1F000000"
    insmod /lib/modules/fpga_mem_driver.ko fpga_mem_offset_addr=0x1F000000
                else
                    echo "fpga_mem_offset_addr=0x0F000000"
    insmod /lib/modules/fpga_mem_driver.ko fpga_mem_offset_addr=0x0F000000
                fi
else
echo "Have bitmain-axi"
fi
killall -9 bmminer || true
    killall -9 single-board-test || true
    /usr/bin/bmminer --fixed-freq --no-pre-heat --version-file /usr/bin/compile_time --api-listen --default-config /config/bmminer.conf
    single-board-test&
}

do_stop() {
        killall -9 bmminer || true
        killall -9 single-board-test || true
}
case "$1" in
  start)
        echo -n "Starting $DESC: "
do_start
        echo "$NAME."
        ;;
  stop)
        echo -n "Stopping $DESC: "
do_stop
        echo "$NAME."
        ;;
  restart|force-reload)
        echo -n "Restarting $DESC: "
        do_stop
        do_start
        echo "$NAME."
        ;;
  *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload}" >&2
        exit 1
        ;;
esac

exit 0


sr. member
Activity: 446
Merit: 347
January 30, 2022, 12:45:25 PM
#18
With all due respect, if you would just take the trouble to take 5min to download my mod for S9, and look inside... you would find that I didn't modify ANYTHING! but I only call functions ALREADY PRESENT in the cgminer (bmminer), but that, I have already said Smiley
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
January 29, 2022, 09:47:48 PM
#17
honestly, the devfee are sold to give help, and improve the project ... but in reality it is not so, the priority is to fill the pockets !!!

I am the only one to provide real support ... the people who use my firmware will confirm it. Even on SERIES 9, on which I earn absolutely nothing, I help.

I see some users who come to see me because they have absolutely no support from another custom and moreover they are too expensive.

In any case, blocking devfees will never kill a firmware, the man is always empty of money! so there will always be developers trying to make money! and therefore make firmware whatever it costs.
The original code for the S9 has been available for many years.
Why do you violate the license?
sr. member
Activity: 446
Merit: 347
January 28, 2022, 01:26:52 PM
#16
honestly, the devfee are sold to give help, and improve the project ... but in reality it is not so, the priority is to fill the pockets !!!

I am the only one to provide real support ... the people who use my firmware will confirm it. Even on SERIES 9, on which I earn absolutely nothing, I help.

I see some users who come to see me because they have absolutely no support from another custom and moreover they are too expensive.

In any case, blocking devfees will never kill a firmware, the man is always empty of money! so there will always be developers trying to make money! and therefore make firmware whatever it costs.
jr. member
Activity: 44
Merit: 33
January 23, 2022, 04:57:36 AM
#15
It's easy enough to remove the fees from all these illegal firmware.
The people who release them are really not that smart.
Of course I'm certainly not gonna support a bunch of criminals and help people use their firmware ...
So how does one redirect the dev fee. I'm actually using this firmware. I got a really crappy mine, I bought it second hand. Send to bitmain for repair, they scrapped it. I but I used a custom firmware and it sometimes works. So I can at least get some $, but I honestly need all I can get to stay alive
Re-directing or outright blocking the devfee address is not the hard part: the fact that the miner is also looking for those (sucessfull) connections and will stop mining when it no longer gets the correct responses when it tries to switch to the dev pool. In short, it is a software based license key dongle.

I didn't try, but this could be possible with Iptables to redirect traffic and a stratum relay/proxy and some modification in its source code. But If you do that, you will kill the projects, which means there will be no more custom firmware to help with situations like yours.
legendary
Activity: 3822
Merit: 2703
Evil beware: We have waffles!
January 17, 2022, 09:09:30 PM
#14
It's easy enough to remove the fees from all these illegal firmware.
The people who release them are really not that smart.
Of course I'm certainly not gonna support a bunch of criminals and help people use their firmware ...
So how does one redirect the dev fee. I'm actually using this firmware. I got a really crappy mine, I bought it second hand. Send to bitmain for repair, they scrapped it. I but I used a custom firmware and it sometimes works. So I can at least get some $, but I honestly need all I can get to stay alive
Re-directing or outright blocking the devfee address is not the hard part: the fact that the miner is also looking for those (sucessfull) connections and will stop mining when it no longer gets the correct responses when it tries to switch to the dev pool. In short, it is a software based license key dongle.
newbie
Activity: 1
Merit: 0
January 17, 2022, 07:57:17 PM
#13
I tried wireshark I could not catch it



It's easy enough to remove the fees from all these illegal firmware.
The people who release them are really not that smart.
Of course I'm certainly not gonna support a bunch of criminals and help people use their firmware ...
So how does one redirect the dev fee. I'm actually using this firmware. I got a really crappy mine, I bought it second hand. Send to bitmain for repair, they scrapped it. I but I used a custom firmware and it sometimes works. So I can at least get some $, but I honestly need all I can get to stay alive
jr. member
Activity: 44
Merit: 33
Here is the idea,
Since all of the pools is using stratum, and it is clear text. Why not use Wireshark to analyze and find it?
I think they keep this a secret because as kano said it will be easy to redirect all dev fees to your wallet with simple tools available right now.
sr. member
Activity: 446
Merit: 347
February 10, 2021, 01:18:42 PM
#11
It's actually much more difficult since S9 ... because since then, the sources are no longer shared (as it should be) ... in fact, XXXXXXXXXXXXXXXXXX there are leaks, and some have the sources for compile, from this moment, indeed, anything is possible;)
legendary
Activity: 2394
Merit: 6581
be constructive or S.T.F.U
February 10, 2021, 06:13:18 AM
#10
[...]

To be honest, this is off-topic. If you know how they go about collecting fees, please elaborate.

My solution for that is, do not use it.

This isn't a solution, it's more like avoiding the problem, people use custom firmware for a reason, nobody is willing to go through the process of installing custom firmware and pay fees on top of that for the sake of having fun, the stock firmware sucks big time, custom firmware can even fix some miners which is one of the main reasons why I use it, many hash boards report dead on the stock and work just fine with custom firmware, people spend thousands of dollars on these gears, when a custom firmware can fix their broken miner or/and give them the ability to tune it as they wish, they will use it, it's common sense.

If someone want a change, compile your own version, all Information are out there in the wild, you only need the will to do it (don't be lazy).

You are right, but..not everyone has the skills and time to do that, I have not looked into it (probably won't) but the fact that there are only 2-3 major custom firmware out there makes me think that it isn't easy to do because if it was - we would see a thousand different versions and their fees would be a fraction of the large 2% or 4%.

The solution is rather simple, Bitmain makes a proper firmware or we start a fundraise for someone to improve the obsolete Cgminer code, I will be the first to donate.

Until that happens, many people will be "forced" to use custom firmware, I do avoid custom firmware as much as I can, but sometimes you gotta do what you gotta do.
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
February 10, 2021, 04:29:24 AM
#9
That might be right, but I would never trust such a firmware. Most of them make use of the api (thank you for the excelent API-Readme in cgminer). But hiveon secured it extra, so blocking of their comand and control IP, stops the mining in total.

My solution for that is, do not use it. If someone want a change, compile your own version, all Information are out there in the wild, you only need the will to do it (don't be lazy).
legendary
Activity: 4592
Merit: 1851
Linux since 1997 RedHat 4
February 10, 2021, 04:04:49 AM
#8
It's easy enough to remove the fees from all these illegal firmware.
The people who release them are really not that smart.
Of course I'm certainly not gonna support a bunch of criminals and help people use their firmware ...
legendary
Activity: 2394
Merit: 6581
be constructive or S.T.F.U
January 31, 2021, 09:57:00 AM
#7
cgminer (or bmminer) already contains these features, this remains relatively secret in the world of firmware developers ... what can I say:

- no need for xnsub
- unmodified cgminer can do this
- no parallel mining possible (contrary to some claim)
- I analyzed several custom firmware, and all used the same method
- no need to disconnect / reboot to change pool on the fly

I understand that firmware devs would want to keep this a secret, no hard feeling at all, you did well, you at least explained what you don't use, of course, I was hoping to hear about the things you do use, but you at least provided a lot more information than taserz. Huh

This subject is interesting but it isn't really on my list of the things that " I am dying to know", but one day, I might put my Linux pants on and dig deep into it, and then I'll explain this in great detail to the general public. Grin
sr. member
Activity: 800
Merit: 294
Created AutoTune to saved the planet! ~USA
January 29, 2021, 06:33:30 PM
#6
Lightnining. I mean yes and no... All I will say  Tongue
sr. member
Activity: 446
Merit: 347
January 29, 2021, 01:27:42 PM
#5
interesting subject, to do it, I pence to know what I'm talking about here, in fact, no need for xnsub ... cgminer (or bmminer) already contains these features, this remains relatively secret in the world of firmware developers ... what can I say:

- no need for xnsub
- unmodified cgminer can do this
- no parallel mining possible (contrary to some claim)
- I analyzed several custom firmware, and all used the same method
- no need to disconnect / reboot to change pool on the fly

hiding the devfee on the side of the pool is very easy,

before, dollemizer or other, changed pool every 1 or 2 hours I don't know, for a period of 1 or 2 or 3 min ... which created roller coasters on the side of the client's pool because the miner found it disconnect from the client this time ....

To hide, some do it (I do not say nobody: D), it suffices to simply scorch all these times ... imagine 10 seconds every 10min for example with a low diff: D, like that, 10s do not even see on the side of the customer pool! and the minor never seems to disconnect because 10s is really negligible: D and as it is very close, no more roller coaster ...

And yet, I'm not talking about the hidden pool fee of certain firmware: D

I pence, that all these reasons pushed me not to hide mine ... good or bad idea? is being honest? I'm starting to doubt it  Huh

I remain a bit evasive because I don't want to attract lightning: D
legendary
Activity: 2394
Merit: 6581
be constructive or S.T.F.U
January 28, 2021, 04:15:50 PM
#4
It a great idea that you asked kano to chime in with answers, i know he knows his stuff well despite his attitude.

You did indirectly remind me of someone (marc from Asic.to), i sent him a text on telegram, hopefully he will join us here.
legendary
Activity: 3822
Merit: 2703
Evil beware: We have waffles!
January 28, 2021, 10:39:15 AM
#3
Good question.
Posted it to Kano in the Discord room so when he gets up later we should get a solid answer because IMHO he has better knowledge of how the software side of the mining process works than anyone else in the Forum - specifically, how cgminer operates and pools interact with it. I asked him:
Quote
I can see its use for rentals as it is the rental service that hardware is pointed at and the rental service then uses the xnsub flag to fiddle with work sent to the hardware and not have to restart cgminer when a rented miner is given work from a different pool (or something like that?)

But - in the case of devfees, the miners is not pointed at a service. It is pointed at normal pools that do not change out work targets. Sooo, is xnsub actually just opening a 2nd IP connection to the dev pool and periodically shifting work to/from it passing data to/from cgminer with cgminer thinking it is still just connected to the 1 pool?
I'm thinking that it's the latter and there is a 2nd hidden/background IP connection being made similar to have multiple tabs open in a browser. If so that would explain his always referring to xnsub as a (potential) security hole and not a feature. Also asked about #xnonce.

In many ways this is touching on what Slush's "Stratum V2" is aiming to accomplish - in a sense make miners more 'multi-threaded' vs doing just 1 thing pointed at 1 IP address (pool).

edit: I thought this was familiar territory - seems I was in a short discussion here about it a couple years back Further google searches turned up references from Mining Rig Rentals and a couple other rental services about needing the "NiceHash #xnonce cgminer patch"... Search using  "stratum #xnonce"
legendary
Activity: 2483
Merit: 1482
-> morgen, ist heute, schon gestern <-
January 28, 2021, 03:01:24 AM
#2
Well, I looked after one of thoose custom firmwares, after I received a used S9 with hiveon firmware.
On wireshark I could see that it connects to one pools, it was f2 and second to an ip address in germany.
BMminer (CGMiner) does have Mining strategy set to multiple pool, I guess, on the hiveon firmware I could see
that it mines the fee, only the target address where wipped out by displaying just ---- instead of the pool address.
I assume that the IP address is contacted to receive the address of the fee pool, because that might change by
the will of hiveon.
I did not get any further in investigation, as I just wanted to get rid of that custom firmware.
legendary
Activity: 2394
Merit: 6581
be constructive or S.T.F.U
January 27, 2021, 11:23:13 PM
#1
NFW and I started a discussion on dev fees "by accident" on a different unrelated topic, so I thought it would be best if we move the discussion here.

NFW's reply was:

... security hole 'feature' called #xnonce to seamlessly redirect where some shares are received from/sent to (DevPool) without actually resetting/restarting a miner like changing a pool would do. The effect of using #xnonce in that manner does not show up on any miner GUI or monitoring software as all it knows is that the miner is hashing at x speed.

I believe he made a typo there, he likely refers to xnsub. My humble understanding about Xnsub is that it simply eliminates the need to re-connect to the pool with a different extranonce so pools/places like Nicehash can go about their daily business, the extranone (for those who don't know) is used to extend the number of possible hashes (nonce range) a miner can try without repeating the same hashes or runs out of nonce, given that the nonce size can't be larger than 32 bits (4 billion possibilities) with thousands of miners hashing the same block with the same coinbase inputs, overlapping can happen before the value of time changes (which will result in a completely different range of nonce), this means the pool will be wasting hash power.

So according to Statrum protocol during "mining.subscribe/ connection" the pool will send:

Code:
mining.subscribe("user agent/version", "extranonce1")

Switching from pool A to Pool B means you will have to subscribe again to get the new pool's extranonce1, if however, you have xnsub enabled, nicehash for example will be able to pass the new extranonce1 without your miner having to reconnect so potentially you save a few milliseconds of wasted power.

mining.subscribe
mining.subscribe("user agent/version", "extranonce1")
The optional second parameter specifies a mining.notify subscription id the client wishes to resume working with (possibly due to a dropped connection). If provided, a server MAY (at its option) issue the connection the same extranonce1. Note that the extranonce1 may be the same (allowing a resumed connection) even if the subscription id is changed!

With that being said I don't know how would custom firmware utilize xsnub in that way, it is used by the pool itself, the miner can't force the pool to accept it, so if you do happen to mine to a pool that does not support xsnub what is going to happen?

I also noticed that for the gears I have Vnish firmware on my hashrate on the pool does not seem like it was interrupted, unlike when I tested Dollermizer years ago, the hashrate on the pool would look like a mountain range and the periods when the dev pool was on are so easy to spot.

Would love to know how exactly do these custom firmware go about collecting their fees, why some can do it without leaving prints on the main pool while others do? let's share our thoughts and views.
Jump to: