You guys are all smartypants, so let me know if I am correct.
Let's say sometime down the line we switch to SHA3 (or whatever new hashing algo).
FPGA's/GPU's/CPU's would be fine, while ASIC's would be hosed, correct? Or am I wrong?
All mining software would have to be redeveloped, and re-optimized. ASICs would then be useless, but I'm sure you could find a buyer in the server (crypto accelerator) or hacking community if you had a mass number of ASICs that calculate SHA256... That is what I suspected. Thanks! |
|
|
|
Thanks for the update. I was wondering, but figured changes were being applied.
It's still lagging, I may just put the replication server on a new 8core server. The pool is fine, but the website is a bit laggy right now. Hopefully you are working on live estimates  |
|
|
|
|
You guys are all smartypants, so let me know if I am correct.
Let's say sometime down the line we switch to SHA3 (or whatever new hashing algo).
FPGA's/GPU's/CPU's would be fine, while ASIC's would be hosed, correct? Or am I wrong?
|
|
|
|
bump, still available. Accepting BTC, Mt. Gox, Tradehill only.
I will give you 16 BTC shipped (Maryland) for the Mobo, Ram, and CPU (which is what you are asking for it basically). As long as I can send it back if it is DOA. |
|
|
|
|
I have updated the quantities.
I am curious if people are interested in buying 90% silver US currency (pre 1964 dimes and up) for bitcoin. I have a bunch that I have obtained over the years, and would be willing to sell at spot (plus shipping). Clearly, it isn't going to be some gem MS-66 bust pieces, but it shouldn't be THAT ugly either. I sold most of my really junk pieces when silver was like $22 per oz in 2007 (d'oh!!).
Right now spot is $31 per dollar in bullion. So around 3 btc (a little less) -> pre 1964 dollar.
If people seem interested I can post some pics.
|
|
|
|
So since there are no bulk discounts for FPGA's, and they are the most expensive part, you don't have to buy them until you get the full order in for people (or maybe just before).
If you need front money just to buy the boards, and some of the cheaper stuff, you should let us know. I am willing to front some of the money for this, or pay for entire cards up front if it helps you obtain discounts (which you can hopefully pass on to us somewhat).
That's a good point, but then you have to deal with shipping on each of those FPGA orders. Li works in Singapore, so that's international shipping, too. Also, like I said, we can't really use any Paypal money to order parts until the finished board is shipped to the customer. We're working something out, though, so we'll get back to you soon. Let me know for real. I am happy to pay for a dual FPGA up front right now with bitcoins if it helps you raise the needed capital to fulfill all your preorders. |
|
|
|
Actually, the size of the order is still going to be quite small, despite the 42 pre-orders. Unfortunately, Cablesaurus can't use any of the deposits that came from Paypal, because of the risk of chargebacks. None of the Paypal money can be touched until the actual order is shipped with a tracking number.
It's great to see that there is so much interest, though! As of right now, the $420/620 price point is still about right, with only a small profit in there for us to compensate us for our time.
The biggest problem with quantity discounts is that we get absolutely no discount for ordering FPGAs in bulk. It's going to be the same price to buy 1 as it is to buy 50. All of the rest of the parts are minor compared to the FPGAs, so I don't see the prices dropping as significantly as newMeat has hoped. Of course, we'll do our best!
So since there are no bulk discounts for FPGA's, and they are the most expensive part, you don't have to buy them until you get the full order in for people (or maybe just before). If you need front money just to buy the boards, and some of the cheaper stuff, you should let us know. I am willing to front some of the money for this, or pay for entire cards up front if it helps you obtain discounts (which you can hopefully pass on to us somewhat). |
|
|
|
Just to be clear, are the 2 chip and 1 chip boards the same? Yes. Whichever one you choose, it will help us get a volume discount on the PCB's. My team is going to buy 10 to start us off! -- to sell later on eBay or for people who miss preorders I am strongly considering preordering 10 as well. |
|
|
|
Sirky- I wonder what the best way to mount a bunch of these would be. Surely just laying them somewhere cannot be most efficient.
What are the physical dimensions with the heat sink on? For the next batch, we are looking at a 3.4in x 4.1in rectangle. I don't know exactly what the height will be~ probably about 1.5in with the heatsink. We're definitely gonna put some mounting holes and standoffs in, so you can stack them vertically. Here's the kind of standoff I'm talking about: http://media.digikey.com/pdf/Data%20Sheets/Daburn%20PDFs/10-40_1.pdfJust to be clear, are the 2 chip and 1 chip boards the same? |
|
|
|
I don't like being so low in the share hash list when I used to be #1. I am getting the mining shakes I think  |
|
|
|
I was asked to comment on this issue. I'm providing a claim that Vlad's analysis is incorrect. Since many of the people that read this thread are statistical laymen, I'm going to walk through this step by step. First off, approximating the distribution with one huge encompassing Poisson Distribution is not the best choice in this scenario. A much better choice would be use the central limit theorem to approximate this Binomial Density separated by difficulty. The Poisson is only valid under certain criteria while the central limit theorem is pretty much good whenever n is large. I will show my work for one iteration of this procedure and produce the results for the rest. Taking difficulty 434877 as the example to go off: // Notes - bolded letters are estimates of what the true value should be (estimates taken from Vlad's sheet) // n - sample size // p - estimated probability of success // p = x/n, where x is the number of successes (estimated blocks found) Y ~ Binomial(n, p) n = 2016 p = 135.705/2016 = 0.0673 Y ~ Binomial(2016,0.0673) From the central limit theorem, we know that a Binomial of sufficient sample size will follow a normal with mean n* p and variance of n* p* q. Therefore in our example our distribution becomes the following Y ≈ Normal(n* p, n* p* q) Y ≈ Normal(135.677, 126.546) To calculate the probability of getting less than some number observed Y (actual blocks found), all that's left is to convert our normal distribution to a standard normal and look up the p-value. P(Y ≤ 134) = P(Z ≤ (134-135.677)/sqrt(126.546)) = P(Z ≤ -0.149) = 0.440 What does this value mean? This means we are 44% likely to see a value this extreme or more at this difficulty(434877) which is completely acceptable. Things to consider with a grain of salt. We gave an estimate for p when in fact p actually changes quite a lot during each difficulty with all the hashing power changes. I've also made a mention on the spreadsheet for occurrences that might indicate something odd happening, explained by DDoS attacks or other systematic errors fixed by patches later on. If this original value value that Vlad had stated was true, I would be concerned. However, thankfully this is not the case and I hope everyone can see the sense and reasoning posted here. The remaining p-values are below for convenience and the sheet that I used to calculate said values is linked: https://spreadsheets.google.com/spreadsheet/ccc?key=0AoAyWRmssbLKdHduLURqdENHckw0SzRNX3JhN3ZKV2c&hl=en_USDifficulty| P-value Verdict 434877.04 |0.439 Nothing wrong at all 567269.53 |0.000 Check For DDoS/Other Systematic Errors 876954.49 |0.449 Nothing wrong at all 1379192.28 |0.341 Nothing wrong at all 1563027.99 |0.040 Statistical Anomaly 4% chance? 1690895.8 |0.331 Nothing wrong at all 1888786.7 |0.001 Check For DDoS/Other Systematic Errors 1805700.83 |0.720 Nothing wrong at all Before I say this, I just want to say that I completely trust Eleuthria, and I do not think that he is gaming the pool. I have chatted with him many times on IRC, and though I don't mine here anymore, it is only because it is proportional. Anyway, I am not sure I follow the logic of breaking it out by individual difficulty. If there was theft, it would show up by everything being slightly lower, and only when you add them up do you get something significant. I added everything back together and get .02% chance it was caused by luck. This really is the best one to use. I do believe that this was caused by technical issues coupled with legitimate bad luck, and not theft. As an aside, this only covers the hiding blocks from bitcoind from the pool. This won't detect fake workers. |
|
|
|
Nobody can predict the future, but the past is not as mysterious; the number of shares already submitted during this round, at the time of deciding on a course of action, directly affects the estimates of what the eventual length of the round will be. Umm - how can you start a sentence with a fact and end it with the exact opposite of that factual statement? You've just stated correctly that you cannot predict the future, but then said the past affects the future. What? If a round already has two million shares, and difficulty is two million, your estimate for the round is that it will be four million shares. The two million already mined are important. Simplest link to verify it: http://en.wikipedia.org/wiki/Gamblers_fallacyI'll put it this way: Once you have mined n shares, there is absolutely no change in the probability of finding a block in the next share than there was in all of the previous shares back to the first. True Secondly, regarding your copy of Roulo's suggestion that pools that pay based on share% mined are affected detrimentally by hoppers
(or: hoppers make more BTC by hopping)
Let me use the simplest way to disprove a theory: An example that fails the theory will show it to be false. What? This isn't true at all. Statistics is not high school science. A single counterexample proves nothing. We are talking about what should happen over large timeframes. Take this statement from Roulo's document: It means that with optimal strategy it is possible to gain on average 28% of ones hashrate by switching from the pool after 43.5% of the current difficulty number of shares have been contributed. Notice that the function is fairly flat and even after switching after λ = 1, one can gain a fairly respectable 22% of ones hashrate. Thus stating that from 43.5% to 100% (λ = 1) there is a gain between 28% and 22% Yet a simple example with 50% shows this to be false: If you mine with a share% of 10% at a site for 50% of the expected time to find a block, then, your shares will be worth on average 5% instead of 10% (since your % will slowly drop, after you leave, to 5% (on average) until the block is found) During this time you can go to another pool with the same hash rate and do the same thing ... and thus get a total of 10% (5% from each) ... which is what you would have got to start with - not anywhere near 20% extra ... I have no idea what you are trying to say here. But I am positive it doesn't make sense, because it is an indisputable fact that you make money by hopping proportional pools. Let's say there are two pools, one with 0 blocks mined this round, and one with 10 million blocks mined. You are claiming it doesn't matter which one you mine. If you are going to be 10% of the hashrate of each pool, and difficulty is 2 million, in theory if you choose pool A, you will make 200000 / 12000000 * 50 = .83 btc If you choose pool B you will make 200000 / 5000000 * 50 = 5 btc. Go back to my first point. That seems to be what you don't get. The number of blocks mined already does affect the average number of blocks that it takes the solve a block this round. |
|
|
|
|
I wonder what the best way to mount a bunch of these would be. Surely just laying them somewhere cannot be most efficient.
What are the physical dimensions with the heat sink on?
|
|
|
|
Block #12  Well done thientibc! Isn't it Block #11 (or Block #10 if you count from 0)? This seems to be quite a lucky pool. mineco.in (which also uses PPLNS) has been working away at a consistent 90 Gh/s and hasn't found a block in 4.5 days. Yes! Since SC kept track of blocks! There was one before all the upgrades/revisions! I stand corrected. Who found the first block? |
|
|
|
Just joined and added 4 ghash. Much thanks to Sirky to help make that possible.
I'm glad to see such serious miners joining this pool. For me the PPLNS reward system is the primary reason for mining here but I'm also grateful for the new server and the various top-30 lists (which, for me, creates a sense of community). May I ask why other people are joining this pool all of a sudden? I got 1gh/s taken away from me and added to hmblm1245, so we are all even in the long run |
|
|
|
I am working with SC on trying to make estimates more accurate and payouts more transparent (so you can see exactly how many of the last N blocks you submitted for a block).
Excellent, I'm looking forward to this. Along these lines I would be interested to see a top-10 lowest reject rate list. This would perhaps further encourage people to try and lower their rejects further and ultimately the pool will be able to boast an impressive "pool efficiency". I have 5 BTC ready to donate to the pool following enhancements as you describe. I like the idea of a lowest reject rate. Perhaps once the bugs are squashed I'll look into implementing that. Take your time and enjoy. I've just visited the pool stats page and was amused to see that the three most recent blocks have been found by the 28th, 29th, and 30th fastest miners. Tsk tsk you guys near the top of the hashrates list; it's quality not quantity!It's funny you should say that! The block I found, was by a lone 5850 mining! Most other blocks have been found by 200-700Mh/s miners! IIRC, All but sirky's block, have been a lower tier worker finding the blocks! 5 500 mh/s miners are the same as 1 2.5 gh/s miner. So the little guys have strength in numbers |
|
|
|
Congrats for reaching 50 GH/s by the way |
|
|
|
|
I am working with SC on trying to make estimates more accurate and payouts more transparent (so you can see exactly how many of the last N blocks you submitted for a block).
|
|
|
|
While I have done a lot of development in the past, it was 100% software development. I have done absolutely nothing hardware related in my life, and wouldn't know where to start. I hope this project continues though!
It certainly will contiune, its just a question of speed. Such people as you are ones we are currently lacking. We desperatly need a firmware and software part for the MSP 430 or any other simmilar chip providing most of its funcitons so it you be great if you could focus on the software part. Perhaps you should break down exactly what this software would be doing. I am envisioning some sort of C or assembly giving direct instructions to various hardwares, which seems sort of scary for someone who has mainly done warm and fuzzy C# and some web stuff (CSS and HTML) in the last five years My problem is that I am so unfamiliar with this sort of project I wouldn't know where to begin. |
|
|
|
|
Show Posts
