Why do you assume the requirement of t->inf for an exponential model to fail?
I don't know why you are insisting so hard on your "exponential growth will fail" thing. Yes, of course it will fail, if will fail much before infty because there is an upper limit for difficulty, otherwise it would not be computable. Furthermore, why do you call it "failing"? We will see saturation, but no "failing". That's how saturation (or, in your terms, "failing") looks like: http://home.arcor.de/wetec/rechner/cladekurve.pngI see no saturation on the Bitcoin difficulty graph. Not even a clue. http://bitcoin.sipa.be/speed-small-lin.png |
|
|
|
There are actually people that don't know difficulty will rise. And even if they do, there are people that don't know the difference between linear and exponential growth.
And a lot of those that think they understand exponenetial growth don't understand that it isnt' sustainable. Cmon... I'm not talking about t->infinity but about the next months and maybe years. By the time we will see saturation (i.e. no difficulty adjustment in either direction beside statistical noise) ALL of the hardware sold now will be useless (as in "not even mine its own electricity cost"). Mining is going to centralize in the future. Margins are getting thinner and thinner and then only companies which mine for themself and with simple designs will survive. The Bitfury "one string" design is the way to go. A lot of people are hunting the "Avalon batch #1" myth. Also what seriouscoin said in the post above. You want to win the mining game? Then don't play it. |
|
|
|
I think they are after some sort of virtual gratification, somehow they want everyone to thank them for their insight and sage advice. They have a saviour complex that needs to be fulfilled. I can't think of any other reason that isn't nefarious. Here is your reason: I spent $500 BTC so I can purchase a mining contract. Albeit, what I didn't realize that BTC difficulty will double in February and beyond. So it's kind of pointless to buy any mining rigs (unless if it's a terrahash rig -- different story -- most people can't afford it) or mining contracts, no? Any suggestions? Thanks.
(color by me.) There are actually people that don't know difficulty will rise. And even if they do, there are people that don't know the difference between linear and exponential growth. |
|
|
|
Leading on to my next question, will there be ASICs that can actually process hashes even faster? Yes. |
|
|
|
Here is a similar question. Bitminter pool the other day had a block that lasted a day and half. This block was not orphaned. Since it had the same transaction of all blocks during that time, do all the other block that were solved up until then get orphaned? Or do all those transactions in the other blocks get another confirmation, and the bitminter lengthy block just go through as the next block?
You were not working on one block during the whole time. The block you worked on changed. The expectation is to find one block every $network_difficulty shares - it's a stochastic process. The block(-data) itself changes every time a new transaction is added or if another block is found (previous hash in the header changes). Changing the block(-data) you are working on does not "reset" of your probability to find a block. Every calculation is either "win" or "lose". You don't make any progress towards finding are block while you are mining. It's just more likely that you will find a block the more hashes you computed (with $network_difficulty being the expectation value). You may as well find a block after calculating a single hash (some ppl found blocks with their solo-mining backup), or don't find a block even after having calculated 10*$network_difficulty shares. |
|
|
|
I realise that p2pool would be worse due to the faster block rate, but even with a 10 minute block, no LP support would reduce efficiency. Actually, it does. |
|
|
|
|
I'm sure someone can explain why having "Nov/Dec initial shipping" on your website while you clearly shipped nothing is not a lie.
|
|
|
|
So, where are the happy owners of the Monarch? I would love to hear some reports.  |
|
|
|
Sorry, that's not real time error detection. It would be impossible for a piece of software to tell if the hardware is making an error in any stage of a pipeline in real time unless it puts in a known value to be hashed and looks at the digest that comes out, but that's a one-off scenario. Otherwise the software would have to calculate the full hash itself every time which would be slow as hell.
If the error happens in a way that the last 8 bits (IIRC) of the hash are still zero, so the software cannot easily detect it as an error, the pool will still reject your share. If the pool didn't re-calculate the share you submit, you could submit loads of invalid shares and make money this way... So, it's really not possible to do any harm with "faulty" Bitcoin mining hardware. Bitcoin mining hardware manufactures might act in a way that makes some engineers cry - but, hey, it works well. VERY well. So I really don't see what's wrong with it. (Still, I get your point.) |
|
|
|
The only comparison I was trying to make was that you should design systems, Bitcoin ones included, with reliability as the priority. That's true for almost all systems, that's right. But "almost" is the key here. If I had to choose between an ASIC delivered now with an expected lifespan of 6 months and the same ASIC (same as in same performance, power consumption and price) delivered in 6 months with a lifespan of 10+ years, I would choose the former. Wouldn't you? For instance, I've never yet seen a bitcoin asic design with any kind of error correction or detection in it's pipelines, yet it's common practice for 'mission critical' systems. What mission could be more critical than making money?
Because it is not necessary. If you ever saw the screen output of miner software like cgminer, you will notice a counter for hardware errors. So there is your error detection. There is no need for correction, as you will just a throw away a invalid share. You actually do know how many errors your ASIC makes, and as long as it's low (like 1%), there is no problem. 1% HW errors means you are losing 1% of your hashing power. There is really nothing worse that could happen with hardware errors on Bitcoin mining hardware. It's not like you are transfering money to someone else if your ASIC returns an invalid share. |
|
|
|
I'm wondering; isn't it a security risk to ship the client with and a default rpcuser/rpcpassword set? This way you can connect to any dogecoind using the default login and issue RPC commands like "sendtoaddress". The use of the RPC server is not restricted by e.g. allowip=127.0.0.1 Am I missing something? Post full default conf please. rpcuser=doge
rpcpassword=wow
rpcport=22555
addnode=95.85.29.144
addnode=162.243.113.110
addnode=146.185.181.114
addnode=188.165.19.28
addnode=78.46.57.132
server=1
daemon=1
|
|
|
|
For my part, I'd much rather get a device that operates reliably within it's rated parameters that has been designed from the start to be efficient rather than buggering around to try to squeeze out more performance. Intel don't design 'to the limit', that's why their chips can be overclocked so readily, the engineers have built in a margin for error. The Bitcoin asic designers don't seem to grasp this point which makes me high suspicious of some of the 'credentials' trumpeted on their websites. I don't think you can compare Intel (et al.) CPUs with Bitcoin mining hardware. In the mining world, it's crucial to have your equipment up and running in the shortest possible time and to squeeze as much performance out of it as possible, as mining equipment becomes obsolete within months, usually. You actually don't need your equipment to work longer than, say, a year. But you want your Intel CPU to work longer than a year... |
|
|
|
I'm wondering; isn't it a security risk to ship the client with and a default rpcuser/rpcpassword set? This way you can connect to any dogecoind using the default login and issue RPC commands like "sendtoaddress". The use of the RPC server is not restricted by e.g. allowip=127.0.0.1 Am I missing something? |
|
|
|
Here is what you need to do. Take out 4 cards. Run your full rigs with 12 cards MAX. The mix and matched full rigs are unstable. 16 card full rigs will eventually become glitchy due to SPI bugs.
Losing 25% hashrate doesn't sound like a good option. |
|
|
|
When I do find a card combination that seems to work, it's not long before a card drops off and even a reboot or reseating the cards doesn't fix the problem. I've tried hundreds of card combinations, I pretty much have to rearrange them every time I restart. Which is like 20 times a day. If I don't, eventually only 1 or 2 cards will be left running. If any at all. I know that behaviour very well (from a total of 7 units, so at least it's consistent...). What I did to mitigate this was to follow the steps posted by punin: https://bitcointalk.org/index.php?topic=250249.msg3455392#msg3455392Although I waited 10-15 mins between the power off/power on in Solution B. Only waiting a short time resulted in cards still not hashing after the hard reset. Maybe there is some kind of fuse that needs to reset, which takes some time. Dunno. Nevertheless, the units are now hashing with 400++ most of the time. Also note that reseating the cards never changed/helped anything for me. Only a hard reset with the unit being turned off for at least 10 minutes got all cards back to hashing, with the config change proposed by punin (turn off auto-tuning) helped to keep them hashing... |
|
|
|
What part of the EU are you in? We have 16A in Germany. Sounds a bit dangerous. It's the Amps that kill you not the volts.  Yeah that's right. But 10A or 16A doesn't matter. First of all, you are dead even if it's just 1A. Regular breakers are not made for protecting people. You usually have a RCD for that task, which trips at 30 mA (that's 0.03 A). Beside that, 230 V are usually not enough to get a high current through your body, because the resistance is to high (you may want to look up Ohm's law). There's so much wrong and dangerous "knowledge" out there  |
|
|
|
|
Just to clarify, prawda is involved in this sale, yes. The avalon units are from a project we planned.
|
|
|
|
|
Maybe add some quote-tags if you want people read through this.
|
|
|
|
|
Eckmar ist wirklich so eine peinliche Nummer, das gibt es gar nicht.
Als ob dieses Gefasel von freier Energie noch nicht genug wäre - die entsprechende Wette wird auf seiner EIGENEN Webseite angeboten.
Ja hm, wie wird die Wette wohl ausgehen? Ich wette auch mit jedem über jedes erdenkliche Thema, solange ich über den Wettausgang entscheide.
Ernshaft, wie kann man diesem Mann überhaupt etwas anvertrauen, und wenn es "nur" Rechenleistung ist?
|
|
|
|
|
Sorry.
WinterParker 1@0.5
sebdude420 2@0.5
electronrancher 1@0.5
poochone 1@0.5
|
|
|
|
|
Show Posts
