It is not possible to create hundreds of thousands of coins out of thin air in a 51% attack. They can mine from a point further back from the main chain and when they surpass the main chain a reorganization occurs which would result in their chain being the main one. The coins they legitimately mined are then real and those that are on the losing chain lose theirs. It's not really 'out of thin air' though. They genuinely mined them.

This is probably what you meant but it's good to be specific otherwise people spread FUD about what can happen in 51% attacks on other coins.

EDIT: I guess they could double spend which is a form of creating coins out of thin air. Spending them once, rolling back, then spending them again. Is that what happened?

Correct, transaction fees are currently used to build the pool reserves.

I'm not sure what this is referring to.

Thanks. Any chance of getting the rest of the information I asked for? It would be most useful.

Given that there are miners mining with 100+ GH/s I don't think that's true. Again, what miner are you using. Do you have backup pools configured. Can you paste, PM or email the command line and/or configuration file you use for the pool. There's obviously something wrong with either your setup or the pool's setup such that it doesn't like something your mining software is doing and it'd be good to work out what it is.

No, that shouldn't be the delay. It would help to track down what's happening if you can email admin@bitparking.com with:

1) Your pool username
2) What miner your are using
3) Have you got any backup pools configured
4) Logs of a mining session that include lost shares. Something about 30 minutes long should cater for the delay.

The more detailed the logs the better but anything that includes submitted/rejected/accepted is helpful. If you could also let me know the timezone of the logs so I can match up with what's in the database that'd help.

Thanks!

You have not. You have not answered the questions I asked to track down the problem. Your response to my questions was "Seriously...". That's not being civil. If you really want to resolve the issue then to help find out the issue, please provide the information I asked for:


In particular, with regards to logs, if you can provide protocol dumps (cgminer uses "-P") that would be most useful.

There is a number of delays between a share being submitted and stats being shown on the stats page. The page itself is cached by the webserver for a number of seconds to reduce load. This means it is always behind. When you submit a share the share the result of that submit (rejected, accepted) goes into a queue. That share is submitted to the database when the queue is processed. This can take some time depending on pool load, database activities, etc. Once it's processed from the queue the web server can report it. This has been the apparent discrepancy in the times that others have reported issues.

Ok, thanks. I misunderstood what it was about from the website.

I'm curious why you don't just use namecoin?

Block numbers are available here. Block 242,435 is the one referred to.

I get quite a few emails and requests for support, it's helpful if you answer questions in a civil tone with the information requested so we can move towards a solution. If you're not willing to do this I suggest you mine elsewhere.

It's a lot easier to maintain a fork if you include all the history of the previous coin it was forked from. Without this it's difficult to merge or cherry-pick fixes that are later applied to the original coin. It also makes it hard for auditors to compare your fork vs the original coin to see if any malware or secuity issues were added. To do this now they would have to basically analyse the entire code base from the beginning. If you don't want to provide the entire history of the previous coin then providing the git repository and commit id it was based on is useful.

This most recent orphan was caused by a bitcoind issue that an emergency patch was supplied for. The issue caused the bitcoin daemon that the pool daemon was hidden behind to crash due to OOM and the pool daemon no longer received updates. It's unfortunate but not much could be done about bitcoind bugs.

The pool was a block behind the mainnet at the time the block was found and it was immediately orphaned on restart of bitcoind when it caught up on mainnet. The  reason the pool lost connection with mainnet is due to a bitcoind issue that I've now patched and applied in the last restart. I'll write more about that when I can. I've left the block as pending to investigate further tomorrow (it's 3:30am here). This is the orphan data btw - block 242435:  

Had to do a quick bitcoind update to fix pool issues over the last couple of hours. You'll have seen a few restarts during that time.

I'm working through all the mails I've had. Some haven't had responses, this is because I haven't reached your account yet or there is some difficulty recovering your data. The best way you can facilitate your processing is to provide all the information at http://exchange.bitparking.com:
If you haven't provided all that, your processing will be slower. If you deposited multiple times to a single address your processing will be significantly slower due to the nature of the recover (I think this is your issue but you haven't provided me with the above to tell - you did read the deposit page about deposit addresses working once only, right?). If you deposited, withdrew or traded during the crash period your processing will be much slower as well. If you have a significant namecoin or bitcoin balance it will also be delayed to confirm the data. Recovery is unfortunately slow and time consuming. I'm doing the best I can. If you have not had a response in the past month you can email/Bitmessage again providing as much information as you can. There was data loss in the namecoin wallet and in the trade database and I'm trying to recover the data which has caused even more delays. I haven't posted progress because whenever I do I get even more enquiries/complaints about progress and I'd rather just work through processing the accounts as a I can. I thank those that have provided positive comments during this process and reported when refunds have happened but I apologise to those still waiting. I don't in general post here or reply to PM's because it just leads to more questions and queries. Emails or Bitmessages are the best approach. Even if I don't respond immediately you'll be put in the queue for processing. Although it is no excuse, this exchange was a hobby project for me to provide namecoin users with a means to get namecoins and the large pump/dump on the day of the crash has made it very difficult to piece trades together. I'm trying my best and working through the queue. Hopefully the responses here where funds have been refunded at least give some idea that this is happening.

You're a bit hard to deal with...things would go faster if you'd just provide the necessary information, especially since you're asking for something outside of what the pool normally does. Your latest email still doesn't include an account name. I need a simple email from you asking for what you want including the account name so I have an audit trail. Thanks. Instead of complaining about it, how about just doing it, so this can be resolved.

Sorry, I don't normally respond to PM's and your email probably got buried in your previous ones complaining about PPS vs DGM. The order in which I deal with email and bitmessage is usually:

1. People using the pool needing support
2. People I'm processing funds recovery requests for the closed exchange
3. Everyone else.

You're number 3 as you're asking for something that is already covered by pool instructions - the minimum withdrawal fee can be worked around by mining. I need to manage this order otherwise I get drowned in requests by people for "just this one time" to do things like you are asking.

Note that I'm not 'refusing to pay'. The pool states there is a minimum payout. By mining you are agreeing to this and you need to mine to reach that minimum to withdraw. The minimum payout of the pool is 0.05 to reduce the cost in fees from a fragmented pool wallet. You know this of course because you've asked me to manually transfer a balance before.

At some point in the future I plan to implement automatic withdrawals where small amounts like yours can be processed with zero fees and picked up by the pool when it solves a block. Unfortunately until that time any request for a manual withdrawal depends on my free time.

If you have sent an email, I'll process it in due time and can do the manual withdraw then. In the meantime you can either:

1) Wait for it to be actioned
2) Wait for automatic payments to be enabled
3) Mine until you reach 0.05.

Edit: I looked in my email pending queue and see an email from a G Lukacs on June 3 requesting a fund withdrawal but they didn't include an account name. If that's you can you do a followup including that information, thanks.

This is the first I've heard of this. Are you on getwork or stratum?

'unknown-work' means work is being submitted to the pool that it didn't serve. What mining software are you using? Do you have backup pools configured with it? Do you have any logs you can provide to look into it?

Fantastic! Thanks for letting me know.