If mining is a marginal industry then Bitcoin is, and always will be, marginal.  Bitcoin Mining is just a subset of Bitcoin. Just because mining is marginal does not make the currency itself marginal. Correct - also, mining isn't marginal - it's the core design... without miners there isn't a bitcoin network. That being said - Everyone needs to just stop freaking out about ASICs. a single will make what a single makes, and a rig will make what a rig makes... You'll still be struggling for some percentage of the entire network. We need to start focusing on growing bitcoin as a network, instead of just profit taking. Lets get those transactions fees high enough to replace the block reward entirely. Yes? Great... |
|
|
|
The argument for the sea-of-hashes design can be derived from the classic analysis made by Mead & Conway and contemporaries.
Consider a circular sea-of-gates big enough to implement many copies of the Bitcoin double-SHA256.
SHA256 is basically a pair of 32-bit wide shift registers seventy-two 32-bit registers
Fixed that first part for you... but just wasn't up to trying to edit the rest for conceptual logic failures. Software optimization isn't the same as hardware optimization. ASIC design should not be thought of as "lets make a chip that can do this calculation at 2000mhz over and over and over..." that's counter-intuitive. You've locked yourself into thinking in terms of GPU design which need not apply to other processes. The reason GPUs (and yes, CPUs too) are designed this way is because they are multi-function chip. There's operations they know how to do, and they process things according to instructions. That's fine for generalized applications. In the case of GPU you've got a hard limit / goal of producing a video frame every so many fractions of a second... sha2 just doesn't need that level of coordination. You aren't having to work for a variety of instructions - it's a single process that doesn't change. Besides which we're not actually talking about that much data. sha2... we only need to work with 512 bits at a time. At the very least we had better be unrolling the chunk processing for so that it isn't looping... that's hardware design 101. |
|
|
|
I don't.
ASICs are expensive and fragile. Heating elements are pennies and durable. Different items for different purposes.
For warming a room, perhaps, if they get really cheap or for people who already own them. Not for drying clothes though!
Yes I can see your point. But that's where I see this going if bitcoin does become the giant I think it will. Why not integrate it into standard every-day application? Sure there are potential problelms, but why hardware has generations, to build more sensible and robust solutions. Anyone in a very cold winter region could for example, use a mining rig to heat a garage instead of paying thousands of dollars an embedded heater. While at the same time making back some of the operating costs of that unit. What about floorboard heating that uses asics to make the heat... basic electric baseboard heating, that's very cheap to run. |
|
|
|
Yes, its just like unrolling loop iterations, but in hardware. You have timing problems because you have one clock pulse per hash and everything needs to arrive into their stages at the right time; if you have traces that are too long or too short then stuff doesn't function correctly or you need to waste more silicon trying to properly synchronize data.
It is much easier to just keep data exactly where it needs to be and iteratively process it.
I agree it's easier... but it isn't better. Which was of course, my entire point. No. As bitfury demonstrated in practice, tiny hashing cores are superior to unrolled designs. He gets 300 Mh/s compared to 220-240 Mh/s for the competition, on an LX150. Some of the gains are attributable to overclocking and overvolting, but most come from its superior design. No. You said it yourself "on an lx150" - the correct way to do this would be to use dozens or hundreds of chips and have it process in a single stage... impractical on an FPGA, but perfectly doable for an ASIC. |
|
|
|
|
I also think then next step is alternate use for asics as a heating element.
Lets build a rig that vents its heat to dry clothes.
"Honey, I need you to do more laundry, we need that dryer be mining for us"
|
|
|
|
Good for my fpga's that havet yet reached 100% RoI
Kinda bad for my gpu's at my electric rates the off chanse of breakage is not covered with what remains of profit after the reward halving.
Bad for my Asic order.
I guess atleast I have my risk decentralized ?
I guess that's a point for some people. Personally, I think it would be interesting to see what happens at halving... and then again at ASIC release. We can expect a quick crash and even quicker recovery when ASICs hit... but halving may slowly drive the price or may do nothing at all... |
|
|
|
these days us GPU folk need every BTC we can grab before having/asics!
Also, if one uses their computers to keep their living quarters heated verses using a heater.. the electricity almost becomes "free" (or at least "very cheap", due to offsetting a normal heating bill)
I actually moved some mining equipment into the living room... cracked a window, and put 35watt box fan in a window at the other end of the house... I haven't had to turn the heater on yet (and it's hitting high 30s at night). The other day I came home to find my wife had closed the window in the front room... then turned on the AC because her gaming rig was overheating... "Well why did you shut the window?" "My feet were cold." *sigh* |
|
|
|
|
Throw a price at me... and I'll get back to you with a quote on a rig.
|
|
|
|
Back to the original point of this thread.
BFL is definitely improving on their customer relations front...they called me last week in response to an email I sent......EMAIL THAT I SENT IN JUNE....to answer any questions I had. I politely informed them they were months late on the FPGA sale. I'd gone with the trustworthy Tom.
Yes I got a call like that as well... of course the rep wasn't able to answer any important questions... and my sales issue was long since resolved. |
|
|
|
Yes, its just like unrolling loop iterations, but in hardware. You have timing problems because you have one clock pulse per hash and everything needs to arrive into their stages at the right time; if you have traces that are too long or too short then stuff doesn't function correctly or you need to waste more silicon trying to properly synchronize data.
It is much easier to just keep data exactly where it needs to be and iteratively process it.
I agree it's easier... but it isn't better. Which was of course, my entire point. |
|
|
|
Maybe I'm not getting upset because I've been through this before with the FPGA's. Just keep mining with your video cards and try to enjoy the holidays.
Maybe I'm not getting upset because my existing GPU/FPGA farm is making decent money for me already... Also I got bought BTC8.5 worth of pies from a local farmer yesterday... gonna be a grand thanksgiving day.  On the other hand, those of us who've dealt with BFL before... were expecting these sort of delays... as should anyone who's ever worked for a small business... When someone asked me when ASICs were coming out (about 6 months ago) I said well BFL says oct. but it probably won't be until march. I stand by that statement, as it was made then. With more competition (Just wait Tom's gonna release on time). . . it's becoming more important that BFL get product out the door before Jan. But I wouldn't count on it. |
|
|
|
|
Really the only thing they'll be able to do second gen (or third gen) is use smaller gap silicon - which allows for a speed increase in the same heat/watt space. As such, I wouldn't expect many people to upgrade in general.
Now a smarter second gen product would be a same hash power, lesser power consumption unit (in a smaller more modular enclosure)... for a very minor price increase. say 5%. That might actually get people to buy them instead of first gen... but the company could continue to sell both. So then you've got the "refurbished generation 1s" going for 5% or 10% less than a new gen1, and a gen2 device going for 5% or 10% more.
I'd want to see upgrades in the form of better board design or innovative cooling instead of following the gpu model and going "faster, hotter, more power needed, in the same space". Space shouldn't really be a concern imo.
Now give me a rolling racked enclosure with slots for the gen2 singles where the enclosure uses a direct contact copper heatsink and I just plug it into a slot... some management metrics displayed on the outside of it... and I'd be all about upgrading to that.
|
|
|
|
I think you're suggesting that unrolled cores are the answer. They aren't. You run into timing problems, and you also pay for that silicon to be produced no matter how sparse or packed it is. The best option seems to be iterative rolled up cores that take ~110 cycles to do a nonce, but you have ~100 times more cores.
Plus, it increases yields as the controller hardware can just test which cores work and ignore known broken ones (ie, intentionally binning parts ala modern GPU design).
I'm not familiar with the term unrolled cores... I assume it's a bastardization related to how you might unroll loop iteration on an x84 cpu? Why there be timing problems, we'd have a relatively slow cycle time... and thus plenty of time to check and/or error correct. |
|
|
|
You mention that this oil may be uneconomical to recover. This is only partially true. While a well is expensive to drill the costs are recovered in the first few months of operation. The cost of this oil comes from transport. People I have spoken with peg it around $22 a barrel to ship due to lack of pipeline capacity, meaning most of the oil is shipped by rail. As long as oil prices are high this isn't a problem. However should the price fall it could become economical due to shipping concerns. The proposed Keystone XL pipeline was supposed to have a load station in montana for some of this oil. However, many people in the area speculate it was nixed due to pressure from Obama's good friend, Warren Buffet. Berkshire Hathaway owns a 100% stake in Burlington northern Santa Fey railroad that benefits greatly from the increased rail traffic.
I would add that the cost of rail transportation of oil is relatively cheap. Moving freight by rail is 3 times more fuel efficient than moving freight on the highway. Trains can move a ton of freight nearly 500 miles on a single gallon of fuel. I thing vast majority of the transportation cost for domestic oil must be in the local delivery (last 50 or 100 miles) where it's in a tank on the back of a truck. But either way, can largely discount the cost of shipping oil, assuming that the person producing it is also the one transporting it. When you're talking about a 100000 gallons being transported on trucks, and consuming maybe 500 or 1000 gallons of that... it's simply added cost of doing business and really shouldn't affect prices at the pump. |
|
|
|
So I'm trying to get my mind around what the best set-up would be for up to 25 ASIC units. Either the BFL SC singles or bASIC.
What about USB bandwith ? Can you use a couple high quality usb hubs or will they have bandwith issues ?
Bandwidth has less to do with it......., since actual bandwidth is quite small, the REAL issue is the protocol. In another post I'd recommended that the Chinese ASIC system could potentially scale better, since they have opted to include WIFI/Ethernet. The problem with USB is that only ONE device can be on the buss at a time AND you have to signal connection & disconnection Which means as the number of devices grows, so does the buss collisions. Hubs solve F*** ALL, the same way that building more roads into a city does, all a hub does is increase the potential for collisions. It is RAW ports that you need, since they decrease the chance of collisions by a power of the number employed. Two RAW ports decrease the collisions by a power of two over the number of devices.(since you can split the USB tree) Overall it is very difficult to work out HOW ASICS will impact the USB communication, because so little details have been released. Consider the Implementation of a SIMPLE buffer scheme for returned nonces. Take the following..... Setup one: Returns EACH nonce when found Setup Two Bundles up nonces and returns a batch every second. consider that we find 5 nonces that are viable, Setup Two will only negotiate with the USB ONCE every second, therefore the collisions are limited down. Setup one will attempt to connect & disconnect ATLEAST 5 TIMES with the USB infrastructure, this will seriously impact the distribution of work to other devices, plus it is going to be exponential for each extra device. Since the Damned ASIC vendors are telling us nothing about how the devices are implemented, we cannot plan ahead or work out anything. HC Your idea about how USB works is factually incorrect. Start reading about the technology on wiki which correctly states: The host controller directs traffic flow to devices, so no USB device can transfer any data on the bus without an explicit request from the host controller. In USB 2.0, the host controller polls the bus for traffic, usually in a round-robin fashion. The throughput of each USB port is determined by the slower speed of either the USB port or the USB device connected to the port.In case you need a translation. The speed of the chain/hub determines how quickly each attached device is polled for transfering data. This operation in double digit milliseconds (around 12 iirc) in most cases, but there do exist some that poll speed is in the single digit. This is for usb 2.0. Furthermore, the signaling method for USB 3.0, while still host-directed, is now asynchronous instead of polling. and drops that access time to each device by a factor of 10. So no, there's no "attempt to connect and disconnect ATLEAST 5 TIMES" it is in effect a flag that's set on the device (closing the ground line???) that indicates it has data to transfer. Polling would be a query from the usbcontroller to the device asking if it's got data... When that happens and the device has data to send... it transmits. Also, this is why it's called Universal Serial Bus it's using the same methods that a data bus on any circuit board uses but to communicate with external devices (and logically instead of physically). |
|
|
|
i think he meant he can use 5000kwh a month off the grid.
Thats effectively = 5000 / 720 = 7kwh.
Which is possible if you have space for all the panels
I'm sorry that is correct. ~5000kwh per month, but we run several households - the bunker (yah it's my datacenter/office and it used to be a fallout shelter) and all our other power needs almost entirely from solar... It isn't on anyone's roof tho... we've got a shallow southward facing hill that was perfect for putting panels on. |
|
|
|
Bitcoin is going to be the biggest opportunity for innovation that the world has seen since the industrial revolution.
Bitcoin is a startup currency which has never happened before.
This reminds me... does anyone know of anyone offering 3d printer parts for bitcoin? If not - great business just waiting to be created. |
|
|
|
Very interesting numbers Keefe, Thanks alot ! As I read, it seems more and more clear that the future of mining, in the long run, will mainly be about power cost. I'd like to know if someone has made some research about solar powered mining rig... As the solar is'nt a constant source of power, what are the odds ? Here the power cost is arround 0.085 CAD/Kwh.. So, if I'll enjoy mining for few years again, at least I hope to ! Thanks again Keefe, and as almost everyone reading this thread, curious to see what the 3 known asic producer will have on the table at delivery  Yes, I'm running my entire mining operation (and actually a lot of other computer hardware) exclusively off solar power. You can purchase a retail solar system for ~$25,000 that will generate around 5000kwh , if you're willing to install it yourself. Personally, I bought B grade 5inch panels and built it myself. For under $7500 total. You can get b grade panels for a buck a watt. Since I don't care about being "off the grid", I use grid tied inverters, running my overage back into the gride during the day, and consuming grid power at night. Electric bill... Is less than they pay for postage to mail it to me, and about 12 bucks in taxes. |
|
|
|
|
Just wanted to toss in my thoughts on the project:
First, get over the smaller is better idea, Yes smaller gaps are nicer for lesser power consumption but it isn't essential. Most miners aren't going to care of the unit is a square foot or 3 square inches... as long as it does the work, and we don't have to modify the cooling.
What you should really look at is... using very large silicon with the gate structure being shallow and very very wide. What if you were able to process an entire nonce in a few cycles through a massive asic gate array... that's only as deep as it needs to be to to generate a single hash.
The amount of silicon wouldn't raise the price that much since you'd simply be making the process much more modular that current designs, and duplicating it over a much larger number of chips. You would raise the cost having to custom enclosure and heatsink for the large hardware. . . but you could recover some of that by using a larger process (90nm?).
The issue with this design is you need to have the software already optimized before making the hardware.
The downfall of designs in EVERY other asic manufacturer, seems to be using 'as small as possible chips' then having to run them at high clock rates and having them do repetative incremental work. Creating a need for custom cooling and stupidity like cooling the bottom of the pcboard with a mosfet cooler (yah BFL I said it). When the design goals should be exactly the opposite (aka load entire noncerange, process entire noncerange) then output flush and start with a new nonce range.
|
|
|
|
I use that one myself... very good unit imo. Be aware that it is infact 2 tiers of embedded (smaller) hubs. So the only way to max out the chain is by linking 3 of these to the 3 of the 4 usb 3.0 ports on your primary. |
|
|
|
|
Show Posts
