To be clear, I don't know for sure about the Polish bank - the transfer I was looking at was sent after he'd switched the details on the website to point to his personal bank in Germany.  So it's possible that until that point he was using a business account.  I don't know exactly when he made the switch, it sounds like it was only a few days ago.

The bank accounts are also in his personal name, not the business's, and I believe he is a German citizen, not a UK citizen.

He doesn't need to know how much money you think you had, or what your password is.  Realistically there's nothing you can do to help except be patient.

If I were he, I would:

1. Analyze the past transactions to work out how much has been lost to errors
2. Figure out how much is recoverable by fixing the broken trades, i.e. how much has not yet been withdrawn, and also decide whether this is ethical
3. Figure out how much is not recoverable, and whether the business has enough reserves to cover the losses
4. If not, figure out if he can prop it up somehow or whether he must declare bankruptcy
5. Overall, limit his business's exposure to lawsuits down the road, either people who disagree with the outcome of (2), or people who feel robbed due to the exchange's downtime and freezing of their BTC during a crash, or... etc, the richest people will find many reasons to sue
6. Plan how to restart the site without bugs or bad publicity

To me, that (2) is ethical or fair is not obvious.  It is a very difficult situation.  See (5).

Only hours later, after obtuse tweets about DDOS that seemed, in the end, to be inaccurate.

You mostly listed irrelevant rumours, and those that are true are mostly just artifacts of being a small business suddenly overrun with customers.  No, it's not a good way to run a business, but it's also neither fraud nor illegal in any form.

So what?  If that's personal then it's none of your concern.  If it's business then it's good, his business should be well set to make good any debts he owes as a result of the trading engine bugs.  From what I've seen all the errors are in the customer's favour, so so far the only loser is the site, and hopefully the profits cover those losses.

I've never seen my bank manager in chat, but I didn't send the police over when their website was down last summer.

Why should it be, did they officially publish it?  It's still not a crime.

And now ask yourself, how would you pull a really profitable scam?

Do you have a copy of the terms and conditions you agreed to?  Has he violated any?  I don't recall seeing any form of SLA or other uptime guarantee.  It's the nature of all these trading sites - they are unregulated, any money or coins you deposit are theirs to hold on your behalf, and although you may hope to be able to access them easily, in practice all these sites seem to have variable performance, especially for withdrawals.

A share is a proof that your mining software is working hard and working correctly.  It's the same thing as submitting a solved block to the bitcoin/litecoin network, but it's done with a lower difficulty setting.  This means your mining software can send frequent shares to the pool server, and the pool server can check they're valid and tell how hard and effective your miner is.  If any of your shares are actually strong enough that they do solve the block then the pool server passes them on to the network and usually collects the reward itself, then distributes it to the miners according to share levels, by various algorithms.

I find the dice metaphor really useful.  Imagine Max and Megan are rolling 100-sided dice, and Naomi will pay them $10 every time they roll a 1.  That's pretty boring, it could take a long - and variable - amount of time to get any money.  So Peter sits between them and Naomi, and offers to pay them $1 every time they roll a number 9 or lower - and if they roll a 1, he passes the die to Naomi and she pays Peter $10.  On average this almost balances out - Peter takes a slight cut, and also has to loan the money some of the time.  And it's more fun and practical for Max and Megan because they get "hits" more often, and they get paid more often, even if the payment is in smaller amounts.

In this scheme, Naomi is the bitcoin/litecoin Network, Peter is a Pool server, and Max and Megan are Miners.  Rolling dice is hashing blocks, the 1-rolls are solved blocks, and the 1-to-9-rolls are shares.  Sometimes the shares also count as completed blocks, but rarely.  Peter gets to choose the hit rate for his miners.  Maybe Paul is another pool server, with a different hit rate, payment scheme, fee, or membership.  The miners can choose which pool to use based on those criteria.

So to understand why hash rate may be high but share rate low, suppose Max buys some extra dice, and rolls three at a time - then he can win more often, as his hash rate is higher.  But if he tries to roll five dice at once, or if he rolls the dice too quickly, then some of them fall off the table and onto the floor.  In this case they don't count, so although he's rolling the dice really fast, he can't submit his shares to Peter - or, he submits them and then Peter says that they don't count.  This is analogous to tweaking your mining settings to values that appear to give a good hash rate, but in fact lead to a poor share rate.

It's also possible that it's best for him to roll 20 dice at once, and have 15 of them fall on the floor, rather than roll just three dice and be sure they're all valid - because at the end of the day, even though he wasted a lot of dice, he still got a higher share rate overall.  It comes at the expense of the hassle of rolling more dice, of owning more dice, and the wear and tear on the dice.

I know that's a bit of a tangent but I think this metaphor is very useful for intuitively understanding the mining and pooling processes.

Try --thread-concurrency 3072 -g 9 -I 13 --gpu-powertune 20, and possibly --worksize 256
Edit: terrible advice - although it reports a higher hash rate, it just generates garbage (never gets a share).

Do try using the --powertune option though, and possibly --thread-concurrency 8192 -g 5 or thereabouts - which does seem to give me a slight edge over large concurrencies and -g 1.

How many shares did you submit, and how many were accepted?

suprnova.cc as a whole has had a hard time finding blocks for the past few days (down to about 20% of the block rate it used to get), and this will translate to reduced returns for the miners.  However, it looks like this was just bad luck - the share rate is normal, there's no indication that the pool's overall hash rate has dropped or anything like that.  There were recent DOS attacks, but these seemed to mostly affect the web site front end, not the pool servers.  Still, I have seen a lot of failed RPC requests, which means your miners have to sit idle while the RPC retries, and that will take its toll.

I'm not sure where you got your 4.5 LTC/day prediction from - it sounds a little high, I'd say if you're truly achieving 800 kH/s then you should expect around 4 LTC/day at the current difficulty level (205ish).

I would give it more time though, and see if the pool's block hit rate improves, and especially pay attention to your shares and whether they're being accepted.

Because it's been called that for years.

Litecoin difficulty rose 30% this morning, so that could be somewhat related to the pool's drop in share rate.

Is your mining software claiming shares which are then rejected, or is it just not finding any shares?

I've noticed my mining fluctuates between finding a lot of shares, and finding no shares, at the moment, and the pool's website is often inaccessible (though the RPC requests seem to get through, on different addresses).  I wondered whether it's DOS-related.

Read the line saying "local rate" - your hash rate sucks - and so you're only predicted to get about one share every 5 days.  You can either live with that, or improve your hardware.  What are you mining with?

The product is very good, and I think it's awesome that you're embracing bitcoin in connection with such a fine product.

Is this essentially just a donation model then, so the game will be free on the Apple Store and Google Play, but invite people to donate?  I can't see how you could do it as a normal pay-before-play or pay-to-unlock store, given how those services operate, but maybe that wasn't your intention anyway.

Note that asking people to tell you which address they donated into your account from is weak - anybody can look up the records of who has donated into the account, and claim to be responsible for one of the addresses.  If you care enough to only give the beta to people who have donated, then you need a stronger way to check you're giving it to the right people.

I also think there's enough of a barrier to entry into the bitcoin market that you'd only get these donations from people who are already using bitcoins - you need to be aware of that from the start.

Why do you think a rise in difficulty will lead to a rise in price?  I think if anything it's the other way around, and even that is tenuous.

Difficulty is calibrated against block rate, so on average we get a steady block rate and a steady 1200 LTC per hour in mining rewards regardless of other factors.  If price goes up then there's an increased short-term incentive to mine and more miners will participate, leading to an accelerated block rate, then an increased difficulty level, which in the longer term leads to lower revenue per miner, probably balancing out at roughly the same real-world level as before the price increase.

But I'm not sure the converse is true - a rise in difficulty indicates prior increased mining activity, and acts directly to balance it out, but I don't see why that would affect the trading value of the coins.  If the difficulty rise wasn't due to a price rise as above, then miners would find it less profitable in real-world terms and may get out of the game, leading to a difficulty reduction.  If anything, the price of the coins would drop though, if the quitting miners sold their coins.

The miners claim the reward themselves, but if they claim it wrong, the network will reject their block.  So in a sense it's the network as a whole that decides whether the miner has claimed the right reward.

The strength of the bitcoin network is having a larger number of nodes all running software which agrees on the rules of how the system works.  Changing the rules involves convincing as large a portion as possible of the network to agree to the changes, which makes the rules stable.

When you receive bitcoins into your private wallet, you ask the wallet to generate a private key and associated "address", and then you can transfer as much or as little as you like into that address.  Or generate multiple addresses and split things up.  It is up to you, regardless of the amount being stored.

Note that you never "receive" a private key - they should never be sent over the network, they are secret.

Maybe I was exaggerating, I guess it's not completely insignificant and it will become much more so in a few years' time, but it was clearly of no interest to the miner of that six-transaction block.  Maybe that was a particularly unusual case though.  You're right that even empty blocks do improve security by building on top of existing blocks, but it would be even better if it also dealt with some of the backlog that must have built up during that period.

For pooled miners, which receive transactions pre-hashed from a remote server, there seem to be distinct disadvantages to frequently breaking off work and asking the pool server for an update, especially with all the DDOS attacks against pools recently.

Litecoin is on block 328351 (http://explorer.litecoin.net/) and is still issuing 50 LTC per block, so the number in circulation is 16417550.

The total that will ever be produced is a little over 80 million.

I think the reason miners are not taking advantage of ways to increase transaction fees is that the transaction fees are miniscule compared to the block subsidies at the moment.  It will be more relevant in future, or would be now if more people voluntarily pay very high transaction fees.  But I don't think that's a good position to be in.

This is all as-far-as-I-know, please correct me if I'm wrong.  But -

The thing that bothers me in the longer term is that miners have absolutely no incentive to include a zero-fee transaction in the block, whether it's so-called "high priority" or not.  Even in the short term, because the subsidy outweighs the transaction fees by a significant margin, you might as well just never include any transactions in your blocks.  Not healthy for the network!  I noticed a block the other day which was the first one for about half an hour, and it only included six transactions.  That is not useful miner behaviour.

Is it not possible to offset the proof-of-work requirement by some metric involving number of transactions in the block and/or volume of transactions, so that miners have an incentive to do useful mining instead of just hoarding the subsidy?  Or is that too open to abuse?

It's easy to turn off the warning, but kind of pointless.

coblee has announced work beginning on pulling changes from bitcoind 0.8.1, so presumably this will go away soon of its own accord.

They tend to come back after a few hours.

It's instructive to actually have a look at a block in blockexplorer - here is the most recent one, as of writing:

http://blockexplorer.com/block/0000000000000224615e7dc4006fcc1baec60b7cc3fa102332575ef53d2b8be0

Note the list of transactions embedded in the block, and that the first transaction has no "from" address, this is the miner receiving the block generation subsidy plus the total value of transaction fees for all the other transactions in the table.  For the other transactions, for any with fees you should find that the sum of the outputs, plus the fee, is equal to the sum of the inputs.  That is where the money comes from, and if it didn't add up the transaction would have been rejected as malformed way before being included in a block.

Two problems:

1) You're trying to redefine kilo-, mega-, giga-, tera-, etc to mean values less than 1 - we already have prefixes for that (milli-, micro-, etc)
2) You're trying to define them as powers of 100 rather than 1000 - we also have prefixes for some of those and could build others more consistently (e.g. centi-, decimilli-, micro-)

I think it's OK to use the base-100 system for convenience, with familiar terms such as "cent" or "bitcent", but we should reserve the SI prefixes for their usual meanings, and use those alongside as necessary.  Also given that nobody knows how much bitcoins will be worth next month, don't get too attached to binding terminology to current fiat currency values (so don't try to call 0.01BTC a "bollar" or a "bit-dollar" or whatever, it will just be wrong again sometime in the future).

For colloquial, non-SI usage, most currencies end up using new words that are completely different to each other, as "penny" is to "pound", or "dime", "nickel", "dollar", or "farthing", "shilling", "crown", etc.