|
My next question would be, if the bASIC ASICs are already finished and in stock. The question was asked several times but was never answered. Tom did never acknowledge that the ASIC is in stock. Maybe his opinion about the manufacturing state of the ASIC is wrong as well?
If this question is not answered fast, I take this as a signal to cancel my bASIC order.
|
|
|
|
|
Unfortunately my bet was that either BFL or bASIC will be the first to deliver. I have a very good position in the queue (low order number) with both companys but no order with Avalon. I will wait a few weeks if BFL shows signs to ship the ASIC hardware (which I no longer expect) or if they shift again (I bet they will). If Avalon ships first my gamble is lost and there is no point in buying mining hardware anymore. In this case I continue buying BTC when the price is low. Mining when the diff is high makes no sense in my area.
|
|
|
|
BTW if the following Avalon news turns out to be true, I expect a storm of refunds request to hit Tom and BFL. At the moment I think about requesting a refund as long as this will be possible. Currently all ASIC miner companies are burning large amounts of money. When everybody starts to request refund it may be too late... No delays to see here.
...
Our demonstration is still scheduled to happen around the end of the year, then soon 1-2 weeks after the demo, Shipping will begin.
|
|
|
|
|
That is really bad news. That basically means no ASIC in 2012. No SC, no bASIC and no Avalon.
From the information we currently have and the questions that are still not answered (is the bASIC chip ready and in stock?!), I would not bet on January. BFL ist shifting week by week and from Avalon I don't see much news.
If all three companies are really working on ASIC miners and everything works well, I expect that the first ASIC product is shipped not before March/April 2013.
|
|
|
|
|
What about IPv6? /64? /48?
|
|
|
|
|
I hope his wallets are encrypted or stored on encrypted volumes and he has encrypted off-site backups.
|
|
|
|
|
From reading the thread I expect that the bASIC board needs a 12V power supply that is not delivered with the boards. Maybe Tom can clarify this point and writes the exact specifications for the onboard power connectors?!
BTW you can get 12V server PSUs ranging from 300W to 1kW on eBay for about 10USD. These PSUs have a high quality and are a cheap solution to power your mining hardware.
|
|
|
|
bei btcjam ist aber personalausweis, arbeitgeber etc wirklich alles hinterlegt. Also die prüfen vorher genau die identität
Ja und?! Von Trendon Shavers kennen die "Investoren" auch alle möglichen Daten. Sieht deshalb irgend einer davon seine BTC wieder? Genau! Deshalb gibt man nennenswerte Mengen von BTC nicht aus der Hand. Und schon gar nicht an Leute die nicht nebenan wohnen, bei denen man dann im Ernstfall jeden einzelnen Satoshi wieder aus ihnen herausprügeln kann. |
|
|
|
|
You are right - scrypt was set to true. I removed the setting and bfgminer is now working. Thank you for your support.
|
|
|
|
A few days ag I tested the stratum branch of BFGMiner but was not get an accepted share. Now I switched to the current bfgminer branch and see the same behaviour. I had so set intensity to a large value (currently 20) in order to get the CPU load down to about 2%. The hashrate with a working miner is typically about 11Mh/s. System is an AMD E350 with 64bit linux. Any ideas? Does it work on other pools? Can you make a debug log? bfgminer <your-options-here> --debuglog 2>debug.log I created a debug log (see logfile). I started a getblocktemplate pool and switched to a getwork pool after a few minutes. |
|
|
|
Just tried to compile HEAD on FreeBSD: localhost|/tmp/bitcoin-bitcoin-bb790aa/src> gmake -f makefile.unix
/bin/sh ../share/genbuild.sh obj/build.h
Building LevelDB ...
"Makefile", line 18: Need an operator
"Makefile", line 63: Missing dependency operator
"Makefile", line 65: Missing dependency operator
"Makefile", line 70: Need an operator
"Makefile", line 82: Need an operator
"Makefile", line 87: Need an operator
"Makefile", line 172: Missing dependency operator
"Makefile", line 194: Need an operator
"Makefile", line 200: Need an operator
make: fatal errors encountered -- cannot continue
g++ -c -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -I/tmp/bitcoin-bitcoin-bb790aa/src -I/tmp/bitcoin-bitcoin-bb790aa/src/obj -I/usr/local/include -I/usr/local/include/db48 -DUSE_IPV6=1 -I/tmp/bitcoin-bitcoin-bb790aa/src/leveldb/include -I/tmp/bitcoin-bitcoin-bb790aa/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2 -MMD -MF obj/leveldb.d -o obj/leveldb.o leveldb.cpp
In file included from leveldb.cpp:5:
leveldb.h:144:2: warning: no newline at end of file
g++ -O2 -pthread -Wall -Wextra -Wformat -Wformat-security -Wno-unused-parameter -g -DBOOST_SPIRIT_THREADSAFE -I/tmp/bitcoin-bitcoin-bb790aa/src -I/tmp/bitcoin-bitcoin-bb790aa/src/obj -I/usr/local/include -I/usr/local/include/db48 -DUSE_IPV6=1 -I/tmp/bitcoin-bitcoin-bb790aa/src/leveldb/include -I/tmp/bitcoin-bitcoin-bb790aa/src/leveldb/helpers -DHAVE_BUILD_INFO -fno-stack-protector -fstack-protector-all -Wstack-protector -D_FORTIFY_SOURCE=2 -o bitcoind obj/alert.o obj/version.o obj/checkpoints.o obj/netbase.o obj/addrman.o obj/crypter.o obj/key.o obj/db.o obj/init.o obj/irc.o obj/keystore.o obj/main.o obj/net.o obj/protocol.o obj/bitcoinrpc.o obj/rpcdump.o obj/rpcnet.o obj/rpcmining.o obj/rpcwallet.o obj/rpcblockchain.o obj/rpcrawtransaction.o obj/script.o obj/sync.o obj/util.o obj/wallet.o obj/walletdb.o obj/noui.o obj/leveldb.o obj/txdb.o -Wl,-z,relro -Wl,-z,now -L/usr/local/lib -L/usr/local/lib/db48 -Wl,-Bdynamic -l boost_system -l boost_filesystem -l boost_program_options -l boost_thread -l db_cxx -l ssl -l crypto -Wl,-Bdynamic -l z -l pthread /tmp/bitcoin-bitcoin-bb790aa/src/leveldb/libleveldb.a /tmp/bitcoin-bitcoin-bb790aa/src/leveldb/libmemenv.a
g++: /tmp/bitcoin-bitcoin-bb790aa/src/leveldb/libleveldb.a: No such file or directory
g++: /tmp/bitcoin-bitcoin-bb790aa/src/leveldb/libmemenv.a: No such file or directory
gmake: *** [bitcoind] Error 1
|
|
|
|
A few days ag I tested the stratum branch of BFGMiner but was not get an accepted share. Now I switched to the current bfgminer branch and see the same behaviour. bfgminer version 2.8.3 - Started: [2012-10-28 11:12:17] - [ 0 days 01:01:52]
--------------------------------------------------------------------------------
5s: 21.9 avg: 21.3 u: 0.0 Mh/s | A:0 R:0 HW:0 E:0% U:0.0/m
TQ: 0 ST: 3 SS: 0 DW: 8 NB: 8 GW: 76 LW: 258 GF: 0 RF: 0
Connected to http://api.bitcoin.cz:8332 with LP as user XXXXXXXXXXXXX
Block: 000004d29e7374fed5c8c1a38224a872... Started: [12:04:00]
--------------------------------------------------------------------------------
[P]ool management [G]PU management [S]ettings [D]isplay options [Q]uit
OCL 0: 67.0C | 21.3/ 21.3/ 0.0Mh/s | A:0 R:0 HW:0 U:0.00/m
--------------------------------------------------------------------------------
[2012-10-28 11:38:45] LONGPOLL from pool 1 detected new block
[2012-10-28 11:59:02] LONGPOLL from pool 1 detected new block
[2012-10-28 12:00:16] LONGPOLL from pool 1 detected new block
[2012-10-28 12:04:00] LONGPOLL from pool 1 detected new block
I had so set intensity to a large value (currently 20) in order to get the CPU load down to about 2%. The hashrate with a working miner is typically about 11Mh/s. System is an AMD E350 with 64bit linux. Any ideas? |
|
|
|
|
If the ASICs are in fab run right now, don't expect any BFL ASIC products in 2012. Let's hope that Tom will be able to get working ASIC devices in time. Otherwise the Avalon customers might be the lucky ones.
|
|
|
|
Put the stratum URL in without any prefix in the config file.
Without the prefix: ...
"url" : "api-stratum.bitcoin.cz:3333",
...
"url" : "stratum.btcguild.com:9332",
I get: 0: Enabled Alive Priority 0: http://api-stratum.bitcoin.cz:3333 ...
1: Enabled Alive Priority 1: http://stratum.btcguild.com:9332 ...
So this seems to work now. Only the http:// prefix in the user interface is misleading. |
|
|
|
I'm using 2.8.4 now but the stratum implementation seems to be broken. I have the same behaviour in all 2.8.x versions (see my post). It seems that stratum+tcp:// URLs in the config file are not working. |
|
|
|
|
First it was Oct, then Nov and now Dec. If Tom is able to deliver end of Nov the BFL per-order customer are screwed. If this Dec news is true my estimation is, that customers will not see any BFL ASIC product in 2012.
|
|
|
|
|
Tom, I think Josh will never agree to your bet and that alone is a clear statement about the status of the BFL ASIC products for me. Sometimes he reminds me to MNW. Just ignore him, stay away from BFL threads/comparisons and concentrate on your bASIC product.
Back to bASIC - do you think your estimated ship date for the bASICs is still valid?
|
|
|
|
|
At the moment, shipment date is the most important factor for an ASIC mining device. I have more trust that Tom will start shiping in 4-6 weeks than that his competitor will ship in 2-4 weeks.
My current expectation is that no customer will mine at 50 BTC per block and that bASIC will be the first device to hit the market.
Tom, is your estimated shipment date for the first batch (week after Thanksgiving) still valid?
|
|
|
|
1) When BFL's line of ASIC's hit the wild they must not consume more than 1.1 watt of electricity per 1Gh/s of Bitcoin mining speed, and according to everything you are telling us 1.1 watts per 1Gh/s is the most electricity they will use.
2) You will no longer post in my thread, if you post in my thread again you automatically lose the bet.
Now things get interesting. I would recommend to set an end date when the BFL ASICs have to be delivered (this year in larger quantity?). If they hit the wild in two years this 1.1W/GH/s might be no problem anymore. Josh, it's your turn - words or money? BTW two weeks until BFL mass shipments (end of Oct / beginning of Nov), so the first devices are already on your table. That should be save money. Or it's not that save which means no device on the table and no mass shippments within two weeks... |
|
|
|
So from my view, GBT is wasting resources for no real gain.
That depends on your point of view. As a pool operator or miner with ultimate trust to the pool operator you are right. From the perspective of a miner that cares about what goes into a block it is important to see the complete information. With Stratum, the pool operator is the one that creates bitcoin blocks and makes the rules. The miner is paid for doing some work for the operator. With GBT the pool operator is a work dispatcher but miners create the bitcoin blocks and make the rules. I don't regard more information and control as a waste of resources. |
|
|
|
|
Show Posts
