As I pointed out upthread there are many reasons to LP other than a new prev. LP does not mean that the pool _will_ reject work from before the LP. It might... it might not. It probably will _soon_ but that isn't a reason to stall.

Even in the case of a new prev,  I don't know what the pools do— but on my solo mining if I get a solution from my miners I reorganize and try to extend that, even if it comes late.   I'll only switch to mining an externally headed chain when its at least one longer.

(This provides the highest expected return:  If you _do_ find a solution you'll get two blocks and probably win even though you were late to the game.  If you don't find a solution before the network gets further then it doesn't matter).

Though we're really debating the angles dancing on the head of a pin.  Even if you stall for a half second every single LP, with LP per block you're only talking about losing 0.08% hashpower / energy at most.

"Dr! Dr! It hurts when I do _this_."
"Then don't do that!"

Don't trow out work until you have replacement work.

Maintain a priority queue, work against 'new' blocks is highest priority.... If there isn't any of that, take what you have.  As has been mentioned, new prev is not the only reason for new work to be issued.

Negative, Ghost Rider.

Merged mining adds a _single hash_ to the coinbase transaction and that single hash binds an infinite amount of whatever completely external stuff the miner wants.  This is not the same as people shoving unbounded amounts of crap in the blockchain.   Go look at the blockchain— bitcoin miners have been adding various garbage in the same location for a long time now.

Meanwhile any user, not just miners, could and have been adding crap to the blockchain already.  Where was your bleeding heart when people added several megabytes of transactions to the blockchain in order to 'register' a bunch of firstbits 'names'? 

Even if you don't buy all the arguments I gave about how merged mining is seriously beneficial to the long term stability and security of bitcoin, you should at least realizes that the mechanism channels a bunch of different bad uses into a least harmful form.

And really— asking for the feature to be removed? Thats— kinda nuts.  Anyone running a pool is already carrying a patched bitcoind for various reasons so it wouldn't stop them. Its already a problem that pool operators are slow to upgrade bitcoin.  Making them carry patches for this just means more they would have to port forward and more reason for them to stay on old bitcoin code.

The data clearly does not support your claim. Hell, we have basically half our hash power on a pool without (disclosed) merged mining.

For merged mining? It's not something new... https://bitcointalk.org/index.php?topic=7219.msg105915#msg105915

As far as "goes off in different directions in their own development" you've described the situation with pools already. They can't use a single unified solution for merged mining because they don't use a single solution for their pool.  Most of the pool operators keep their software private— presumably as a competitive advantage.

So— We shouldn't have pools with stats?  We shouldn't have pools with different payout systems (e.g. hopping resistant ones)?  We shouldn't have pools that can pay users directly out of the coinbase?   We shouldn't have distributed pools?  We shouldn't have ntime rolling? We shouldn't have miners with pool redundancy?

Every one of these software features carries risk in fact, I'm aware of examples where an implementation of every single one of these has had bugs and caused outages for their users.   Importantly— in all of these cases only the people benefiting from the changes suffered from them, and the same is true of merged mining.

For a while I've been mining solo, quite enjoyably and profitably— but I switched back to mining on eligius for the time being because Luke had merged mining working and I didn't want to dork around with it (and that python proxy looked like crap to me).  I considered the costs of MM for me and decided on a course of action that made sense for me. You should do that too.

Before I respond to it I think it's important to emphasize that there is _NOTHING_ fundamental about the problem here.  Regardless of merged mining the bitcoin daemon needs to be able to tell workers that they need to move on to new work— this arises without prev changing due to merged mining, sure,  but it is just as equally an issue if a new txn with high fees hits the memory pool, a pool server is simply restarted, or a network failure switches remote miners to another datacenter.

Many people misunderstand merged mining— they think things like it means automatically switching between systems, or that it lowers the work useful work miners do on bitcoin. This is not true (save any software bugs that crop up while adding the feature— but you can say this about _ANY_ feature).

Now, as far as the goodness of MM goes— forget about the profitability of it, it's not why MM is important.   Merged mining is a major improvement in the fundamental trustworthyness of Bitcoin:

Prior to merged mining,  adopters of bitcoin took the risk that IF bitcoin lost popularity (or, even didn't lose popularity but mining became less attractive due to energy costs, declining rewards, etc)  THEN bitcoin would NECESSARILY become insecure— and vulnerable to reversal attacks.

With the existence of merged mining bitcoin being popular or profitable-to-mine is still sufficient for security but it is no longer strictly necessary:  Bitcoin is secure so long as the sum of ALL distributed systems which use the nakamoto block chain distributed consensus and share work with bitcoin, some of which may have no "coins" at all,  are popular enough to provide enough mining hash power for security.

For example of a very different application: P2Ppool now uses merged mining to achieve consensus about the distribution of payouts for the distributed pool.

Merged mining is also very good for bitcoin because it reduces the incentive for various parasitic behaviors.  For example, some people have wanted to cram random data into the block-chain for proving time of creation.  This is bad for all bitcoin users because our system fundamental depends on flooding and near global awareness— bitcoin is the least efficient data storage system used by man (short of our own genome).   Merged mining would allow these parasitic loads to exist in separate chains.  (Importantly, the _only_ cost to bitcoin for merged mining is a single hash in the coinbase, and whatever software bugs miners suffer while implementing it, and MM has O(1) scaling— with one additional hash in the coinbase we can support an infinite number of merged chains)

Also, In cases where a system using the same computing resources becomes as interesting as bitcoin mining you risk hash power oscillation unless you have merged mining. At one point we had a good few hundred GH/s bouncing between NMC and Bitcoin every difficulty change.  Because bitcoin was still growing hashpower quickly at this point it wasn't a terrible problem (well it was pretty devastating on namecoin, and only wasn't on bitcoin because bitcoin miners were fortunately slow to respond to the extreme profitability of namecoin). But if the swing had instead been twice as high or happened when we had declining hash power we would have been seeing very noticeable cycles of slow blocks.

It's also the case that you're wrong to ignore profitability. Because the profitability of mining contributes to the attractiveness of adding lots of hash power legitimately which provides bitcoin's security (as opposed to the profitability of using hash power to attack).  If you make legit mining more profitable you make bitcoin more secure.

Finally, even in cases where you can argue that MM is bad (perhaps the various scam-coins) you can't actually prevent merged mining. The current system works cooperatively with the binding in the coinbase txn, but you could always bind other hashchains by stuffing the binding hash in a parasitic transaction.

So, I think it's clear that merged mining is technology which is good for bitcoin even if the specific usage with NMC is boring and the software is having growing pains.

I am reloading this thread like a crazed weasel.  I'm quite eager to see what kind of results you get from the manual placement.

You can do the RS code over the digits directly. It's so much nicer if the base is a 2^n however.   E.g. if we were using a base 64 the implementation of the encoder (/checker) would be just a few lines of code and a table.

(sorry for the OT tangent)

5830s overclocked (and carefully clock managed, but not overvoltaged, 324MH/s) bought in bulk, 6x to a board, slowest cpu, network booting, a lot of careful tweaking. All other parts cut to a minimum. GPUs screwed to a wooden frame many linear feet long spaced as wide as possible. Ribbons ordered from hong-kong and shipped on the slow boat. I'm also fairly power efficient for a gpu setup— you can gain a fair bit by careful psu selection and running at 240v.  (and good power quality is important for stability at high clock rates)

Total cost per node are 109*6 (gpus) + 210 (mb) + 4*6 (ribbons) + 60 (cpu/ram)  + 100 (power) + 8 (marginal price of a ethernet switch port) = $1056 plus some modest shipping costs and a negligible amount of wood and screws.  yields 1944 MH/s.  Er. That a bit better than I said, though its a bit closer once you throw in some for shipping.


Its hard to say. There are a lot of gpu miners... and once the cards are a couple generations old I expect an influx of used cards (especially a lot of lemon used cards that have been driven hard and not well cooled as many miners are guilty of) will undermine the used market price. It's hard to guess by how much.  These ATI GPUs are only so vastly superior to the alternatives for a few apps.. a lot of gamers would rather have nvidia.

If you want to build a DES cracker however, then that FPGA will be a pretty smoking solution.  I expect the FPGA vendors could probably improve their sales by offering tools for other applications, just to increase customer confidence that the FPGAs are useful for things other than mining.  DES reversing and WPA cracking are obvious things that come to mind. ... lack of fast IO limits SDR applications, lack of memory and fast IO limits imaging applications, these are best for crypto.

People should run their own numbers in any case— your $/MH on the GPU farm is higher than my actuals by about 25% but people build with different degrees of efficiency.

You're certainly making the point that FPGAs are now in the realm of competitive for new deployments, even for buildouts with fairly short term planning horizons. Ztex's modules are also attractive because they've clearly been designed in a manner which would facilitate re-purposing them for things other than mining, which is a reason they should retain some value even if future SASIC (or even ASIC) devices are more efficient for mining.

OTOH, the density of one S6-LX150 per board is kinda poor, as I assume these are losing a fair amount to commons and PCB costs— (the bare FPGAs are about $190 each IIRC).  Sort of a tossup, the single chip boards are more reusable but it's still kinda pricy even with the quantity discounts.

Sorry, — you don't need my permission. I apologize if I was too heavy handed and made it seem that I was suggesting otherwise.  I'll try to confine any further comments I make to the thread to the assumption that a change would be made, and simply to questions about the best/worst ways to change it.

I'm interested in knowing what you expect to happen to cause the hash rate to fall faster than the current adjustment can keep up with it which won't in itself present material problems which dwarf transactions being slow while the difficulty catches up?

The only things I can think of that would cause massive super-fast hash-rate losses — things like major governments outlawing mining without warning— are both highly unlikely and devastatingly terribly completely independent of the difficulty calculation.

I would have previously bought a theory that if the exchange rate fell to the point where many GPU miners were unprofitable over electrical cost that hash rate would plummet, but this appears to be disproven by the evidence— it seems that there is enough mixture of energy costs (e.g. people with higher costs that shut off first), people whos energy usage is offset by being able to use the surplus heat, people with FPGAs and free power (partial or total energy cost insensitivity), and people with faith that bitcoin will gain value in the future that downward changes caused by exchange vs energy cost are fairly slow in practice.  It's gone down, of course, but not so quickly that its problematic.

In the meantime,  alt-chains with modified difficulty algorithms have been exploited thoroughly by attackers who used overpowering attacks which were assisted by the difficulty being too easily ramped.

So perhaps this was just the wrong time to have this debate: At the moment I don't think the evidence for changing the difficulty has ever been weaker and I don't think the evidence against it has ever been stronger.

I gave a concrete example with figures for a proposed change to a windowed system which wasn't even faster than the current one (making it faster just exacerbates the issue further)....  Which is a lot more specific than people waving their arms speculating "I could picture a situation or two" with respect to enormous hash rate falloffs.

And yes, I do think it's easier to fix a problem after the fact when you don't actually understand the potential problem concretely before the fact, and when there are a great many possible specific problems which may require different solutions— and when the solution carries real practical costs plus non-trivial theoretical security harms _AND_ must have pretty much complete and universal consensus.

Sure, security issues exist otherwise. But it's not like any difficulty adjustment change you could propose would completely solve all difficulty adjustment issues. If you take every security reduction which is just a change in magnitude but not kind, eventually you have no security at all.

Just an edit to make this clear:

Here are two examples that require drastically different difficulty handling solutions (of course there are many other possibilities than these): There is an energy crisis and electrical power jumps to the equivalent of $10/kwh everywhere  vs  another blockchain cryptocurrency becomes as popular as bitcoin and roughtly as profitable to mine.   To the first a one time step in difficulty reduction is the proper tool, not a faster syncup in general though faster might be sufficient. A single step is better than a faster change because it would address the need without harming security in the future.   To the second case merged mining with the new cryptocurrency would be the rational change: Making the difficulty algorithm faster would only cause deeper highly disruptive oscillations as hash power moved between chains.

Then so what?  So transactions take longer to confirm. If we really lost more than half our hash power overnight then we'd probably have bigger concerns than somewhat slower txn processing for a couple of weeks.

The slow introduction of FPGA miners also makes sudden losses less likely, because their costs are even more frontloaded than the GPUs which make up most of our hash power now (and which appear to have significant hysteresis).


As I pointed out upthread, there is a real tradeoff vs security here. Some minor improvement against some hypothetical case isn't obviously a win vs a change in security exposure.   Making the change also requires a complete blockchain forking flag day event which would itself create non-trivial security risks (old clients ending up on a dead chain fork but believing txn on it).

The change you want would be far more clearly defined and far more easily implemented in the presence of an actual problem. E.g. if blocks were actually taking 6 hours it would be a lot easier to convince everyone to upgrade at once, and a lot easier to know exactly what change would be needed to address the actual situation at hand.

The xilinx timing and power analysis stuff is a bit crazy at times. If you're making the mistake of believing it that might be part of your lower hash rates.

The ideal setup for mining is not zero errors... if you can get 10% more speed but only lose 1% of the shares due to corruption then you're still 9% ahead. And false positives are trivially swept up by the supervising cpu.  Ideally you'd want to do some self-testing in order to auto calibrate the clock rate on each unit to get the highest yield possible from each chip.

Otherwise, you might just try making a bunch of inconsequential changes in order to perturb the routing and get better timing out of it.  These mining engines seriously tax the interconnect occupancy, so small differences may make big timing differences

.

Obviously you need to change your pool name to AAABitcoin. 

But really, moving hash power from the biggest to the second or third biggest doesn't improve the over consolidation of hash power much.   50% isn't this magical point where it's all terrible where 49% is just fine.  (since with a simple majority you'd have to hold it for a long time to pull of any interesting attacks).

I know you were kidding, but some people around here don't have a sense of humor. Promoting some of the small but not tiny is the simple, rational thing to do and doesn't require any kickbacks.

Luke made it online and got it back up— unfortunately he's suffered a laptop failure while on his trip.

I'll instrument the code I'm running to check.   One thing that might help is just increasing the number of front ends you're running, even on the same systems.

I haven't hacked on pushpool for a while, but when I last did it had a lot of blocking IO.... so a few slow sockets could really bog down its response time.  I actually have no clue what you're running but if has a similar design you might get better throughput just by running more processes.  (You could load balance with some OS level rounding-robbining  of the sockets or just by giving users more ports to connect to)

I'm seeing the same issue with cgminer on fast systems— watching the traffic I'm seeing the pool take several seconds to respond to getwork requests and the miner runs dry.   I _assume_ this is hurting my hashrate as you're reporting 1.80GH/s against a system which does 1940.6 MH/s day in and out, though maybe I've just had bad timing.   I do see the 0.2% stale rate, which is nice enough.

Cgminer systems can have a lot of hash rate behind a single connection, and they avoid queuing much work to avoid stales... so it's important to keep them saturated.

I didn't bother reconnecting to check the headers, do you have nrolltime enabled?