Hence merged mining. The more blockchains you need to secure the more useful merged mining becomes.
-MarkM-
I don't want or like merged mining, and it's not a solution to the flash mining pool problem, it just duck shoves the problem to some other coin dev. |
|
|
|
If the coin is already on the exchange, no need to mine it then - just buy it and wait for the price to go up, sell it and profit. This is pure arbitrage and has nothing to do with mining. Mining most profitable coin is mostly about difficulty and not about the price because people who switch between coins would usually sell coins right away.
A coin without mining is worthless, how do you think the transactions are achieved? When a coin is locked at high diff because of a flash mining attack, the transaction time can be screwed for weeks on end as we have seen with CNC and FTC. This can lead to the coin being removed from the exchange. |
|
|
|
Someone pointed out in another thread that these chain-hoppers screw themselves as well as everyone else, because if they were careful not to throw "too much" hashing power on a chain they could milk it of many more blocks than they can if they stick its difficulty as high as possible as fast as possible then leave.
I do not know though if the writer was correct. The idea was theh igh difficulty was lowering the total number of blocks per hour or day or whatever so much that there would have been many many more blocks to grab in that timeframe by carefully ensuring the difficulty did not rise, or only rose minimally or something like that.
Jump in fast, grab 100 blocks in ten minutes, no more blocks for a month, versus jump in less precipitously, get 100 blocks or more per day for a month, kind of concept.
Maybe they just didn't do the math and the total blocks the chainjumpers get is the same either way?
-MarkM-
Yeah that was me in the ARG thread, the idea being that the pool would work our a desired difficulty in advance to keep the coin below based on the nethash of the pool added to the coins nethash. Then vary the mark/space ratio of when it mines to keep the profit as high as possible. eg. mine the coin for a predefined number of blocks, mine another coin or two, until a predefined number of blocks have passed on the first coin then go back to it and mine it for a certain number of blocks again. Rinse and repeat, recalculating the optimum number of blocks to mine each time to maintain the desired difficulty. I doubt if the pool operators would bother to do this, they seem arithmetically lazy to me, else they would have already worked out that they are forcing their users to spend most of the day mining inefficient high difficulty, high hash rate coins that are tolerant to the hopping effects of their net hash like LTC,FTC. The claim that flash pools are "always mining the most profitable coin" is bogus, because to make it happen they destroy the profitability of other coins for extended periods of time, so the less profitable coins look better. The best money to be made is mining the lowest diff coin you can get away with, not just for 20min then bouncing to a high diff coin where you have no impact or decent share, just because you have smashed down all the way more profitable coins. |
|
|
|
I have noticed that it takes about 10-12 blocks of ARG when it hits high diff before multipool bounces to the next victim. This suggests a coin with a diff adjustment every 20blocks or less would be a viable easy solution. Another approach is to make the diff change after a set amount of time say every hour or even half hour. That's the solution I would like to see, this block counting method is just wrong.
Constant readjustment isn't good either. The retarget time is fine if hashrate doesn't go up or down 4000% instantaneously. Constant block count readjustment can work if you limit the effect to a certain percentage. eg. a 25% difficulty change every 30min. |
|
|
|
|
I have noticed that it takes about 10-12 blocks of ARG when it hits high diff before multipool bounces to the next victim. This suggests a coin with a diff adjustment every 20blocks or less would be a viable easy solution. A better approach is to make the diff change after a set amount of time say every hour or even half hour. That's the solution I would like to see, this block counting method that everyone uses is just wrong. It's one of the legacy design faults from the original BTC.
|
|
|
|
|
I am also getting the "stratum connection to pool 0 interrupted" hang issue with 3.3.1 and windows 7
Have to close the command window and start a fresh one.
|
|
|
|
Where is that buried under? So if someone bought 100000 jupiters 1 week ago and i buy 1 today I still get it in october? 1+1 not adding up to 2 for me.
They would remove the notice if it were no longer relevant don't you think? You couldn't place and order for 100,000 jupiters as their shopping cart would tell you there was only 1,931 left in stock and "Order contains unavalible products count" |
|
|
|
Not actually pointless, my question was simple although I did interject some extra speculation. Wondering when you would get a product if you ordered now? Only info i see for new orders is that shipping starts in sept like you pointed out. Do they have enough chips in the first order of chips from the foundry to cover any new orders, and if so up to how many units does it cover past the initial?
The number of units their chips cover is KNCminer business, and probably confidential. If you look at their site. you would find:  This has already been mentioned today. |
|
|
|
I guess but would be nice to have an idea of their initial capactiy, which is why i was asking if anyone knew what it was. I'd think they wouldnt be placing more chip orders until they at least get one batch in. So shipping starts in sept for batch 1 ?? 2014 for batch 2? who knows.
When you place a pre-order for a product that has never shipped before, you take your chances! If KNCminer are smart they would have ordered enough chips to keep some stock, I am sure that's what BFL tried to do, but it all fell apart when they discovered they would need twice as many chips per unit to meet the performance they promised! Because it take a couple of months for a chip order to be manufactured, you would want to order at least two months more chip stock as you had orders in hand for, but the gamble is always will the chips perform as simulated, and is the order rate consistent hence predictable? When the chips come arrive in September, and KNCminer test their prototypes, we shall know more, until then everything is just speculation, and probably a little pointless. |
|
|
|
Back to the topic of KNC. Did they ever say how many chips they have on order? Wondering how they are still selling miners on their website saying shipping in september.
It says "Shipment begins in September" when I just looked, which doesn't mean if you place and order now you will get it shipped in September, but it certainly suggests you wont get it before September. |
|
|
|
What BFL SHOULD be doing is burning the chips in, and binning them based on performance. Who knows why they're not.
I don't understand the point you are making at all. With the exception of the MiniRig, BFL don't run their chips flat out, that's why speed bumps are available over the base unit. The MiniRig has been reported at being 480GH/s instead of 500GH/s but I don't know how many people experienced that, I have only read the one report. Running your chips below their maximum stable clock is a very different thing from completely disabling functional engines. One may be an optimal trade-off with power consumption and chip lifetime; the other simply wastes potential. No kidding, that's why people are having fun unlocking the potential with firmware upgrades! |
|
|
|
What BFL SHOULD be doing is burning the chips in, and binning them based on performance. Who knows why they're not.
I don't understand the point you are making at all. With the exception of the MiniRig, BFL don't run their chips flat out, that's why speed bumps are available over the base unit. The MiniRig has been reported at being 480GH/s instead of 500GH/s but I don't know how many people experienced that, I have only read the one report. |
|
|
|
I assure you defects are quite real. I looked at one today under a scanning electron microscope. I think it winked at me. Or maybe that was the astigmatism...
Clearly, BFL is just as incompetent at binning their chips as they are at making deadlines.
BFL don't make the chips, and they are only 65nm, I can just imagine what you would find on a 28nm chip. |
|
|
|
Certainly BFL has encountered issues with killer defects on their chips. Know what they do? They disable the regions with defects and bin them. Suddenly there's not much correlation between yield and die size anymore.
(Intel does this also, and their chips are *much, much* more complex. Then again, if you ever had to deal with those fuckers, you'd understand how they get their defect concentrations down. "Our spec is zero defects, hurr hurr hurr... Your recipe creates 2 defects per wafer..."
Sorry, sorta got an axe to grind with those guys)
Anyway, here's to hoping that KNC is at least as competent as BFL.
Except when you read the threads in this forum where people have changed firmware and activated all the engines on their BFL chips, the results have been really good, so much for that theory! |
|
|
|
|
Just what we need another coin!
|
|
|
|
|
So it's been almost 38hours since multipool.in forced ARG into high diff. In that time just 230 blocks have been mined, where it should have been around 4,275 blocks. So that's over 4,000 blocks that everyone, including the users of multipool.in didn't get a share of. The greedy rush for a quick 250 blocks wastes 4,000 blocks. It's relatively simple arithmetic to work out how many minutes in an hour a pool with around 400MH/s could mine a coin ARG for maximum sustainable profitability, instead of rushing like a bull at a gate and ruining it for all.
The end result of course, is that multipool.in users are forced to mine high diff, energy expensive, coins with a high hash rate like LTC, FTC or even DGC for hours on end where the can't achieve the majority of the hash rate, instead of the far more profitable low diff alt coins. Quite sad really.
|
|
|
|
|
It amazes me the number of gullible people that even think that a commercial consumer complaint falls under criminal law, instead of the relevant consumer legislation.
|
|
|
|
Lol the best Germany could do would be ban import, they have no other jurisdiction, BFL are not in the EU. How would that help the customers? It would certainly help other BFL customers around the world as they would move up in the queue.  I smell another smear thread. |
|
|
|
multipool.in are responsible for most of that. Read the ARG thread if you want to know more about the problem.
It is in ARG Announce thread? Yeah, most of the last few pages, it gets a bit heated, but still worth a read. |
|
|
|
|
Show Posts
