Are you sure you have the correct port, port is open, etc?
Try telnet to the host/port and see if you can connect.
salfter@files:~$ telnet localhost 8844
Trying ::1...
Connected to localhost.
Escape character is '^]'.
GET / HTTP/1.0
HTTP/1.0 401 Authorization Required
Date: Mon, 10 Nov 2014 15:31:46 +0000
Server: joulecoin-json-rpc/v0.9.2.2-beta
WWW-Authenticate: Basic realm="jsonrpc"
Content-Type: text/html
Content-Length: 296
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd">
<HTML>
<HEAD>
<TITLE>Error</TITLE>
<META HTTP-EQUIV='Content-Type' CONTENT='text/html; charset=ISO-8859-1'>
</HEAD>
<BODY><H1>401 Unauthorized.</H1></BODY>
</HTML>
Connection closed by foreign host.
That's about what I'd expect, given that I'm not sending the username and password. "Server: joulecoin-json-rpc/v0.9.2.2-beta" indicates that I'm talking to the right port, at least. |
|
|
|
|
I'm running the latest version, but I've had a transaction to an exchange stuck with zero confirmations for the better part of 24 hours now. Also, while a mining pool says it's sent me payments, they've not arrived. Is something still not right with the network?
|
|
|
|
I'm looking at adding Joulecoin to my MinerSwitcher setup, but I've run into a snag: I can't get the block reward out of joulecoind. MinerSwitcher depends on ProfitLib, which in turn depends on a set of coin daemons and some exchange data (currently from Cryptsy, but I'm looking at adding support for more exchanges) to determine which coin to mine at a particular time. This block of ProfitLib code uses python-bitcoinrpc calls to retrieve the current block reward: b=jsonrpc.ServiceProxy(url)
# get block reward, including transaction fees
# note #1: Novacoin (and coins derived from it?) report
# 1% of actual value here
# note #2: Namecoin doesn't support getblocktemplate, so get
# coinbase value from last block
# note #3: PPCoin doesn't want any parameters passed to
# getblocktemplate. Bitcoin requires at least
# an empty dictionary to be passed. Others don't
# care.
reward=Decimal(0)
try:
reward=Decimal(b.getblocktemplate()["coinbasevalue"])
except:
pass
if (reward==0):
try:
reward=Decimal(b.getblocktemplate({})["coinbasevalue"])
except:
pass
if (reward==0):
try:
vouts=b.decoderawtransaction(b.getrawtransaction(b.getblock(b.getblockhash(b.getblockcount()))["tx"][0]))["vout"]
for j, vout in enumerate(vouts):
reward+=vout["value"]
except:
pass
if (coin=="NVC" or coin=="DEM" or coin=="OSC"):
reward*=100
It tries three different methods, determined over the course of adding 25 other coins, that work: * getblocktemplate with no input * getblocktemplate with an empty input * if getblocktemplate isn't available, get the coinbase value from the first transaction of the last block mined This works for every other coin, but not for Joulecoin. getblocktemplate is a valid call; joulecoind getblocktemplate returns what you'd expect. There appears to be a communication error between python-bitcoinrpc and joulecoind. I knocked together this test script: import bitcoinrpc
import jsonrpc
import sys
from decimal import *
import pprint
url="http://salfter:redacted@localhost:8844"
#url="http://salfter:redacted@localhost:8332"
b=jsonrpc.ServiceProxy(url)
pprint.pprint(b.getblocktemplate()["coinbasevalue"])
The first url definition points to my joulecoind instance. The second, commented-out definition points to my bitcoind instance. If you run it against bitcoind, you get the current coinbase value: Run it against joulecoind, however, and you get this: Traceback (most recent call last):
File "test.py", line 12, in <module>
pprint.pprint(b.getblocktemplate()["coinbasevalue"])
File "/usr/local/lib/python2.7/dist-packages/bitcoinrpc/authproxy.py", line 120, in __call__
response = self._get_response()
File "/usr/local/lib/python2.7/dist-packages/bitcoinrpc/authproxy.py", line 146, in _get_response
parse_float=decimal.Decimal)
File "/usr/lib/python2.7/json/__init__.py", line 351, in loads
return cls(encoding=encoding, **kw).decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded
Something is going seriously wrong here. I built joulecoind from GitHub source yesterday: git clone https://github.com/joulecoin/joulecoin
cd joulecoin
./autogen.sh && ./configure --with-incompatible-bdb && make -j3 && sudo cp src/joulecoind /usr/local/bin
It's hard to reach any other conclusion than that there's a bug somewhere in the Joulecoin codebase, given that I have 25 other coins configured and running properly with the same code. |
|
|
|
I'm trying to spin up a new nautiluscoind instance, but it's having trouble finding any peers. I have the addnode statements from the OP in nautiluscoin.conf, but am just getting lots of this:
Make sure you are compiling using the "master" branch of the Git repository. I used this to download, configure, and build (I have a newer bdb and don't care about binary wallet compatibility): git clone https://github.com/nautiluscoin/nautiluscoin
cd nautiluscoin
./autogen.sh && ./configure --with-incompatible-bdb && make -j3
That should be the master branch. Just in case it isn't for some reason, I'm building it again after this: As I was writing this post, the build completed. I restarted with the newly-built binary, and it's now downloading the blockchain. Weird, but I'll take it...thanks! |
|
|
|
I'm trying to spin up a new nautiluscoind instance, but it's having trouble finding any peers. I have the addnode statements from the OP in nautiluscoin.conf, but am just getting lots of this: 2014-11-07 22:38:10 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:11 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:11 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:12 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:12 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:13 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:14 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:14 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:14 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:15 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:15 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:15 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:15 connect() to 74.208.230.160:11161 failed after select(): Connection refused
2014-11-07 22:38:16 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:16 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:17 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:17 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:18 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:18 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:19 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:20 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:20 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:21 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:21 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:22 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:22 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:23 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:23 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:24 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:25 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:25 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:26 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:26 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:27 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:27 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:28 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:28 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:29 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:30 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:30 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:31 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:31 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:32 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:32 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:32 connect() to 109.201.154.157:11161 failed after select(): Connection refused
2014-11-07 22:38:33 connect() to 54.187.101.97:11161 failed after select(): Connection refused
2014-11-07 22:38:33 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:34 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:35 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:35 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:36 connect() to 54.186.223.183:11161 failed after select(): Connection refused
2014-11-07 22:38:36 connect() to 54.187.101.97:11161 failed after select(): Connection refused
A bunch of other coin daemons are working without issue. Is there an updated set of nodes to use? There's mining activity going on, so there has to be a node available somewhere, but the current git source can't find it. |
|
|
|
https://gitlab.com/salfter/MinerSwitcherMinerSwitcher is a profitability-based mining farm pool switcher. For the set of coins you have configured, it will determine how many of each you can produce given your hardware, and determine what they're worth in Bitcoin. It will then reconfigure all of your miners accordingly. MinerSwitcher is algorithm-agnostic: you can have a mix of sha256 miners, scrypt miners, etc., and each will be switched to whatever is most profitable for it to mine. Sometimes pools go down without much notice. Before switching coins, MinerSwitcher verifies that at least one of your configured pools is still up. If it isn't, it prints a warning and moves on to the next most profitable pool. (I suspect that adding a notification mechanism (Pushover, perhaps?) is in order.) If configured, MinerSwitcher will also send Pushover notifications when a miner is down or pools aren't reachable. MiningSwitcher is built around my ProfitLib library. Example output, right after startup: Sun Oct 19 14:19:29 2014: running ProfitLib
BTC 0.00835068
UNO 0.00507514
ZET 0.00195981
Sun Oct 19 14:19:46 2014: checking BTC pools
Sun Oct 19 14:19:48 2014: switching miner4 to BTC Guild
Sun Oct 19 14:19:50 2014: switching miner4 to Eligius
Sun Oct 19 14:19:51 2014: switching miner3 to BTC Guild
Sun Oct 19 14:19:53 2014: switching miner3 to Eligius
Sun Oct 19 14:19:54 2014: switching miner2 to BTC Guild
Sun Oct 19 14:19:55 2014: switching miner2 to Eligius
42 0.00310407
LTC 0.00227397
ANC 0.00224579
FTC 0.00213765
BTG 0.00003768
Sun Oct 19 14:19:56 2014: checking 42 pools
Sun Oct 19 14:19:56 2014: switching miner1 to HashFaster 42
Sun Oct 19 14:19:59 2014: sleep for 30 minutes
miner1 is a bunch of Gridseeds (11 orbs and a blade) hanging off a Raspberry Pi, running bfgminer. miner2 is a Bitfury rig with a couple of BFL Jalapeños, running cgminer. miner3 and miner4 are Antminer S1s. They're all on my home LAN, but MinerSwitcher should also work with remote mining rigs as long as the cgminer/bfgminer RPC port is accessible to the machine running MinerSwitcher. The only outside data dependency is Cryptsy, for exchange-rate information. All of the remaining information MinerSwitcher needs is obtained directly from coin daemons running locally. I currently have 10 daemons (DOGE & NMC can be merge-mined and are counted as appropriate) running on a box with 4 GB of RAM; it works, but RAM is overcommitted. I'll be kicking it up to 10 GB in the next day or two.
|
|
|
|
Yes, there are sites such as CoinChoose and CoinWarz that aim to show you which coin is the most profitable for your hardware. Hidden algorithms and bad data (usually from coin daemons that have gotten wedged) can throw their results off. They also might not offer all the coins you'd like to mine. ProfitLib is a Python library that works with the coin daemons you operate to find the most profitable coin. Its only external data dependency is for market data from Cryptsy so you can compare all coins in terms of what they're worth in Bitcoin. https://gitlab.com/salfter/ProfitLibI already have a shell script using it to control my miners by running the scripts I had already set up for CryptoSwitcher through an SSH connection...kinda janky, but it works. I have another project in the works that will use ProfitLib to control your entire mining farm from one place: all your sha256 miners on the most profitable sha256 coin, all your scrypt miners on the most profitable scrypt coin, etc. I'll post more when it's ready. |
|
|
|
Looks like the network is having some issues.
...and it would appear that it's up and running again. |
|
|
|
Looks like the network is having some issues. I keep two instances of bitgemd running: one for my pool on a VPS in Germany, another on a home server in the US. Neither is able to connect to other nodes. My block explorer says the last block it's heard of is 84449. I found another block explorer; it concurs. There have been no commits to GitHub since February, so it's not a matter of having missed a critical update...so what's going on? |
|
|
|
I pay zero fee TXs all the time and they get confirms.
The Constitution only applies to the government.
Nobody is armed forcing you to pay TX fees.
people may not know.. i use Multibit and it forces a fee that is NOT cheap ! if i want to send $500,000 worth of BTC it would cost me 0.0001 BTC and if i want to send 0.0002 BTC it costs me 0.0001 BTC 0.0002 is about 7.6¢. You can't even find a gumball machine anymore that takes less than a quarter. Why are you trying to send such a small amount? If you don't like the fee policy Multibit enforces, don't use Multibit. There are plenty of other options that'll let you set whatever transaction fee you want. If you want to pay 0 tx fees (which I don't recommend), I have three words for you:
createrawtransaction
signrawtransaction
sendrawtransaction
CheapSweep uses those to combine lots of small inputs into a single, larger output. |
|
|
|
If you have issues with heat emission from the H-boards V1, you should try to cool the back of the PCB. If you put a heatsink on top the bitfury chip it won't do very much, it only helps a little. Most heat generated by the bitfury chip comes from the bottom of the chip -> back of the PCB. Try to fit a heatsink on the back of PCB but I know there is little space for that.
I have heatsinks on the backs of my boards:  (It's an old picture from when I only had two H-boards, but all my H-boards are set up like this.) |
|
|
|
|
Summer has well and truly arrived in Las Vegas. I had moved all my mining hardware out into the garage a while back to get the heat and noise out of the house. Most of my gear is working OK in triple-digit temperatures...fans speed up a bit, but they keep on moving.
The exception, though, is my Bitfury rig (nine H-boards with the appropriate backplane...the one that looks like a bunch of PCIe 1x slots). In the cooler months, I was getting about 270 GH/s from it easily. Every once in a while, it'd lose communication with some of the chips; restarting bfgminer would get it back on track. As the weather got warmer, though, it started getting stuck more and more often. I backed off the speed a bit. It worked a while longer, then started getting wedged again. I found that cgminer had added support for these systems (--enable-bab) and would adjust clock speeds automatically to optimize performance, so I built it and switched over from bfgminer. It'll keep running now, but as the temperature outside pushed past 110 last week, hashrate fell down to about 120 GH/s!
I have heatsinks on the backside of the boards opposite each mining ASIC and voltage regulator. I have it in a Spotswood frame with three fans good for over 270 cfm between them. The other miners (two BFL Jalapeños, two Antminer S1s, a Gridseed blade miner, and a handful of Gridseed orb miners) are stock, except for some of the Gridseed orbs which I stacked together with standoffs so they'd take less space. These other miners haven't skipped a beat.
Since the Raspberry Pi in the Bitfury rig was also controlling the BFL and Gridseed miners, I needed to set up another to take over for them when I moved the Bitfury into the laundry room. Mining speed picked up to 200 GH/s...still not back to 270. One of the fans had worn out, so I replaced it. (The fan was working before I moved the rig, but it had gotten noisy. Finding high-speed fans that aren't riced out with LEDs is harder than it should be, but that's fodder for another rant.) With the new fan in place and the rig still in the laundry room, it's finally back to mining at 270 GH/s.
|
|
|
|
Mine was in English:  Whatever. I don't think I had more than a cent's worth of BTC at MtGox when it went tits-up, if that. Sucks to be those who treated it like a bank, I suppose...this ends up being a potentially expensive lesson in missing the point. |
|
|
|
|
I currently have four types of ASICs in my mining rig: Bitfury, BFL, Antminer, and Gridseed. The Antminers are self-contained, while the others all run off of the Raspberry Pi in the Bitfury rig.
bfgminer seems to work well enough with my Gridseeds for scrypt mining on Multipool, but it seems to have problems on the SHA-256 side when the pool switches coins. It gets stuck, and never appears to get unstuck. The Antminers shipped with cgminer, which doesn't appear to have this problem.
Supposedly cgminer was never going to be updated to work with BitfuryStrikesBack rigs because they were limited to running on the Raspberry Pi, connected through its GPIO port. At some point, though, support was added for the Bitfury-based hardware from Black Arrow, which is AFAICT functionally identical to BFSB hardware (they both support four groups of hashing boards per RPi, with the chips in each group chained together over SPI). I built the latest cgminer yesterday, tweaked the config file a little (took stuff out, mostly), and fired it up. It's working much better now with Multipool. It's been running since sometime yesterday evening, switching between coins (network difficulty keeps switching from ~11 billion for Bitcoin to somewhere in the low hundreds of thousands for the SHA-256 altcoins) without an issue. As a bonus, it's also tweaking speeds on the Bitfury ASICs to squeeze more speed out of them while keeping errors low. If a chip got pushed too far with bfgminer, it would start spewing nonstop errors until it was restarted.
With all of that said, is there some reason why the SHA-256 side of Multipool runs better with cgminer than with bfgminer? Given that the scrypt side of Multipool works fine with bfgminer (good thing it does, as you can't mine scrypt at all with recent versions of cgminer), this seems a little odd.
|
|
|
|
The pool has moved: https://bitgem.alfter.us/The old hostname still works, as I've set up a 301 redirect for it, but you should update your miner settings. The pool's now running MPOS, and vardiff has been enabled. Also, the new pool has a proper (read: not self-signed) SSL certificate. |
|
|
|
CoinChoose's data has apparently gotten stale over the past few months due to a lack of maintenance, which has made CryptoSwitcher somewhat less useful. This package doesn't try to do all of the things that CryptoSwitcher did, but what it does, it should do well. Its workflow is roughly as follows: - see what coins are tradable for BTC on Cryptsy
- check CoinWarz for profitability information (tested with scrypt coins, but others should work)
- find the most profitable coin to mine that we'll be able to trade for BTC
- call a shell script to switch pools, if necessary
- wait and repeat
You'll need API keys for both Cryptsy and CoinWarz. CoinWarz charges for use of its API after the first 1000 calls; checking once per hour, you should be able to try out this script for six weeks before running out. Grab it from https://github.com/salfter/coinswitch. PyCryptsy is included as a submodule, so you'll want to grab it as well: git clone https://github.com/salfter/coinswitch
cd coinswitch
git submodule init
git submodule update
See the README for further details. coinswitch itself is in Python, but it calls shell scripts to do the actual switching, which can have their own dependencies. (Mine depend on a PHP script I knocked together for use with CryptoSwitcher. For that matter, the shell scripts are the same ones I used with CryptoSwitcher.) |
|
|
|
http://zoomhash.com/collections/top-sellers/products/gridseed-80-chip-blade-miner-5200khsMy first one arrived last week. It's plugged into a Raspberry Pi (along with some Gridseed 5-chip orbs, a Bitfury rig, and a couple of BFL Jalapeños). With scrypt hash rates being roughly equivalent to SHA-256 hash rates three orders of magnitude higher, and with the profitability of some altcoins being about two orders of magnitude higher than Bitcoin (for instance, Sexcoin is about 91-92x more profitable as I write this), 5.2 MH/s on this rig is probably equivalent to 450 GH/s or so in SHA-256 equipment. Even if you limit yourself to the bigger-name altcoins such as Litecoin or Dogecoin, they're 40-50x more profitable. As for me, I let CoinChoose pick the best coin to mine at the moment and have Cryptsy convert it all to Bitcoin.
|
|
|
|
Tried signing up ,but keep getting "Account registration is currently disabled. Please try again later.We are currently not accepting new user registrations."
That was a mistake on my part.  Registration at bitgem.alfter.us is now open as of a few minutes ago. I've also tightened up the email templates so they don't pollute your inbox with HTML, and I've enabled variable difficulty in the stratum server. Your mining rig should settle in somewhere around twelve shares per minute (one every five seconds), unless your hashrate is low. I'm using half of a Gridseed blade miner, which delivers about 2.5 MH/s. (It's running at 800 MHz to keep hardware errors down in the heat we're now getting.) The server settled on a difficulty setting of 256 for it. The old server, by comparison, had difficulty fixed at 32. |
|
|
|
|
Show Posts
