Thanks, that's all I needed to know.

Didn't intend to. I only want to know how much I received in each address, so that I know whoever was supposed to pay me did. Whatever crazy things the client does later to rearrange my funds is not interesting.

Bump, because it happened again. This address has recently received 2.47330177, and my client says it received 7.38126662 - which is actually the sum of what I received to several addresses in the same block, possibly from the same source (they are all Continuum pool rewards).

What is the best place to report such things?

I completely agree! But practically speaking, experience shows you can get more with a mediocre service and good marketing than with a good service and mediocre marketing. People should indeed strive to offer the best possible service, but they would do well not to neglect an honest, respectful yet effective marketing if they do not wish their great service to remain unused. (It's the "respectful" part that some of the referral spammers don't get...)

Come on, we're not that different you and I. The main thing that prompted my objection is that my affiliation with Tradehill is actually a step up from being a mere referral whore. So referring to them has some qualities of linking to my own services, leaving me confused if I am allowed to do one but not the other.

PS. I actually also have my own service, which I do not yet link to in my signature for strategic reasons.

That would be me, going well so far.

If they average 30min per block then they average 48 per day.
The standard deviation is 6.9, So taking a 1 sd range, the blocks in 24h can easily be anywhere from 41 to 55.
Which is 85% to 115% of the average.
Pools differ by a few percentage so this is definitely not enough to make any kind of comparison.

This accusation is outrageous and I resent it.
I don't have a pool. I did play a part in the creation of Continuum Pool (devising a scoring method and helping in its implementation) and I currently mine for it, so I'm not completely without bias.
But to accuse me of lying is appalling. Everything I say is 100% honest. And I happen to be one of the few people in this community with the skills to analyze such matters, if you choose not to listen to my advice it's your loss.

@TheManOfTown - I may be interested in participating in such a forum.

I disagree about the "no referral link" rule though.

And I'll take this opportunity to say that one of the problems of this forum is people not bothering to read the documentation and posting criticisms of Bitcoin that are trivially debunked. This is exhausting after a while.

No. It's actually pathetic. It should do about 6 MHash/s, I have a computer which can do 1400 MHash/s.

No.

In any case it's not enough to have a GPU, you need to actually use it. The Bitcoin client software doesn't, you need a mining software like kiv's GUI mining.

Without a pool, you have 0.1% chance to get 50 BTC.
With a pool, you have 100% chance to get 0.05 BTC.
(Actual numbers depend on your hashrate and time spent mining)

No, the score-based system has nothing to do with it. Possibly there's a bug with the pool but you'll have to discuss this with slush.

Avoid proportional pools like the plague, with the advent of Multipool you will receive much less from them.

You can't find out anything in 24h, it's too short and the variance is too high.

There are very few fair pools. slush is good enough, but if you want 100% hopping-proof go for Continuum pool.

1. You may be interested in this.

2. You need to be in a pool for weeks or months to be able to empirically determine its profitability.

3. The most profitable pool is probably Multipool, if you're ok with joining the dark side. Otherwise I recommend either slush or Continuum.

Transaction fees don't eat anything up. They're paid to the miners who then do with them whatever they want.

It doesn't need to be confirmed to be visible in the client. As Eri explained, the OP needs to download the block chain.

Oh, we have that. -testnet . Makes mining so much easier .

AFAIK mtgox didn't offer international wire withdrawals at all. You'd have to use Dwolla or LR or other such US-specific nonsense I'd never heard of before starting with Bitcoin.

MagicalTux.

I think the current half-life is about 550 shares. So if 5000 shares were submitted after yours your payout will be close to 0.

Think of this as a gentler version of solo mining. You don't have a good chance of being rewarded for blocks found while you were out, but your variance is much lower than solo when you're in (and on average it's the same whatever you do, and all that).

Probably never going to happen.

Difficulty depends on the number of miners. If miners leave, difficulty will decrease until mining is profitable again.

This is an idea I've been thinking about for a while. In fact one of the things that drew me to Bitcoin is that it provides an answer to some of what my idea tries to solve.

The plan is for a peer-to-peer banking system. Like traditional banks, it will allow you to make a deposit of any currency - be it government-issued, Bitcoin, or a future alternative cryptocurrency - and have the ability to transfer it to beneficiaries of your choice. Unlike traditional banking, you are not locked in to a single provider (whom you must trust with your entire fortune) and the barrier of entry to aspiring banks will be very low.

I can argue that even in a world dominated by cryptocurrencies, this system can have advantages - for example, instantaneous confirmations of large transactions. But speaking practically, government-issued currencies will exist for the foreseeable future and there will be a need for a good way to handle them.

This is only a very rough sketch of the plan, I can't hope to figure out all the details myself. I also cannot know for sure if this idea is novel, or if it was discussed before, or if it is so trivial it was never worth a mention.

The plan

Every user of the system will have a cryptographic identity (maybe more than one) for digital signatures and encryption, and be a node in the p2p network. There will also be many bank nodes (anyone can start one easily, it's basically just announcing to the network that you'd like to be a bank). Each bank node will hold locally a balance for each identity he's interacted with.

Every user will have a "trust value" associated with every bank, representing the maximum amount he is willing to deposit in it. Ideally there will be an algorithmic way to determine trust values based on the bank's history, not only with this user but also with other trustworthy users (a trust propagation reminiscent of Google PageRank) - but I can't yet think of a good way to do it and it's not strictly necessary. Instead the user will input manually how much he trusts several banks based on external information.

When Alice wants to send money to Bob, they need to negotiate (this is done automatically by the software) to find a bank node, Trent, to handle the transfer. In the simplest case this is a bank which Bob trusts with the amount and with which Alice has the amount in the balance. Bob sends Alice some identifier to recognize the transaction. Alice sends Trent a request to credit Bob and have the identifier part of the transaction. Trent moves funds from Alice's balance to Bob's, and sends Bob a confirmation of the transfer (he can also give Alice a copy).

In a more general case, Trent doesn't have to be trusted by both Alice and Bob. Rather, a strong enough path of trust must exist from both Alice and Bob to Trent. So there must be a path A -> X1 -> X2 -> ... -> Xk -> T <- Ym <- ... <- Y2 <- Y1 <- B, where an arrow means trusting with the required amount (and we assume that on the path from A to T, each node has the required balance with the next node). A informs X1 she would like to transfer money to B; X1 debits A's balance and takes on the assignment of delivering the money to B. This is done by requesting the transfer from X2, and so on; eventually T is trusted with delivering to B. This is done by crediting Ym's balance (which he trusts T to do) and requesting that he sends to B, and so on. Eventually B receives a payment confirmation containing the code he originally sent A, so he knows she paid.

Even more generally, there needn't be a single chain to handle the entire amount; if A's funds are distributed between several banks, or if not enough trust exists in a single chain, the payment can be done in several pieces accross several trust chains.

Sharing trust information to find this arrangement of chains will be the hardest part in the protocol. But if enough trust exists in the network an arrangement should be possible, and the mechanics of finding it should be doable.

Every bank node will charge a competitive fee for his services, and the negotiation will also include finding the flow with the least fees.

Depositing funds from the outside world into this system isn't too hard if we assume there is some bank that, while we don't trust to guard our savings for any length of time, we do trust to properly handle a sizable deposit without running away with the money. A deposit will be done in such a bank, with instructions on how to distribute it between other banks; It will use its trust relationships as well as bulk transfers to credit the required banks, and send the user confirmations.

Enabled technology: Distributed Bitcoin exchange

And now we get to the interesting part, why now of all times I decided to write this up. With the recent mtgox woes, there have been calls for the need of a distributed Bitcoin exchange. The reaction has generally been that this is impossible. I claim that with a distributed banking system in place, a distributed exchange can be built on top of it.

Alice wants to place a market order, say for buying BTC for USD. She informs Trent, a bank with which she has the USD balance needed for it, of her intentions. Trent freezes the amount and broadcasts the order. Thus the data on all pending orders is publicly available, and can be visually displayed by the client software or 3rd party services (like blockexplorer is to Bitcoin). Bob, who wants to execute Alice's order, finds a path of trust to Trent, and through it transfers BTC to Trent (each node in the path guarantees to the previous one that he will receive a refund if things go wrong). Trent credits Alice with the BTC, debits the USD, and sends the USD back to Bob.

And, incidentally, it needn't be a Bitcoin exchange. It can exchange any two currencies, making global currency exchange more competitive.

Can't you use several account per pool, from different IPs (using some proxy service)? And can you try to do the hopping more gentle, at the cost of some efficiency but becoming less conspicuous?

An average 6 blocks per hour is only when the network hashing capacity is at an equilibrium. If it is in a rapid upward trend it will be faster.

You could argue that it should have had a more sophisticated control algorithm that will approach the target average over time, but long term it doesn't matter much.

Depends only on storage space and can easily be a billion.

Bitcoin is volatile now because there is so much uncertainty about it, and probably because of lack of financial instruments relating to it. As it becomes more established it will be much less volatile.