Interesse - aber keine Möglichkeit eine PM zu schreiben. Ebenso Umfeld Zueri.
So ein Mist. Nachdem sich bisher niemand gemeldet hat, war ich gerade beim Recyclinghof und habe die PDUs bei Elektroschrott abgegeben. Tut mir sehr leid, ganz schlechtes timing. Sorry, Zefir |
|
|
|
Hallo zusammen, mined heutzutage noch jemand im deutschsprachigem Raum? Ich musste meine Mine vor langem abschalten und habe aus der Zeit noch 13x 22kW PDUs, die ich gegen Gebot zur Abholung in der Schweiz (Zürcher Oberland) anbiete. Es handelt sich dabei um das Modell NKP-DY-U, welches von Kejia Automation ( http://www.kejia.com/) produziert wird. Die PDUs verteilen 32A-400V auf 18xC13, also 6xC13 pro Phase, wobei jede Phase von einer C-32A Sicherung von Schneider Electric abgesichert ist. Ich habe die PDUs mit einer Auslastung von 6kW pro Phase 24/7 für etwa ein halbes Jahr betrieben. Bilder poste ich bei Bedarf, wie das Gerät in etwa aussieht, kann man z.B. bei diesem Produkt auf alibaba sehen. Das Gerät ist mit CE und VDI versehen, Verkauf erfolgt von privat an privat. Fragen beantworte ich hier oder per PM, Interessenbekundung bis zum 16.03. bitte per PM. |
|
|
|
With deep regret I have to confirm the OP's scam accusation claims. One of the previously most competent and respected member of this community collected a lot of money from me and other investors, burnt it, and finally ceased communication and disappeared. DeathAndTaxes: a legendary member and former mainstay of our communityI took notice of DaT late 2011 after I started building my first GPU based rigs and stumbled upon some of his posts in this forum. What stroke me immediately was the quality and completeness of his technical analyses and explanations and the solidity of his argumentation. Over the years while mining technology evolved over FPGA to ASIC, people were losing coins to online wallets over ponzis to exchanges and securities, and while bitcoin itself evolved, it was hard to find any relevant discussion where DaT did not contribute with valuable input. While I focused myself on the technical side of mining and over time found it very difficult to keep up-to-date even with this narrow sub-topic, DaT always seemed capable of following any development in the bitcoin world. Take a look at his essay supporting block-size increase as an example of his contribution. If you check the forum stats, you will notice that DaT contributed over 16k posts and with that is the 8th most active poster of all times - even half a year after he stopped posting. For me, Gerald was one of the (if not the) most competent fellow(s) and with that a mainstay for this community - and for sure I know that I have not been the only one with that impression. Ironically, if you search the 'scam accusation' sub-forum, you'll find him involved as mediator or in other trust-centric functions. But that was then, and the expensive lesson I and the other investors had to learn is that a brilliant and sane mind does not imply it is also a honest one. The BitSimple fiascoSomewhere in early January 2014 (during a chat about immersion cooled high-density ASICs) DaT incidentally told me that he was collecting money for a seed funding of his BitSimple exchange service. I did not even thought about it twice but agreed to buy what is left and ended with 390k from a total of 1200k series A shares. With the total sum of $600k collected, my payment was a $195k equivalent in BTC. Iirc, all of the handful investors paid in BTC, which made this seed funding the first processed completely in the BTC domain. Shares were managed by the gust platform. I was very well aware of the involved risk, but at the same time I felt it is not worse than putting my coins into pre-orders of mining equipment or into doubious bitcoin companies. After being defrauded and betrayed by so many, my hope was straight and simple: if there is one person to remain honest, it must be DaT - if he did not, it was time to leave this community.What happened thereafter is what OP is reporting. I was very disappointed to realize that Gerald managed to spend the collected funds mostly to pay his employed family-members - even if most of the time the exchange was not operational due to a missing bank account. Even if this might be legal, it is very unethical and puts him and his intentions in a very suspicious light. Still, I was willing to accept this as business failure when the company is dissolved and remaining assets were distributed to investors (which would give us back some 15%). But shortly after the investors agreed to do so, DaT stopped communicating and is not reachable any more for the past 6 months. This is a sad ending for a bright shining star. You too, Gerald? |
|
|
|
ty who ever fixed it  . You're welcome (I mumbled the magic words a couple of times) This time it looks like yesterday someone pointed 2PH to eligius and since then hit 4 of the last 8 blocks found by the pool. |
|
|
|
Has there been anything from the board? I can't believe that these guys are just sitting on their hands doing nothing...
What is the board expected to do? We have been duped as everybody else and most of us lost all of our BTC denominated holdings - the biggest losers of all, so to speak  Jutarul traveled HK and investigated situation on site for weeks without positive outcome. Only thing left to do is to throw more good money after the bad for legal processing with practically zero chances of any return. This ship sailed and with it the supposed idealism of bitcoin as a whole. selling ~550 shares of ASICMINER for 0.055 BTC
Are you missing a zero here? |
|
|
|
With the latest builds of bitcoind
Anything obviously wrong? I'll debug and report back if not, just to be sure it is not some silly mistake at my side.
bitcoind rpc allow command changed Ok, did some tracing to narrow down the issue. First off, it is not a bitcoind misconfiguration problem, since localhost always works (double checked using RPC interface over curl). I observe that in function read_socket_line() in line ckpool.c:455 the recv() function returns 0 when 'validateaddress' is called after 'getblocktemplate' returned a very large response over the socket. Following manpage, a return value of 0 for recv() has to be interpreted as 'peer has performed an orderly shutdown' which is not handled in read_socket_line(). Question remains why bitcoind is closing the socket, but at least this has to be handled accordingly by ckpool. This is my debug log: [2015-03-24 23:40:56] Opening /tmp/ckpool/generator
[2015-03-24 23:40:56] Unlinked /tmp/ckpool/generator to recreate socket
[2015-03-24 23:40:56] Opened server path /tmp/ckpool/generator successfully on socket 5
[2015-03-24 23:40:56] File /tmp/ckpool/generator.pid exists
[2015-03-24 23:40:56] Opening /tmp/ckpool/stratifier
[2015-03-24 23:40:56] Unlinked /tmp/ckpool/stratifier to recreate socket
[2015-03-24 23:40:56] Opened server path /tmp/ckpool/stratifier successfully on socket 7
[2015-03-24 23:40:56] File /tmp/ckpool/stratifier.pid exists
[2015-03-24 23:40:56] Opening /tmp/ckpool/connector
[2015-03-24 23:40:56] Unlinked /tmp/ckpool/connector to recreate socket
[2015-03-24 23:40:56] Opened server path /tmp/ckpool/connector successfully on socket 8
[2015-03-24 23:40:56] File /tmp/ckpool/connector.pid exists
[2015-03-24 23:40:56] ckpool stratifier starting
[2015-03-24 23:40:56] Opened client path /tmp/ckpool/listener successfully on socket 6
[2015-03-24 23:40:56] Listener received ping request
[2015-03-24 23:40:56] ckpool generator starting
[2015-03-24 23:40:56] Closing file handle 6
[2015-03-24 23:40:56] Attempting to connect to bitcoind
[2015-03-24 23:40:56] Listener received ping request
[2015-03-24 23:40:56] Opened client path /tmp/ckpool/listener successfully on socket 6
[2015-03-24 23:40:56] Closing file handle 6
[2015-03-24 23:40:56] Closing file handle 6
[2015-03-24 23:40:56] Opened client path /tmp/ckpool/generator successfully on socket 6
[2015-03-24 23:40:56] Closing file handle 6
[2015-03-24 23:40:56] ckpool connector starting
[2015-03-24 23:40:56] Succeeded delayed connect
[2015-03-24 23:40:56] json_rpc_call: REQ: {"method": "getblocktemplate", "params": [{"capabilities": ["coinbasetxn", "workid", "coinbase/append"]}]}
[2015-03-24 23:40:57] json_rpc_call: RESP: OK
[2015-03-24 23:40:57] Discarding:
[2015-03-24 23:40:57] MH0 dba90ae1e4c98ae65e07baa18c5735015a3850ea2db3771a71f193647966e278
[2015-03-24 23:40:57] MH1 928e668d417d547bbfc3237e727abdb5f81ff5a1d9a587afa7500697720f5917
[2015-03-24 23:40:57] MH2 23f8815bcb4b8275b0242b6cca6d844daa2e2398cbfb8c2fa721ac23197846ec
[2015-03-24 23:40:57] MH3 357c2632b29c0a71845aa3aed3c74f907a797095b1229957dbce378753c8db5c
[2015-03-24 23:40:57] MH4 d962fe3ba85ef5b919c90ceb9c5fb898e78f1f5df025ed280666dedd6c03f94f
[2015-03-24 23:40:57] MH5 0f3b07341144ef4290d0bbe8170fa45cc975a091a2816fa9fdb30367dd25634f
[2015-03-24 23:40:57] MH6 116582e86cae9fbf0df80bf929bce816743f05a9984389d8908eb2ca71e6f7f5
[2015-03-24 23:40:57] MH7 1a25a3929cdab41e9be026884027dec5835bbe4780f61810073d7fdacf8a9cf2
[2015-03-24 23:40:57] MH8 3175f8961f699a1f160497568cb86960d6d3ea30c346b777da9506b48cbdc0d9
[2015-03-24 23:40:57] MH9 5ea864a0f2a6752e545e05388ebd63664a592a770455340b0264905dd35635c2
[2015-03-24 23:40:57] Stored 540 transactions
[2015-03-24 23:40:57] json_rpc_call: REQ: {"method": "validateaddress", "params": ["14BMjogz69qe8hk9thyzbmR5pg34mVKB1e"]}
[2015-03-24 23:40:57] Failed to recv in read_socket_line: 0/0/Success
[2015-03-24 23:40:57] Closing file handle 6
[2015-03-24 23:40:57] Failed to read socket line in json_rpc_call
[2015-03-24 23:40:57] Reopening socket to 192.168.0.14:8332
[2015-03-24 23:40:57] Succeeded delayed connect
[2015-03-24 23:40:57] Failed to get valid json response to validate_address with errno 115: Operation now in progress
[2015-03-24 23:40:57] Invalid btcaddress: 14BMjogz69qe8hk9thyzbmR5pg34mVKB1e !
[2015-03-24 23:40:57] Closing file handle 6
[2015-03-24 23:40:57] CRITICAL: No bitcoinds active!
The modified error message gives ret/errno/strerror(errno), added with diff --git a/src/ckpool.c b/src/ckpool.c
index 1ffe45f..4df333a 100644
--- a/src/ckpool.c
+++ b/src/ckpool.c
@@ -457,7 +457,7 @@ int read_socket_line(connsock_t *cs, const int timeout)
/* Closed socket after valid message */
if (eom)
break;
- LOGERR("Failed to recv in read_socket_line");
+ LOGERR("Failed to recv in read_socket_line: %d/%d/%s", ret, errno, strerror(errno));
ret = -1;
goto out;
}
@@ -678,6 +678,7 @@ json_t *json_rpc_call(connsock_t *cs, const char *rpc_req)
json_t *val = NULL;
int len, ret;
+ LOGDEBUG("json_rpc_call: REQ: %s", rpc_req);
if (unlikely(cs->fd < 0)) {
LOGWARNING("FD %d invalid in json_rpc_call", cs->fd);
goto out;
@@ -738,6 +739,9 @@ json_t *json_rpc_call(connsock_t *cs, const char *rpc_req)
val = json_loads(cs->buf, 0, &err_val);
if (!val)
LOGWARNING("JSON decode failed(%d): %s", err_val.line, err_val.text);
+ else
+ LOGDEBUG("json_rpc_call: RESP: OK");
+
out_empty:
empty_socket(cs->fd);
empty_buffer(cs);
Will dig deeper tomorrow, just to leave here as probable bug report. |
|
|
|
With the latest builds of bitcoind
Anything obviously wrong? I'll debug and report back if not, just to be sure it is not some silly mistake at my side.
bitcoind rpc allow command changed Ouch, so a running bitcoin-cli on localhost does not necessarily mean bitcoind is configured properly for every client on localhost? Thanks for the hint, will check later today. |
|
|
|
With the latest builds of bitcoind and ckpool, I am stuck with the following problem: [2015-03-23 09:34:58] ckpool generator starting
[2015-03-23 09:34:58] ckpool stratifier starting
[2015-03-23 09:34:58] ckpool connector starting
[2015-03-23 09:34:58] Failed to recv in read_socket_line
[2015-03-23 09:34:58] Failed to read socket line in json_rpc_call
[2015-03-23 09:34:58] Reopening socket to localhost:8332
[2015-03-23 09:34:58] Failed to get valid json response to validate_address with errno 115: Operation now in progress
[2015-03-23 09:34:58] Invalid btcaddress: 14BMjogz69qe8hk9thyzbmR5pg34mVKB1e !
[2015-03-23 09:34:58] CRITICAL: No bitcoinds active!
What puzzles me is that I had ckpool running some time ago, i.e. the configuration files used should be correct. Still, it seems it is not a common problem. I double checked that configurations should match by doing the rpc commands manually: zefir@PC:~/work/bitcoin/src$ ./bitcoin-cli -rpcconnect=localhost -rpcport=8332 -rpcuser=rpc -rpcpassword=pass validateaddress 14BMjogz69qe8hk9thyzbmR5pg34mVKB1e
{
"isvalid" : true,
"address" : "14BMjogz69qe8hk9thyzbmR5pg34mVKB1e",
"scriptPubKey" : "76a91422ddd9233f44ac2e9f183ec755adf134c12cdbf188ac"
}
which should mimic what ckpool should be doing with the configuration of {
"btcd" : [
{
"url" : "localhost:8332",
"auth" : "rpc",
"pass" : "pass",
"notify" : false
}
],
"logdir" : "/home/zefir/tmp/ckpool-log"
}
Anything obviously wrong? I'll debug and report back if not, just to be sure it is not some silly mistake at my side. |
|
|
|
[...] If you have the time - please do PM me the details [...]
Or even better: post the details publicly and enable pool operators and miners to establish a standard for an objective and common luck measure. |
|
|
|
SP20 bulk setup mini-HOWTOWhile setting up my SP20 mini-farm, I tried to figure a process to speed up the config steps usually required to perform over the Web-UI. The following might be useful for you if you need to configure a batch of SP20 devices with the same configuration. Please ignore if this has been posted already. Step 1: FW upgradeIf your units are freshly delivered, upgrade all to latest (mine was 2.6.1) Step 2: configure your reference unita) If you need non-standard cgminer configuration (e.g. API access from your monitoring server), ssh into unit and modify /etc/cgminer.conf.template to your needs. b) configure the reference unit; this scheme covers: root password, UI password, pool settings, HW settings c) start cgminer and ensure the unit is mining according to the desired configuration Step 3: grab reference config filesa) on your (Linux) PC, create a fresh directory and cd into it b) scp from your reference unit the following files - /etc/cgminer.conf
- /etc/cgminer.conf.template
- /etc/mg_custom_mode_sp20
- /etc/shadow
- /etc/ui.pwd
Step 4: bulk clone configsa) scp all files to your remaining units (root/root) Step 5: start the farma) open each unit in Web-UI (use the UI password set in step 2) b) start cgminer The process improvement is marginal for up to 5 units, but worth if you deal with 10+. It is also less error-prone and can serve as template for automated processing. Happy mining!
|
|
|
|
Thanks, worked - one just needs to RTFM  . This is how the luck developed since eligius started mining, averaged over 300 and 1000 blocks:  The feeling that luck got awfully bad over the past two moths is not cheating us. At the same time, it was worse 10 months ago. Let's hope we saw the bottom. |
|
|
|
That sounds about right. According to organofcorti's blog, our average time to find a block over the last 3 weeks (Jan 04-24 inclusive) is 1.2x, 1.2x and 1.42x the expected value, which is 78.5%. It's been a bad start to the year.
Thank you for pointing me to that. What is interesting to note is that recently all major evaluated pools ran into bad luck. Looking back around one year, we see how bad luck and good luck pools were par - which is what one would expect. Today, all of the pools are significantly unlucky (over 1.2). How probable it can be that a set of pools worth 50PH are unlucky - individually and as a set? Variance aside, there has been a monotonic down-trend in the luck over the past year - unless I knew better I'd suspect either a systematic error in how the statistics are collected or something very fishy is going on. I'll try to get some feedback on that from organofcorti before starting conspiracy. Which leaves 1.87 % of withholding hashing power for the pool lifetime assuming it is a long enough time frame (which I think it is)
Thanks man (or should I say: bash-guru  ), that was exactly what I was looking for. Kudos for instead of asking for CSV data, extract it from the website (small fix: your command for the last 3000 has a typo). Your results show exactly what I suspected my feelings are cheating me: while the all-time average seems ok, the luck is monotonically getting worse. Compare any series of the last N blocks to the previous one to see what I mean. Must be missing something... |
|
|
|
I need some help to correctly interpret the pool statistics. To my understanding, the round luck expresses the ratio of spent shares to solve a block. While intuitive as immediate value, it is not suitable for intuitive statistical analyses. Take e.g. the following series of luck values (real ones starting from block 338694): - 137.70%
- 3971.90%
- 18.20%
- 393.70%
Looks not so bad at first sight - makes one think the sub 20% one is well compensated by the lucky ones. But truth is, you need to average over the reciprocal values to get the combined luck of a series, formally: luck(n1..nk) = 1 / [(1/n1 + 1/n2 + ... + 1/nk) / k]For the above example we get the series luck calculated as 1 / [(0.726 + 0.025 + 5.495 + 0.254)/4] = 1 / [6.5/4] = 61.54%If my assumption is correct, then this was a quite bad luck series. Talking variance: shouldn't the average over a longer series be close to 100%? I manually typed the round lucks for the last 100 blocks into a spreadsheet for closer inspection. The averaged luck over this series (covering last ~3 weeks of mining) is 78.74% - which I found shocking low since variance should be leveled out quite well. I disbelieve this number that much that I assume my interpretation is just wrong. Anyone with better understanding willing to comment? @wizkid: are those numbers at http://eligius.st/~wizkid057/newstats/blocks.php available in CSV or JSON format? Thanks |
|
|
|
Modifying cgminer or bfgminer to drop every block not going to pool X with a probability of Y is a one liner to code. If done in closed-source products, the exposure risk is basically zero. We would need organofcorti here to give us reliable numbers on how long you would need to collect statistics to have an indication that a 1TH machine is withholding blocks. Since you are not dropping low-difficulty shares but only blocks, I'd assume it would be impossible to detect a malicious behavior even with a pool of 100 units. So technically, what you describe is absolutely and trivially doable. Above that, everything is conspiracy Fight this easily by not using closed-source products and deploy them with FW you built from source yourself. And if you can afford, do solo-mine - pools are in fact quite unlucky recently... |
|
|
|
Wow, 11,000TH at 21 hours and still no found block. Is this a new record?
It doesn't matter to me, with my mighty 140GH, but I do pity the other bigger setups.
EDIT: Heh, just popped. I wouldn't be surprised if we have awesome luck now.
Unfortunately, you leaving the pool did not help I am pointing my 'bigger setup' to eligius and still hope that the recent series of bad luck will be over some day - but this is eating up my reserves. Started mining again a month ago, found 4 blocks, got 40 coins paid out so far. I know variance, luck, and all, but looking at the series of sub 30% blocks I seriously hope that there are measures in place to detect and fight block withholding. Price for BTC declining faster than you can sell them to pay your operating costs does also not help - but that's a different story and not related to pool. |
|
|
|
As PayCoin is now PoS, all SHA-256 ASICs are now coming back to bitcoin network. Big jump ahead...
Happened just now: almost +60PH within a day |
|
|
|
|
Just received the IPO opening mail from HL, with that this group-buy offer is closed.
|
|
|
|
It appears the IPO starts at 11 am Eastern time. Is that correct?
Yes, that's what is displayed for IPO opening as Havelock server time (which should be UTC-0500). |
|
|
|
Why do you think it take until the IPO closes?
That's how I interpret the wording, but have no definite confirmation. AMHash3 shares are converted to AMHash1 at end of IPO, which for direct shares seems reasonable to be done in one single step to prevent extra fees (direct->AMH3@HL->AMH1@HL). I might be wrong here, but would not like to risk buyers to have to wait weeks for their shares. |
|
|
|
Noticed the bonus for 100 TH has gone up to 6% if bought direct from AMHash.
Which means if this GB gets to 100 we get 4%!
Thats what I meant in the offer OP with: Note: AMHash offers direct bulk orders with an additional 1% bonus. At time of writing, it looks like shares would become direct ones, which won't be feasible for a group buy. If it turns out to be a viable option, bonus split will remain proportionally same, i.e. 3.6% to 2.4%. But seems that it will take until the IPO closes before direct shares can be transferred to Havelock, which I consider not desirable for a group-buy. |
|
|
|
|
Show Posts
