Bitcoin block verification has very specific requirements which are probably impossible to achieve by using an external computing project of the type you mention. See also this StackExchange question.

The most important requirement is that the work is generated in a deterministic computational way from a piece of data, so that any change to the data would render the proof of work useless. Otherwise the work has no use whatsoever for verifying a block of transactions in a tamper-proof way. This is incompatible with most projects, which generate problems based on their real-world usefulness in an ad-hoc way.

It's interesting to note that if the external project is itself based on calculating hashes, there's some room for assisting it. That's basically what merged mining Namecoin is - using Bitcoin mining computations to help with an unrelated project. I expect that in the future Bitcoin mining will be merged with many other projects.

Larger problems than providing the world with a decentralized digital currency?

This is usually referred to as the "fundamental value". It is established by an intricate interplay between various market forces, but in brief it would be equal to the value each bitcoin needs to have in order to facilitate the level of commerce being done with Bitcoin. For example, let's say the majority of BTC use is in the cycle you mentioned. There are (made up numbers) 10,000 people buying $1000 worth of goods with BTC each month, and to reduce the hassle of buying BTC they buy that amount every month. So everyone will carry on average $500 worth of BTC, for a total of $5M for everyone. This means the total worth of all BTC must be $5M, and if there are 8M coins each one will be valued at $0.625. If the exchange rate dropped below that, people would need to buy more BTC to satisfy their shopping needs, and the added buying pressure would drive the price back to the equilibrium value.

The more people use Bitcoin, and the more goods and services offered for them, the more commerce done in BTC and hence the higher its fundamental value.

You are correct that currently the rate is mostly determined by speculative forces. Here too the dynamics are complex, but if 10,000 people are each willing to risk $5000 on their belief that the price will appreciate, there will need to be $50M worth of bitcoins, giving a rate of $6.25 per bitcoin.

The closer Bitcoin gets to fulfilling its potential, the more significant the fundamental portion will be of the total price.

Mining has a very low barrier of entry, so this is impossible - if there was that much profit to be had, more people would mine and the difficulty would adjust. The price of a bitcoin is necessarily very close to the total cost of mining, all things included - including the risk that any capital expenditure will greatly lose value due to future changes in the relevant parameters, and the limited availability of opportunities to mine at low electricity rate and efficient hardware.

Yes, when there are multiple lenders, a reserve is crucial for being able to allow withdrawals in a timely manner. I'm tempted to model this as a Poisson process, but the independence assumption is too strong for such analysis to be useful.

This is ridiculous. Of the 3 people who posted after me in that thread:
remmy (the op) understood what I said, up to some technical details.
iamzill probably didn't understand. His loss, my suggestion solves his suggested failure mode and I explicitly addressed it.
BitOffer presumably understood what I suggested, as he referenced it.

My "overly complicating the idea" was written in a way that makes it precise who gets what in which conditions. It was designed to solve the problems raised earlier in that thread - some of which you will probably only realize after some more chats with your IRL friend.

Armory, which is currently in pre-Alpha. Maybe others.

The reason I (and others) linked to past discussions is so that less time is spent reinventing the wheel. Take a look at this for example. Some more discussion occurred here.

It's tricky. There are some ways to do this properly but at this time they are either troublesome legally or too much of a hassle. What I can do is lock the rate when he informs me he sent the funds, even before I receive them, so he doesn't need to worry about future volatility if currently prices are stable (but only when I'm available, so he'll have to contact me about my availability).

That works, but of course the real solution is to use a client software which can handle multiple wallets conveniently, which I believe Armory does.

As was already explained, this link is for email notifications which are not what the question is about.

I should also mention that the main difference between PPLNS and DGM is that the variance is reduced by having the operator absorb some of it, which means he will gain money on short rounds and lose some on long rounds (which averages out to 0, before any pool fees). In EMC the absorption is very weak so you will likely not notice the effect, but in general this could contribute to a negative prop diff in short rounds (and to a positive diff in long rounds).

But again this can only explain about a 1% diff, the 193% you saw is due to good luck on your part in managing to find shares in that short time span.

This discussion is relevant.

Maybe http://bitcoinservice.co.uk/ is what you're looking for.

I'd need more data (and time) to give a definitive answer, but it looks like you're seeing variance in the number of shares you found. Let's say you have about 0.1% of the pool's total hashrate, so in a period of 2777 shares you'd expect to find 3 shares. DGM reward is influenced by your past work so will be comparable to that average. But if you were lucky and got 8 shares (which is definitely within the realm of possibility, chance for a Poisson variable with mean 3 to be at least 8 is 1.2%), your proportional reward will be much higher.

Maybe it's misleading, but it looks like it simply gives a percentage with DGM payout as the base, that is .14404033 - 193.52% * 0.04907340 = 0.04907340.

For a while now verification requires any documents to have a notarized translation if they do not already contain the necessary details in Latin script.

I don't think the new requirements apply retroactively.

Not sure if serious. Mtgox aren't doing this because they feel like spiting you. All exchanges have been through tons of shit with legal and banking issues. It stands to reason that Mtgox, dealing with volumes orders of magnitudes more than other exchanges, suffer from more fraud and are subject to more scrutiny than the others.

Another exchange may or may not succeed Mtgox, but they will suffer the same problems and will likely come up with similar solutions.

They don't internalise that risk. They make a one-time purchase of some BTC and keep it on the exchange (if the exchange offers selling on margin even that much isn't necessary). When they receive bitcoins on behalf of a merchant they sell the corresponding amount on the exchange immediately, and receive exactly the dollar amount they owe to the merchant. Then they can at their leisure transfer the bitcoins to the exchange to replenish their balance.

This way they don't suffer at all from daily fluctuations. They could suffer from long-term depreciation of their investment (again, only if they're holding BTC rather than selling on margin), but a business of this kind is likely to be long on BTC anyway.

The investment in BTC or collateral only needs to correspond to the total payment processed in the hour or so it takes to get bitcoins to the exchange, which is bearable.

This is all what I think they should do, I don't know how Bit-Pay specifically actually does it.

Going by the average rate is stupid. The merchant should always use the current rate, anything else is an invitation for dutch booking.

Please explain, this isn't clear at all.

That's not how it works.

I don't know about the OP but there are plenty of use cases. Personally I'd be more interested in an option to send from any address but a specified one.

Bit-Pay already offers instant conversion to USD, so merchants get the exact amount of USD they sold for (minus fees). Volatility for merchants is a solved problem, and it's important to make merchants aware that they can accept Bitcoin payments without ever owning a single bitcoin.