Not one based on the bitcoin algorithm.  Litecoin is already too fast most likely.

The Bitcoin algorithm is not convergent when the highest latency (including all block validation time) bisection of the hash rate becomes higher than the mean time between blocks. E.g. if a chain has a 3 minute average block time an it takes 3 minutes for some half of the miners to hear from and validate another half, then most of the time a new block will be found in each half before it's heard about the other half's blocks and the two will form longer and longer forks, which take longer and longer to reorg between. The result is a partition with the halves not able to agree on the history of transactions.

At current transactions levels (which are only a portion of the maximum allowed) Bitcoin is already seeing multi-minute propagation in some cases.

Litecoin's blocks could well be far enough apart to escape being doomed from this— escaping with just needing to wait for some more confirmations to cope with larger reorgs due to slower convergence (as the number of confirms you must wait for a given confidence goes up as you approach the latency bound); but it seems unlikely that the bitcoin algorithm could go much faster successfully.

It's a shame people don't even bother to learn from all the failed altcoins who have twiddled Bitcoin's parameters without understanding them or their reason for existence. They weren't set the way they were just to piss you off.

Except LTC can also take 90 minutes for a block too, it will just happen less often.

Maybe. The current reference software sorts transactions by fee per KB data size. Due to rounding that tiny increase may make no difference depending on your transaction size.  Paying less that the base fee won't help at all, very tiny fees are just treated the same as free transactions.  Historically even the base fee would have given you a substantial advantage. But the dice site is flooding the network with 0.0005 BTC fee transactions so free and 0.0005 transactions frequently get to wait.

No, LTC mining intentionally used parameters _far_ smaller than the scrypt recommendations—  You only need ~128k.
I'm sure that there is enough distributed sram on those FPGAs for that, although there may be routing constraints or not enough room for them and the hashing engines.

The reason the GPU scrypt miners use a lot of memory is that they must run many instances in parallel to get high performance (to hide the memory latency and to use all execution units).  A typical FPGA Bitcoin miner runs just one instance unrolled.

Because the software doesn't know it isn't done, otherwise it would continue.  It happens now when the peer you were pulling from goes aware or becomes unresponsive. One of the things about making a secure zero trust client is that you just can't count on 'servers'  to tell you what you need to know, there is a lot of complicated interlocking behavior which can have unexpected outcomes.  Improving this aspect of the IDB processis planned, but software isn't written through wishes.

If you'd like to contribute please test and write procedures for testing and report bugs, or chip in on fixing some of these things.  Posting ideas here is only of modest assistance (most of the time such recommendations are already known but aren't handled yet because no one has had a chance, or because they're tricky).

Whoever was telling you this was mistaken.  This is an expected behavior during the initial block download currently. It will begin pulling again when there is a new block on the network.

Well… not quite. It's only linear for sane changes— though it does have quartic convergence even in crazy cases.

No no, it's an external device... so it does exohashing, of course.

Agreed.  I did my part: https://bitcointalk.org/index.php?topic=118464.0

Hi, this thread is created in response to the thread requesting 65 GH from the SC single.

Everyone knows that more is better, and since >9000 exahash is more than 65 GH (perhaps infinitely more) then it is clearly the best option.

I think BFL should begin making these alterations to accommodate these speed increases with all haste.

We need a breathalyzer function on the forum to govern posting access.    Can you please keep this garbage out of the technical forum?

Going down at the same time as pirate doesn't prove he was using pirate. He could have been using zeekrewards directly.

Uh oh: http://www.btcman.com/bbs/forum.php?mod=viewthread&tid=353&extra=page%3D1

I suspect you're bumping into the same reason their initial specs didn't match the delivered product: the power (and perhaps clock?) estimates out of these tools are wildly wrong because they don't account for the very high toggle rates.

Your numbers would have been more in line with what BFL originally claimed for the product but couldn't deliver.

Gibberish.

Depends on how you define "eventually".  If there exists a partitioning of miners such that the mean time between blocks is less than the communications and block processing latency for a block to propagate completely is less than the mean time between blocks then the bitcoin algorithm will take infinite time to converge in the average case.

In Bitcoin at current transaction levels we now see propagation times at several minutes sometimes. High orphan rates and lots or reorganizations also slow down convergence, so in practice you probably need to have a block time considerably greater than the latency bound or bad things start happening.

But hey, if you plan on reporting the many coin-generic bugs I'm sure you'll find then it's all good, and might be a fun exercise even if it's doomed to fail. Have fun!

Slush is both intelligent and thoughtful and cares about what happens with Bitcoin. I've never seen him do anything for a quick buck.  Your unkind words here are unjustified and just make you look foolish.

Yes, barring implementation bugs it behaves just like a normal node externally.

Wow. I'm really disappointed to see this misinformation still being promoted. It is completely untrue.  It's perfectly possible to solo mine and solve a block with your very first hash operation— just unlikely.   Assuming an idealized zero latency zero fee pool your expected return is the same either way.  With real pools its somewhat lower compared to a well maintained local node solo mining (although that may be something of a stretch, the reference client has some scalability / stability issues that make maintaining it harder than should be, but we're working on that).

Sequential trials of N months each isnt the right way to think about this. There are sequential trials— but they're happening billions of times a second, one for each hash operation.   A better mental model is to imagining forking off 2 million copies of the universe, a million solo mining, and a million pool mining. After any span of time the average of each of the groups would be the same (minnus pool fees and stales from latency to the pool, and differential maintenance quality in each), but the distribution would be different: in each of the pool universes you'd have a similar amount of coins, while in the solo universes some of you would have nothing, some would have the expected, some would have an enormous amount more than expected, but the over expected would match up with the under expected and the result is the expected average.

Or you you can think about it as choosing between two lotteries to play, one has a 1/1000 odds and pays out $0.98 (2% fee) for each win, and the other has a 1/1000000 odds and pays out $1000 for each win. Playing the lotteries cost the same, and you can play them thousands of times a day. Sometime in the future the relative odds will change but the payouts will stay matched. Which lottery do you prefer to play?     If not getting $.98 right away would make you die of dehydration then the pool is a clear win... otherwise it just depends on your relative risk tolerance and how you value your time. If the risk reduction and time savings doesn't justify the pools fees and hazard to bitcoin security (even if just theoretical: FUD hurts bitcoin too) for you then you should prefer to solo-mine.  (Or P2Pool!)

Difficulty changes don't make a bit of difference in this.  If you instead think about hash rate in terms of percentage of the total you can pretty much ignore the difficulty changes entirely.  

As a long time user of Bitcoin and a developer: Thank you for taking a firm position against making dust payouts. Blockchain bloat is no one's friend, and tiny outputs will likely never get spent— meaning they'll bloat the txout set perpetually.

I've seen fairly little evidence that the botnets are especially big factors (especially since many of the pools will block them when discovered), though they're something of a factor.

There are a great deal of other factors though.  Mining is— once established— passive income. As long as their GPU keeps spitting out coin many people are not in a rush to mess with what works.

There also has been (and continues) to be a widespread misunderstanding of mining: a lot of people fervently believe that mining is like a race: the fastest wins almost always, and they expect a non-linear increase in returns from being in the biggest pool.

Some of the larger pools have used tools like google adwords to promote themselves in the past too— with high fees that smaller pools an decenteralized services can't collect they can afford more marketing and polishing work.

This subject is a concern— but we're much better off now than where we were a year ago.  And the concerns are somewhat overstating the risk. Miners can and do switch pools pretty quickly (e.g. automatically), and more recently developed miners like BFGminer have checks which can automatically detect some kinds of pool treachery. "no one here or anywhere else can prove me that dozens of computers contributing more than 51% of network processing power is better", doesn't of pols is not the same as "dozens of computers contributing more than 51% of network processing power"