I'm sure we can have a great centralized stock exchange service. This doesn't obviate the need for a decentralized stock exchange.

The "one place" is an abstract concept. It doesn't need to be a single physical location, and it doesn't need to be provided by a single service. If there is a p2p network where I can place a bid and have someone on the other side of the globe accept it, then the entire world is the one place where people come to trade.

No. The distribution of round length is memoryless, so having a high share count does not make it any more likely that a block will be found. The result is that a properly implemented PPLNS pool is hopping-proof - the expected payout per share is always the same no matter when it is submitted.

I pledge 1 BTC per organization, until further notice.

But if I'm allowed to be a bit of a spoilsport, I think we need to be realistic with respect to the success prospects of this initiative. 100 BTC is not a lot for the organizations that matter, and Bitcoin comes with legal and publicity baggage that they will be mindful of. If they need any convincing at all to accept bitcoins, a mere 100 BTC will not be what convinces them.

It's even worse if the funds aren't collected in advance. When the time comes to pay up you don't know who will have forgotten about the whole thing, who doesn't get the memo, who has run out of coins and who simply refuses to honor their pledge. And the organization will be less eager to go along if they're not assured the money is all accounted for.

Maybe we can learn a few things from the DOSBox pledge which was sort of similar but on a much smaller scale. That was essentially a one-man crew with a hobby project and without any real legal obligation, and the persuasion process was far from "100 BTC you say? Of course I'll accept bitcoins now!".

As far as I understand, this only allows essentially OTC stock trading. But to be a stock exchange it should have some mechanism to commit people to their orders. If I broadcast an order and someone wants to take me up on it, I can just decline. I can be required to tie up my coins/shares for the trade but I can't be required to go forward with it. This IMO will lead to inefficiency and manipulation.

If what you mean is that the client will never switch to a different branch, even if longer, if it rejects a block which already has x confirmations, this will lead to situations where a node has checkpointed the wrong version and will never be convinced to switch to the true one. I'll call this approach (which isn't new, of course) "branch cementing".

My own ideas for synchronizable checkpoints - proof of stake via signature blocks - can be found here. In fact this can work in conjunction with block cementing, since a wrong cement will occasionally be overthrown by a signature block.

I think the question of what number to display is completely distinct from how to visualize it. For the number you can have (N/D-1) as it was before, or exp(-N/D) as it is now, or ln(N/D) as organ suggested. Each has its own pros and cons with respect to the message you want to deliver.

And then you can choose how each possibility should be visualized. If for example you feel that anything above 400% difficulty (which happens for 1.83% of blocks) is an Eternally Damned Cursed Block from Azazel, give it an icon and color to match.

Well, currently mining is subsidized by generation. But once that's over it's not at all obvious that the network hashrate (scaled to hardware advances) will be as high as it is now even if Bitcoin is successful, and the incentives of trillion-dollar entities to attack it become ever greater.

You can reject all blocks which do not belong to you, to make sure you get 100% of the block reward rather than your hashrate proportion.

You can reject all blocks which do not belong to you and not include any transactions in your own blocks, to prevent any transaction from being confirmed.

Identifying addresses involved in double spending isn't trivial, especially if you consider that future advanced transaction schemes could make use of legitimately superseding one transaction by another.

Even if you could detect them, I for one disagree with the idea to blacklist addresses. And my own disagreement is indicative of the fact that it will be very difficult, if at all possible, to obtain consensus to do this, and even if so, the client software isn't set up for this and a lot of work would be required to enable this feature. Also, for this to work the entire network needs to agree which addresses are blacklisted which is also difficult, so you're guaranteed to have chaos.

The main misunderstanding is to think that the only reason to carry out a hashrate attack is to profit from a double-spend. More likely a hashrate attack will be carried out by someone who wants to destroy Bitcoin, or at least to profit from short-selling bitcoins. Generally, mechanisms to protect against profitable double spending will amplify the chaos that ensues during such an attack, making us more vulnerable to a malicious attack.

Also, once this starts happening the bitcoin rate will probably drop, and depending on the attack miners will have their blocks rejected so it won't be profitable. Miners will quit and then it will be even easier to continue the hashrate attack. And since the difficulty targeting algorithm doesn't handle sudden drops in hashrate well we have a whole new set of problems.

This is a problem which hasn't been solved yet. It is probably solvable, and I've written occasionally on some pieces of what I think the solution will be. And I'm sure you could respond with some additional protection mechanisms. But these all have their own pros and cons, and need to be carefully considered, agreed upon and implemented. We need to prepare in advance for the contingency of a hashrate attack. Otherwise the chaos of the event could radically shake the faith in Bitcoin.

I don't think it's that important to know if it's above/below difficulty. "Luck" gives the connotation of making comparisons in the percentile space. Then average luck is 69.3% of the difficulty, which is the 50% percentile (median). Above 50% should be green, below should be red (currently it looks like the midpoint for colors is about 40%).

Anyway, I think it will look better if all numbers in the column will be in the format ##.##%, even if it has leading or trailing 0's.

Depends on what exactly you want to achieve with the luck factor display, but one obvious way to have a balanced view is to use percentiles. If the round length is N and the difficulty is D, then exp(-N/D) is the (opposite of the) percentile, which is uniformly distributed from 0% to 100% - higher is better and 50% is in some sense average luck (unlike the current luck factor which is green more often than red). Then you can color-code that, maybe even with a continuous gradation from red to green.

What happened to Vladimir's talk?

Exactly. Satoshi's original paper contains calculations for how many blocks the recipient has to wait to keep the chance of succeeding in double-spending at a given level (say 0.1%), as a function of the attacker's hashrate. At >50% hashrate the number of blocks if infinite - no matter how many blocks are waited, the attacker has 100% chance to eventually have the longer chain.

This attack isn't the only thing you can do with high hashrate, though.

You can do this with Bitcoin, see for example my suggestion here. You'll need OP_EVAL and the seller's agreement to make this kind of transaction.

I wasn't around back then, but didn't more than a year pass since announcing the Bitcoin project to starting mining?

This. With Bitcoin you always know that a payment has been made and there can't be a disagreement on this by the two parties. I once heard someone going on and on with a contractor about how he wired him funds, and the contractor claiming he never received them. And that same person (who, by the way, often complains about how sending funds internationally is expensive and troublesome) had been dismissive of Bitcoin when I talked with him about it. Go figure.

From the Taylor series of ln(1+x) You know that for x~0 you have ln(1+x)=x+O(x^2). So for large D you have 1/D ~ 0 and so ln(1-1/D) ~ -1/D and ln(U)/ln(1-1/D) ~ ln(U)/(-1/D) = -D*ln(U).

If you don't know the Taylor series of ln you can simply use the fact that the derivative of ln at 1 is 1. Or you could use exp(x) ~ 1+x and take logs of both sides.

Round length follows a geometric distribution starting at 1. So to generate a sample accurately, you should use 1+round(ln(U)/(ln(1-1/D))) (assuming "round" rounds down). For an approximation that works well for large D you can simply use round(-D*ln(U)).

It's a reference. But I won't spoil the fun by mentioning it explicitly.

The work is now complete, but not quite finished. I might still add new content as time permits, and there's a bounty for helping me improve it.

Thanks to everyone who have given me their support.

In an effort to improve the quality of my paper Analysis of Bitcoin Pooled Mining Reward Systems, I am offering rewards for people who submit errata. Every factual error reported will be rewarded with one hexadecimal Bitcoin (0.16777216 BTC). Every valuable suggestion is worth 0.01048576 BTC - comments on content, structure, prose, format, style, spelling, grammar and typography are all welcome. Reports can be given here, in the main thread about the paper, or in a PM.

Some additional rules are:

1. The decision what constitutes an error, a suggestion or neither is entirely my own. Generally, a necessary condition to be either is that it leads me to make a change to the paper.

2. I can discontinue or change this offer at any time.

3. Only the first time each particular report is given will be rewarded, and only if it is relevant as of the most recent version.

4. If you specify a receiving address, I'll send to it. If not, I'll send to your signature address. If you don't have one, or if you explicitly waived the bounty, I will not send it.

Remember, your contribution to making this work better is worth much more than the bounty. It is a token of my gratitude, not a replacement for it. Don't let the small amount or any other consideration discourage you.

Even funnier is when they put up names of Bitcoin core developers.

I have no idea what is "required", I can only speak of my experiences wiring to mtgox. Sometimes an intermediary was used, sometimes it wasn't. The fees for the intermediary were in the range $25-$33. For at least one of the transfers, I think the intermediary was "HSBC BANK USA NA GEN REM A/C HK NEW CASTLE".