Payout 387968 sent (a little while ago)
2236d7a9f47035b3b7cb2317b377c43274f6025dd0dbfafbb7c1b271a8a77bf3
but not confirmed yet
Kano, just for information - is this ok that Status field in Account->Payout tab is empty and not updated after each payment? This is not a problem really as payments are regular, but it might be good idea to fix it? Some users I guess not able to track payouts on forum because of limited time but it will be quite convenient to login into your account and to check what is paid and what still not.. |
|
|
|
Thank you Kano! So easy, it works. I've missed command line params related to BTC and instead of this " http://127.0.0.1:8330" string in ckdb log confused me. |
|
|
|
Can someone give advice why ckdb (latest ver from git) can't connect via RPC to local bitcoind (v0.11.2) ? At least I am trying to setup BTC payout address in User settings (web) but got error ERR: Invalid BTC addressFirst time ckdb was not able to connect to standard bitcoind RPC port 8332 as it was hardcoded to 8330 in ckdb.c char *btc_server = "http://127.0.0.1:8330";
char *btc_auth;
I've changed to 8332 and recompiled, it is connected but still no luck [2015-12-12 13:04:28.923+00] _btc_io() btc server response not ok: HTTP/1.0 401 Authorization Required0x0d0x0aDate: Sat, 12 Dec 2015 13:04:28 +00000x0d0x0aServer: bitcoin-json-rpc/v0.11.2.0-g7e278920x0d0x0a
WWW-Authenticate: Basic realm="jsonrpc"0x0d0x0aContent-Type: text/html0x0d0x0aContent-Length: 2960x0d0x0a0x0d0x0a<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
0x0d0x0a"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">0x0d0x0a<HTML>0x0d0x0a<HEAD>0x0d0x0a<TITLE>Error</TITLE>0x0d0x0a<META HTTP-EQUIV='Content-Type'
CONTENT='text/html; charset=ISO-8859-1'>0x0d0x0a</HEAD>0x0d0x0a<BODY><H1>401 Unauthorized.</H1></BODY>0x0d0x0a</HTML>0x0d0x0a0x00
[2015-12-12 13:04:28.923+00] usersettings.userset5111.ERR.Invalid BTC address
I've tried to recompile this again w/ hardcoded username/password in ckdb.c char *btc_server = "http://127.0.0.1:8332";
char *btc_auth = "USER:PASS";
according to snprintf(buf, sizeof(buf), "%s:%s", btc_user, btc_pass);
btc_auth = http_base64(buf);
but the same result, this can't authenticate against bitcoind RPC. Any hints will be highly appreciated. Thanks! ps: ckpool works fine via RPC using user/pass from ckpool.conf , so there is no mistake in user/pass |
|
|
|
I presume it would be just as easy to make a patch that would block all known SPV addresses?
Just wondering.......
Patch or firewall is not a problem, but for example Kano pool is 1.5+ % of total hashrate but F2pool and Antpool is 50% total, this will be not effective at all. It will not hurt giants pool in any noticeable way... They do not care if Kano's pool or any other small pool include their transactions or not. |
|
|
|
Sure, you can alter the client code to block addresses, but you can't just throw some addresses in a configuration file. As you've quoted, it was towards a specific release (Gentoo) and required changes to the underlying core code. I agree that somebody, if motivated enough, could in fact change the code to block kano's address; however, there are a whole lot of somebodies that would have to do the same thing to have a noticeable effect.
It is quite easy to make patch for such filtering and recompile bitcoind, a few hours max. Especially after recent 'dirty' mining talks here, kind of revenge.. |
|
|
|
Kano would a test payment to/from the pool address and a private address confirm any suspicions? I am sure you know how to prove this on your own, I am just curious to know if this would be a way to prove some pools are playing dirty.
Who cares of this proof? Yes, they ignoring Kano's transaction and so what? You will post it on forum and they fix this immediately?  I do not think so. Just we need to be patient and it will be confirmed anyway. |
|
|
|
|
No any probs with confirmation delay, just wondering why it was not included with 0.001 fee in those 10+ blocks
|
|
|
|
So Slush and other relatively fair pools lack blocks
How you can measure this? Pool can be only "fair" or "not fair", there is no intermediate value. Or "relatively fair" means that it stole money once a month? Lol ) |
|
|
|
..Your transaction was ignored because it did not pay enough fee.. What is 'enough fee' at f2pool? Just for info. |
|
|
|
This guy leaked our IP addresses to the public, I pm him kindly and begged him to remove them but he refused.
Are you serious?! Any IP address is PUBLIC and nobody need to have any permit to post this info anywhere. |
|
|
|
|
Try to setup the lowest possible freq in advanced settings just to check if chips will report good state.
It can be power supply issue for sure, PSU in S4 is not really good even replacement revision.
|
|
|
|
So i have a batch 1 S7 that ever since performing the FW update form the site wont hash seems like after a hard reboot and leaving it for a few hours it starts to hash but if I ever power it down the problem starts up again. multiple reboots and nothing the main screen is dead See screen shot  I have also tried to login via SSH with default root/root and i get access denied so I can't even poke around inside to try and review the config files Anyone had any issues like this or can offer advice on how to get in with SSH I would appreciate your help It is root admin, not root root. s5 started the root admin thing. s3 was root root. Thanks I got in but still can't get the stupid thing to start hashing you use dynamic or static address? I use static and 8.8.8.8 dns (Google dns) . I have tried both and use same DNS I have 4 other miners that work fine those I haven't touched trying the new FW. I have tired re-flashing FW multiple times hard power resetting, rebooting, assigning Static IP rebooting router nothing seems to work. Usually after a few hours it start to hash this time its still not hashing after over 12 hrs Sorry for overquoting this but connect BOTH FACTORY FANS as it was from the box! |
|
|
|
|
What are talking about? I do not care of overall diff raise, it is absolutely clear and inevitably.
But about bad luck will be never covered with such raise now +10% per 2 weeks. It is 90% for last months here.
|
|
|
|
|
Exactly, but unfortunately pool luck still not so good for quite a long time. And this loss will be never fully covered later because of huge difficulty raise each time nowdays.
Another issue is poolhoppers in each long round, now they for approx +2-3 PH/s which gone immediately after block found. 2/40 = -5% for long(unlucky) rounds so average -2.5% for all profit.
|
|
|
|
|
0.0001 payment is not from Slush, you may check advertisement message in blockchain in this 0.0001 transaction. Someone decided to pay this to your address and nothing more. Payment from Slush was as predicted.
|
|
|
|
I understand your answer but my message was not about someone's burned miner. Any statements from Bitmain that October firmware SOLVES internet blackout issue? I've just never seen this and that's why the question was. Btw at least it solves possible fan malfunction like posted here https://bitcointalk.org/index.php?topic=1235167.0Actually really bad that Bitmain firmwares do not have any public release notes.. |
|
|
|
There is nothing wrong with the September firmware. The October firmware SUPPOSEDLY fixed the issue with rigs burning up after internet loss. I've seen two people in the forum who have had their units replaced because of burning up after losing interest and they had the October firmware. One of them lost 3 rigs due to burning up after internet loss.
Don't believe the hype about the October firmware. It does not fix that issue. ... I wonder who told you this fact that it solves internet loss issue? At least October firmware protects of fan's malfunction and stops hashing to prevent overheat. Try to disconnect one fan during running and you will see result - it will stop hashing. Anyway this is your own risk and I can't guarantee anything to you as I am not manufacturer. |
|
|
|
|
Show Posts
