KanoPool since 2014 🐈 - PPLNS and Solo 0.5% fee - Worldwide - 2436 blocks

[huynhdat1989]

See... our hashrate went down and we are getting more lucky and getting more blocks.
we need to keep our hash rate below 27,000TH. 

That is why bitfury is the private pool ^^

[1715160120]

1715160120

[1715160120]

1715160120

[1715160120]

1715160120

[NotFuzzyWarm]

A have a question to kano or some other blockchain or db specialist.

I was under impression that once tx is on the blockchain, even an unconfirmed one, then it is unchangeable.
is this really so, or does current soft allow for some sort of "replacement in kind" with the same numerical outputs for currently unconfirmed transactions?

I seem to remember some noise last year about purchasers having a 10 minute window to cancel the tx. Could that window be related to min time a tx sits in the mempool before being permanently added to a block and therefore the blockchain? A lot of small retailers that do take BTC like diners and coffee shops were upset about that because of some folks getting their goods then walking out the door and canceling the tx...

Don't know if that is right but is what I dismember

[bitsink]

...
Now here's the real fun part ...
It checks for a reply from bitmain and if bitmain replies with anything containing the word "false"
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7755
Then it will abort the checking function
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7777
with the message "Stop mining!!!"
But if it fails to connect to bitmain or it doesn't get a "false" reply, it will continue checking randomly every 1 to 11 minutes connecting to bitmain.

Now I wonder why they would have a function like that, there in the code ... ... ... ... ...

Would it make sense to try to fork the code and update the miner with a new version that eliminates the send_mac and setup_send_mac_socket functions entirely?

I got booted out of the cgminer team - so don't ask me
Ask the cgminer guy who bitmain pays for pretty much all the code he writes

I thought that I read somewhere that it is possible to run a different miner (was it cgminer) on the S9's? The startup scripts also seem quirky and not very robust.

[bitsink]

But that wasn't the reason for wanting to run away screaming ...
There is a function in all your recent bitmain miners "send_mac"
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7764
It connects to bitmain
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7683
Since AUTH_URL is:
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L223
"auth.minerlink.com"
and it sends your mac address, some miner id, and some hash board id string to bitmain
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7774
Randomly every 1 to 11 minutes while the miner is running
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7783
It doesn't matter what pool you are mining on, it still connects to bitmain

Now here's the real fun part ...
It checks for a reply from bitmain and if bitmain replies with anything containing the word "false"
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7755
Then it will abort the checking function
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7777
with the message "Stop mining!!!"
But if it fails to connect to bitmain or it doesn't get a "false" reply, it will continue checking randomly every 1 to 11 minutes connecting to bitmain.

Now I wonder why they would have a function like that, there in the code ... ... ... ... ...

I might just block "auth.minerlink.com" at DNS and my router in preparation for when it starts to resolve?

Or perhaps it's just something they utilise at hashnest to manage their miners.

Good idea! A simple entry in the "hosts" file pointing to 127.0.0.1 will do  

This will do in /etc/hosts:

Code:

127.0.0.1       localhost.localdomain           localhost
127.0.0.1       auth.minerlink.com              auth

[kano]

A have a question to kano or some other blockchain or db specialist.

I was under impression that once tx is on the blockchain, even an unconfirmed one, then it is unchangeable.
is this really so, or does current soft allow for some sort of "replacement in kind" with the same numerical outputs for currently unconfirmed transactions?

An unconfirmed transaction isn't in the blockchain.
It's simply in the mempool of anyone who has accepted it.
From the point of view of it ever getting in the blockchain, it must be in the mempool of (some) miners and they must include it in a block they find (and it must not be orphaned) e.g. a pool - kano.is

There's also:

1) RBF (replace by fee) was implemented by core - yep many may not realise that you can replace a transaction with a higher fee.
Bad idea in my opinion, but no one got to decide that, core just added it in.

2) Maleability. There is a minor fix for this here already in core for 1x transactions.
However P2SH (3x transactions) is plagued with this due to the design flaws in it.
That's basically what segwit is a poor solution for - poor since it is also full of 'core profit' motivated code, not just a maleability fix.

Maleability means anyone can change a transaction identifier to produce the same transaction result (same inputs and outputs) by modifying something in the transaction that does not depends on proof of ownership of the inputs.

[Biodom]

A have a question to kano or some other blockchain or db specialist.

I was under impression that once tx is on the blockchain, even an unconfirmed one, then it is unchangeable.
is this really so, or does current soft allow for some sort of "replacement in kind" with the same numerical outputs for currently unconfirmed transactions?

An unconfirmed transaction isn't in the blockchain.
It's simply in the mempool of anyone who has accepted it.
From the point of view of it ever getting in the blockchain, it must be in the mempool of (some) miners and they must include it in a block they find (and it must not be orphaned) e.g. a pool - kano.is

There's also:

1) RBF (replace by fee) was implemented by core - yep many may not realise that you can replace a transaction with a higher fee.
Bad idea in my opinion, but no one got to decide that, core just added it in.

2) Maleability. There is a minor fix for this here already in core for 1x transactions.
However P2SH (3x transactions) is plagued with this due to the design flaws in it.
That's basically what segwit is a poor solution for - poor since it is also full of 'core profit' motivated code, not just a maleability fix.

Maleability means anyone can change a transaction identifier to produce the same transaction result (same inputs and outputs) by modifying something in the transaction that does not depends on proof of ownership of the inputs.

....interesting
I had a tx that was not confirmed for 40-48 hr or so, but i could see it's tx id on both blockchain.info and blocktrail.
Suddenly, it disappears altogether and shortly, but not immediately, there is another tx id and tx is immediately confirmed, but timestamped at the second occurrence. All inputs/outputs are the same.
What could have happened?
Someone just picked up this tx, but timestamped it as a current one?
Blockchain fixed itself? LOL

[kano]

A have a question to kano or some other blockchain or db specialist.

I was under impression that once tx is on the blockchain, even an unconfirmed one, then it is unchangeable.
is this really so, or does current soft allow for some sort of "replacement in kind" with the same numerical outputs for currently unconfirmed transactions?

An unconfirmed transaction isn't in the blockchain.
It's simply in the mempool of anyone who has accepted it.
From the point of view of it ever getting in the blockchain, it must be in the mempool of (some) miners and they must include it in a block they find (and it must not be orphaned) e.g. a pool - kano.is

There's also:

1) RBF (replace by fee) was implemented by core - yep many may not realise that you can replace a transaction with a higher fee.
Bad idea in my opinion, but no one got to decide that, core just added it in.

2) Maleability. There is a minor fix for this here already in core for 1x transactions.
However P2SH (3x transactions) is plagued with this due to the design flaws in it.
That's basically what segwit is a poor solution for - poor since it is also full of 'core profit' motivated code, not just a maleability fix.

Maleability means anyone can change a transaction identifier to produce the same transaction result (same inputs and outputs) by modifying something in the transaction that does not depends on proof of ownership of the inputs.

....interesting
I had a tx that was not confirmed for 40-48 hr or so, but i could see it's tx id on both blockchain.info and blocktrail.
Suddenly, it disappears altogether and shortly, but not immediately, there is another tx id and tx is immediately confirmed, but timestamped at the second occurrence. All inputs/outputs are the same.
What could have happened?
Someone just picked up this tx, but timestamped it as a current one?
Blockchain fixed itself? LOL

A transaction doesn't actually have a timestamp.
A "blockchain site" is probably showing the first time they saw or added the transaction.
So if the txid didn't actually change, it doesn't make any difference what "timestamp" they show.

The 'replacement' transaction, if it did have a different txid, would depend on which of the above I mentioned it was, if the 'replacement' transaction creator wasn't the one who owns the inputs.

However, there's another option I didn't mention, since that is under the control of whoever created the transaction
After a certain amount of time, a non-confirmed transaction can become abandoned - thrown out of the mempool.
In this case, you can effectively replace the transaction with a completely new one, similar or completely different, reusing some or all of the old inputs.

[kano]

...
Now here's the real fun part ...
It checks for a reply from bitmain and if bitmain replies with anything containing the word "false"
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7755
Then it will abort the checking function
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7777
with the message "Stop mining!!!"
But if it fails to connect to bitmain or it doesn't get a "false" reply, it will continue checking randomly every 1 to 11 minutes connecting to bitmain.

Now I wonder why they would have a function like that, there in the code ... ... ... ... ...

Would it make sense to try to fork the code and update the miner with a new version that eliminates the send_mac and setup_send_mac_socket functions entirely?

I got booted out of the cgminer team - so don't ask me
Ask the cgminer guy who bitmain pays for pretty much all the code he writes

I thought that I read somewhere that it is possible to run a different miner (was it cgminer) on the S9's? The startup scripts also seem quirky and not very robust.

A scammer who mined here, and had a short run of luck, but his total luck mining on the pool was actually below 100%, "produced" a closed source S9 implementation that also talked to his own web site.
Yeah, really not worth the risk of going down that path at all.
His scamming was the ridiculous claims he made about making the miner something like 16% luckier ... to get people to use "his version"
Thus, no I wont provide a link (and would delete any such links)

[NotFuzzyWarm]

re: https://bitcointalk.org/index.php?topic=789369.msg18083086#msg18083086 (s9's phoning home?)
Since you just brought up He Who Is Not To Be Named, I do have to mention that he found that bit of code last year. As far as he could tell it did not actually do anything but one of his mods was to remove the code.. However, still worrying though...

My take on the code: If folks here remember, think it started with the s4 and was definitely in at least the early s5's. Bitmain for a time looked at a central Cloud control/monitoring solution for us using their miners. The site name? Minerlink.com In the Bitminer GUI they had a tick-box to use that service.

Don't think they ever took it active outside China. Just looked and the site is still there but have not seen that tickbox on any s9 or s7 as far as I can recall. Hmm.

Question still remains, is that code benign and just unused legacy? Considering how much Bitmain says they re-wrote all the code in the s9's ya gotta wonder how that got left in...

[kano]

re: https://bitcointalk.org/index.php?topic=789369.msg18083086#msg18083086 (s9's phoning home?)
Since you just brought up He Who Is Not To Be Named, I do have to mention that he found that bit of code last year. As far as he could tell it did not actually do anything but one of his mods was to remove the code.. However, still worrying though...

My take on the code: If folks here remember, think it started with the s4 and was definitely in at least the early s5's. Bitmain for a time looked at a central Cloud control/monitoring solution for us using their miners. The site name? Minerlink.com In the Bitminer GUI they had a tick-box to use that service.

Don't think they ever took it active outside China. Just looked and the site is still there but have not seen that tickbox on any s9 or s7 as far as I can recall. Hmm.

Question still remains, is that code benign and just unused legacy? Considering how much Bitmain says they re-wrote all the code in the s9's ya gotta wonder how that got left in...

The code does exactly as I stated, my running commentary and links are not guesses
Although -ck threw me off the ckpool and cgminer team for stating that I have a lot of experience
(I also have more than him - but his medical god status got upset at that comment and he threw a public tantrum about it)
I do know more about coding/programming than most.

The code in git is benign if bitmain keeps the DNS A record missing as it currently is.
It's only a one line change to their DNS to enable and disable it.
When you enable a missing DNS A record it is usually an almost immediate activation.

However, the git vs the code running in your Bitmain miners ... there's certainly no guarantee that's exactly the same either.
The git shows one inital commit and one change since then.
Seriously would anyone think there was only the one original commit and only one change ever since that?

[NotFuzzyWarm]

Ja. Especially considering how much Bitmain has dicked around with a plethora of Firmware updates...

I know I certainly wonder Bitmain did with their software in latest R4 and s9's. Looking at hash rate reported by Awesome miner shows a very uncharacteristic smoothness vs what I normally see from s7's and earlier s9's. Think it's a s9 b22 I have at work that displays like the R4's do.

This shows my 2 R4's and Batch-1/b3 s9's at home. No way in hell are the R4's performing THAT evenly. BMminer 2.0 must be doing major stats smoothing of some sort and given that, who knows what else.

[firetreeactual]

Seriously would anyone think there was only the one original commit and only one change ever since that?

Of course no one (with a pulse) believes that. I'm not exactly happy with how all that came down with Con, but it's not my "stuff" (thankfully) and given my former profession, that's a blessing (for me, at least). Anyway...that sequence of events (which happened to include you as collateral damage, it seems to me) is what led me to mine only here, and to not buy Bitmain gear again. I don't sleep a heckuva lot anyway, but choices like these at least make those power naps a lot more peaceful.

Mine on.  

[ComputerGenie]

Ja. Especially considering how much Bitmain has dicked around with a plethora of Firmware updates...

Most of that was in a vain attempt to strike a balance between how a high-performance miner should operate and how hobbits, running it 4' from their bed, want it to run.

[tbonetony]

Now here's the real fun part ...
It checks for a reply from bitmain and if bitmain replies with anything containing the word "false"
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7755
Then it will abort the checking function
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7777
with the message "Stop mining!!!"
But if it fails to connect to bitmain or it doesn't get a "false" reply, it will continue checking randomly every 1 to 11 minutes connecting to bitmain.

Now I wonder why they would have a function like that, there in the code ... ... ... ... ...

kano, would this give them the capability to remotely shutdown one's miner? For now it's just logging but if this condition works, who knows what else they will extend it to.

and if that day comes, maybe I have to block such connection on the router?

[kano]

Now here's the real fun part ...
It checks for a reply from bitmain and if bitmain replies with anything containing the word "false"
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7755
Then it will abort the checking function
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7777
with the message "Stop mining!!!"
But if it fails to connect to bitmain or it doesn't get a "false" reply, it will continue checking randomly every 1 to 11 minutes connecting to bitmain.

Now I wonder why they would have a function like that, there in the code ... ... ... ... ...

kano, would this give them the capability to remotely shutdown one's miner? For now it's just logging but if this condition works, who knows what else they will extend it to.

and if that day comes, maybe I have to block such connection on the router?

Well the real issue related to that is: what code do they actually have in the miner?
As it is in git, it's effectively benign, just possible (with a minor DNS change) to have every recent Bitmain miner log information to Bitmain.

They delayed creating the git beyond the license requirements (even though creating the git is a few minutes effort)
Who knows what they're up to

Blocking it isn't trivial.
Updating the hosts file as suggested above by bitsink will block it until a power cycle.
But you don't know what the actual address will be, so you can't block that IP in advance at your router as such without whitelisting instead.

[NotFuzzyWarm]

Hmm, just had a thought: When I got my 1st Avalon 721's I had Antpool as my #3 failover. The Avalons could not connect to it. Think Bitmain might use that code to identify if their product is connected to the pool? Last time I ran my rare A1 Dragon clone from AMT it connected but that was around 2 yrs ago... (and truthfully Antpoo not liking Avalons does not break my heart)

[kano]

Hmm, just had a thought: When I got my 1st Avalon 721's I had Antpool as my #3 failover. The Avalons could not connect to it. Think Bitmain might use that code to identify if their product is connected to the pool? Last time I ran my rare A1 Dragon clone from AMT it connected but that was around 2 yrs ago... (and truthfully Antpoo not liking Avalons does not break my heart)

Well, firstly they'd have to have a DNS A record - which I don't check that address, but I gather it may usually not exist.

They can just look at the agent information you supply when you connect to the pool and be pretty sure it's a Bitmain miner, if it's directly connected to the pool, so I doubt they'd bother doing that.

If it was a proxy of miners, then there's all sorts of issues about if any of the miners can get out to the net, how many there are vs the hash rate, etc.

All in all, pretty pointless.

[bitsink]

Now here's the real fun part ...
It checks for a reply from bitmain and if bitmain replies with anything containing the word "false"
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7755
Then it will abort the checking function
 https://github.com/bitmaintech/bmminer/blob/master/driver-btm-c5.c#L7777
with the message "Stop mining!!!"
But if it fails to connect to bitmain or it doesn't get a "false" reply, it will continue checking randomly every 1 to 11 minutes connecting to bitmain.

Now I wonder why they would have a function like that, there in the code ... ... ... ... ...

kano, would this give them the capability to remotely shutdown one's miner? For now it's just logging but if this condition works, who knows what else they will extend it to.

and if that day comes, maybe I have to block such connection on the router?

Well the real issue related to that is: what code do they actually have in the miner?
As it is in git, it's effectively benign, just possible (with a minor DNS change) to have every recent Bitmain miner log information to Bitmain.

They delayed creating the git beyond the license requirements (even though creating the git is a few minutes effort)
Who knows what they're up to

Blocking it isn't trivial.
Updating the hosts file as suggested above by bitsink will block it until a power cycle.

I beg to differ: The hosts file DOES survive a power cycle (at least on a S9 13.5TH model wih the XILINX controller), but would not survive a hard reset without a hack... but obviously this is only a hack. What is the longterm solution? It must be possible to use a different miner all together with the right driver / interface if this is documented?

[bitsink]

Thanks kano for your pool! Seems like a good place. I am struggling though, unable to get some basic stats apart from the current (very rounded) hashrate. A simple graph like eligius had would be nice to have and give some piece of mind about past performance. I also have not yet quite worked out the payout scheme and any minimas. Where may I read up on that?

You could abuse cacti to draw monthly and/or weekly graphs based on data from your address.php - if this data were more accurate and parseable, it is also something that user may do herself. I can offer to do this locally if you make the data accessible and you could then implement it in the pool?

[agentcash]

Workers > Shift Graph   put "all" without quotes in input box, make sure it's checked and hit update

Edit: if you mean for the whole pool Pool > Graph