how does the whole thing behave if i use e.g. 2 gekko usb hubs with 3 compac f each?
does each hub then have its own mining power from the 3 miners in mentioned or can the mining power of the two hubs, which is generated by the 6 miners, be merged? All miners on all of the hubs are automajikly found and used by the 1 instance of cgminer. While each stick runs at its own (varying) diff and reports its own results, the total hash rate of all the miners are combined and reported as an aggregate hash rate. |
|
|
|
Are there so far any chips for mining that are branded with samsung? So far I have never seen that and could only imagine that they produce under another name. But if they now have 3nm I think they would use 5+nm for mining, if even. The Canaan A921 using chips from Samsung was the 1st 7nm miner to market beating Bitmain by almost 6 months. Not sure if they did the chips for the A10x series but AFAIK they make the chips for Canaan's A11xx and A12xx miners. They made the chips for MicroBT's M10 & M20 series and I'd think probably the M3x series as well. As I said above, last year they also became a 2nd-source supplier for Bitmain after TSMC slashed mining chip production to free up production for more valuable chips. |
|
|
|
Having the protocol be the least common denominator is exactly what the protocol architects should be striving for. Everything else is an implementation detail. What you describe already exists: Sidechains such as LN that at their base level are tied to Core and the main BTC network. Sidechains lets folks explore a myriad of possibilities as long as in the end it's compatible with the BTC protocol while (hopefully) having zero or at worst only a minuscule chance of undesired impact to the main BTC blockchain. Any risk in using the side-chain MUST be only to the operators of the side-chain service and its users and not anyone else using BTC. Again, if what those side-chain folks come up with truly serves a truly needed purpose then ja, the Core devs should consider it provided it does NOT break anything or otherwise extensively modify the basics of how the BTC network operates. |
|
|
|
The thermal shock does not have to do with humidity?  are you serious? I think you need to go back the college and take thermodynamics classes. Riiigggghhhttt... Only been designing/building industrial power electronics and cooling systems for them since 1975 so...  Yes the moisture content (humidity) of an airflow does impact its heat transfer rate as the air stream flows over a surface (here, heatsinks) - more specifically, it changes heat-capacity of the air - and as such deserves consideration when designing the heatsink structures, their surface areas and type of airflow needed BUT that has nothing to do with the purely mechanical nature of what thermal shock is. For a top of the Google list reference see https://www.corrosionpedia.com/definition/1079/thermal-shock They are two very different and separate design points to consider... Thermal shock is induced by fast and sizeable thermal cycling - not cooling efficiency at any given point in time. If the temperature swing is extreme, rapid, and the material is a particularly fragile & poor conductor of heat - say a glass heated to a couple hundred degrees and then plunged into water - the material cracks/shatters from the wildly uneven stresses that are induced by thermal shock. For less fragile materials the damage per-thermal cycle is usually far lower but it *does* add up if the material is not self-healing. Back to the main point of the thread, an AC system needs to be properly sized for where it is operating and the design heat load + a reasonable reserve margin. If sized correctly and one is not sucking in too much unaccounted for tropically hot & damp air from say, a swamp next door, the humidity in the room where the miners are will be very low no matter where on the planet you are because the AC runs long enough to remove the moisture. The primary problem that excessive humidity can cause- condensation leading to corrosion - is eliminated. |
|
|
|
|
Query: What is the power limit for what you can supply back to the grid in NJ before you have to go through the state PU commission for permitting as a regulated Grid Power Generation site?
In Michigan it is anything from 500kw on up no matter what the source is be it solar/wind/hydro/waste gas/ et al.
|
|
|
|
Compared to most alts Bitcoin's development already is moving at a glacial pace  And for good reason! But I fear increasing the political overhead would pretty much halt development and possibly even increase developer attrition. @HeRetiK: I agree with you, and I'm beating a dead horse at this point, but I have a different definition of "glacial" and would much prefer it if the design was basically set in stone, never to be tweaked again. I don't have the same appetite for improvements that most people seem to. Of course, that's blithely ignoring real issues like quantum cryptography, but I suspect that even once Bitcoin is "post-quantum" there will still be many more upgrades than are strictly necessary, with each one being an opportunity to get something wrong, with possibly disastrous consequences. I intentionally worded it like that, because I already addressed why its not encouraged in my first reply (i.e. the protocol becomes the least common demoninator, which is exactly what the protocol architects do not want). @NotATether: Yup, can't argue with that. Agreed.  Considering that BTC is a Financial System, it is admirable that so far the Core dev team have taken what in financial circles is called a Fiduciary approach to making sure the BTC network works securely as intended including an immutable and easily accessible record of all TX's back to the Genesis Block and nothing that is added breaks its intended purpose. In lay terms it translates to, "Once something Works - DO NOT SCREW WITH IT unless there is a more than compelling reason to change it/add a 'Feature' to it". When there is a non-critical but valid reason, get a feeling how the major parties affected feel about the idea. If it is worth pursing then review the hell out of the code followed by tests the hell out of it with edge-cases before release. Rule #1 to that is Thou Shalt NOT Break Code! Everything created since day-1 (TX's) MUST be maintained and unchanged and seamlessly accessible by the new code. I'm more than happy to let the altcoin folks experiment with interesting ideas for using blockchains and I'm certain that the Core developers watch what they do as well to see if what the alt folks come up with could *possibly* fit in well with "The BTC Manifesto" so to speak. edited for text flow |
|
|
|
|
Um, apparently others here seem unaware that Samsung DOES have their own Foundries and have been producing chips for their internal use as well as for outside customers for decades... The 1st three Foundries to get the EUV lithography equipment needed to produce chips under 7nm were in this order Intel, TSMC, & Samsung followed by Global Foundries and a company in Japan. AFAIK those are the only 5 companies on the planet that have EUV litho gear.
Samsung has made mining ASICs for Canaan, MicroBT and are a 2nd source for Bitmain's chips.
|
|
|
|
|
Maybe.
One has to remember that the only reason TSMC produced so frickin' many fairly low cost 5nm chips for Bitmain is that as I've repeatedly said before in other threads -- the uber-simple mining chips are great for fine tuning production processes before said tech is good enough to be used for more valuable and far more complex chips. Mining ASIC's are very tolerant of defects so even imperfect production processes still produce enough salable chips per-wafer to be worthwhile and that makes them perfect testbeds.
Once the processes have decent yields one can then expect any Foundry to:
a. shift the majority of their production capacity to more valuable chips
b. raise the price for mining ASIC's
|
|
|
|
|
@ Cygan
Your post is off-topic.
Since that is NOT one of Sidehacks's Compac sticks you need to create a new thread for it. When you do it would greatly help if you tell us just what it is...
|
|
|
|
|
It was an A721 bought about 2 months after they were introduced.
That was quickly followed by 2x 741's then 2x 821's and 12x 841's as they were introduced. Then 921's, 1041's, 1047's and now one of the A1246 93TH ones.
|
|
|
|
|
It will be interesting to see how this plays out. The few specs you released seem reasonable.
|
|
|
|
|
Link to their PR announcement please?
Nothing you quoted alludes to their 3nm process being used for mining chips. Unless they're planing on following what TSMC does and are using mining chips to fine tune their production processes odds are more valuable devices are 1st in line for the new node.
|
|
|
|
@achow101: I agree with basically your whole post, but could use some clarification on this bit: Suppose there is some bug in one implementation that others do not have, and this bug causes that implementation to reject blocks that other implementations accept, thereby causing a chain split. This could be very dangerous and result in people losing money. And so people use this as a reason to advocate for homogenous implementation because chain splits are generally bad.
I'm not yet far enough along my path to understanding Bitcoin to have much confidence in the argument I'm about to make, but I'll try it anyway  Doesn't the chain split regularly, because of occasional mining "races"? And aren't these little splits resolved by simply following the longest chain? ... For one, orphan races are not a regular event. For another, the average 10 min between blocks ensures that the losing chain is never more than at most 2-3 (very fast but not fast enough) blocks long so transactions in blocks built on the losing split are regenerated and soon re-confirmed in the longer chain. The Txs still exist in the mempool so no double-spends can happen, it's just that they have to be reconfirmed. |
|
|
|
...it will run even at below 200v, but then your miners will RIP if that happens too often.
Is there a place where this is elaborated on? How many cycles of <200V would cause the miner to RIP? I'm asking because I'm interested in how many cycles a standard S19 PSU could be at 0V before RIP. Short answer: not many and for any 1-event not for very long. If for some reason the miner/PSU continues to operate you risk serious damage to the PSU. Good part is that the PSU *should* shut down before damage occurs. Bad part is that given your concern I take it you have a very low/unstable power source - big problem. If the main issue is just a line that normally holds around 208VAC (preferably higher) and occasionally may drop below 200v you may be ok, just expect the miners to hopefully shutdown and then restart once the powerline is back into a usable range. If dropping to a low line voltage is a fairly common thing you need to address that. |
|
|
|
It could cause you problems, the thermal shock generates humidity and therefore affects the electronics of the PSU Random and very incorrect speculation written by someone who has no understanding of cooling processes. 'Thermal shock' has nothing to do with humidity but it *can* affect connections and solder joints. Thermal shock is the result of different materials that are in contact with or bonded to each other expanding/contracting by different amounts when their temp is changed. Stress in the joint builds up and later released when temp cycles up and down. Thing is, the temperature swings needed to be rather significant, happen often, and relatively rapid to cause it - as in at least several 10's of degrees per minute. Yes if the AC is pointed directly into the intakes of a miner and the AC frequently cycles on & off then you could introduce thermal shocks to the components. As for the 'humidity' bit -- if you mean condensation and if the AC is oversized enough to be running for just a short time followed by long times of being off then yes, excessive humidity not removed by the AC remaining in the air could very well condense on any cold surfaces and cause problems. |
|
|
|
I find that really unfortunate. I think alternative implementations should be encouraged.
I enthusiastically disagree. If there are two independent Bitcoin clients with roughly equal market share, then the protocol becomes the intersection of supported features on both clients. The protocol is no longer singularly developed ahead of the reference implementation. It will be possible for some feature to be added to the protocol (by people who also happen to be devs of the first clients), but the second client torpedoes the feature by not implementing it. This is the exact hell that is facing LN at this very moment. It's the reason why you don't see any major improvements to the PDF format. Because ISO standards have a tendency of staying put.NAT hit the nail on the head. The whole point of a Standard is that no single entity - eg Adobe or Microsoft et al - can futz with it by adding 'features' to make it more their own format - and in turn therefore attempt to make any other versions less desirable to use - based on their own particular marketing plans. Adobe in the past attempted to do exactly that every time a 3rd party put out a pdf reader/writer like Foxit Reader and initially MS's implementations of it tried to add 'Features' geared specifically to the 'Doze OS. The whole point of pdf was to have a universal document format that is not tied to 1 specific software vendor or OS and to have documents produced using it to be able to be easily accessed for decades without having to find an old copy of the software that produced it. Ja the bitcoin protocol is not managed by an outside entity like ISO but until (if ever) it is, having Core as the sole official implementation of it is the best we can have. The developers involved with Core bend over backwards to ensure that any changes made to the BTC protocol have a REAL and useful functional purpose and do not break older versions. In the case of LN obviously the various developers could care less about that because they have their own agendas. |
|
|
|
I mean, maybe we could be a group of 40 or less and get together and run a low-cost version of the Bitcoin network with a few nodes and a limited number of hash miners between us, like in the early days. You mean a clone with no value whatsoever. There is already a network for you, it's called testnet, and seems like it has only 500Th/s right now, so you could mine not just one but quite a few coins even with an old ASIC that is valued at scrap metal price. re: Testnet. Keep in mind that any coins mined on it are eventually supposed to be either donated/returned back to the Testnet coin faucets where they are originally generated. For example the one ran by mempool.co Testnet and its coins exist for the sole purpose of testing mining software - not for mining and accumulating Testnet coins. It is expected that after testing is done all coins generated are returned to their source. Folks mining Testnet coins and then hanging onto/selling them is why it's up to v4 or such. To stop that each version makes the older ones unusable on Testnet. As for making a clone coin it also must be said that you would be creating yet another worthless altcoin - it cannot/would NOT be "Bitcoin". BTC is 1 specific crypto coin and in-turn 1 specific protocol and blockchain, period. "Bitcoin" not a generic term for any other crypto coin including those that do use sha256... That said, coming up with your own coin just for the heck of it can be fun. Something like five thousand or more altcoins have been created just for that sole purpose. Heck, a couple including of course Dogecoin are even worth something. Given that fact this thread belongs in the altcoin areas of the Forum or at best the General Bitcoin Discussion area - not here in the BTC-only areas- so expect the mods to move it. |
|
|
|
|
Try running your command string starting with sudo. Normal install does not let you run without it. Somewhere in this thread is info on how to run a as normal user that will not require the sudo prefix.
|
|
|
|
|
Show Posts
