The backup you used was done after the 5 bogus transactions. For that to work, you'd need to find a backup which was done before the bogus transactions, but which happens to contains all your private keys. Seeing the number of transactions you make, that might be difficult. 
You'll probably have to resort to manually deleting the transactions...


To the devs: isn't this a bug in the Satoshi client? Shouldn't the client try to rebroadcast unconfirmed transactions once in a while? If it does rebroadcast, just not fast enough for Jeremy's needs, then isn't this an enhancement issue that should be logged anyway? (allowing the user to configure the rebroadcasting periods, and/or adding a command line switch (perhaps even GUI) to manually force the rebroadcast...)

Or is there something peculiar with those transactions that make them be refused by everyone every time they are sent? I'm ruling out voluntary double-spends. (if it's an involuntary one, it's possibly an even more serious issue...)

I thought these transactions were initiated by Jeremy's wallet...
If they are incoming transactions then the problem is not with him, but with those trying to send the money.

If the backup contains all the private keys, a rescan should be enough for it to see transactions that were confirmed. It will see them in the chain.
What's important is that the backup contain all private keys, but not all transactions.
Keep a copy of your current wallet before doing this, of course.

Instead of dropping them completely, have you tried offering a more competitive price for bitcoin purchases?
http://www.bitcoinmoney.com/post/23551708288/discount-for-cash

Maybe if customers see they have a financial advantage in using bitcoin, they'll at least be motivated to learn about it.

Plus, they should allow users to set limit to themselves.
Like a preferences page where I set maximum withdraw amounts per day and per week to myself. If I want to change these preferences by increasing the amounts, the change will only take effect like 48 hours later. And every change in these preferences are notified by e-mail, as every withdraw of any amount.

This way losses can be limited in cases such as this.

Maybe???

https://www.youtube.com/watch?v=zwoqzb5R6vw


+1
Plus, you may ignore these posters.

If I understood this piece correctly, you're claiming that you have skype logs in which CryptoXChange says that your wires are on the way, while they are not.
If that's true, it would be shameful to CryptoXChange - even if WME is indeed a scammer, there's no reason for CryptoXChange to lie.
I find it more likely that you just didn't understand their English correctly. Check again. Somebody who doesn't consider 100K USD an amazing amount shouldn't have troubles finding a good English speaker to help. (and that includes helping with your writings here)


Now, WME, if what you say is true and you legitimately own this money, you should already be doing what Mathew said above: sue CryptoXChange. Demand them the money, plus indemnities for the time loss and other problems you might have had due to this. It should be easy to win such lawsuit if your claim is legit.
But you have to go to court, not to bitcointalk.org. Not only people here cannot help you, as they have strong reasons not to trust you.

+1

A chart like this could be on bitcoin.org.

No, we don't. If in the debt contract it is written that only bitcoins are accepted as payment, that clause is legally void: the debtor may still pay with legal tender if so he wishes.
And US legal tender laws are less authoritarian than many others, if that's the only thing they force. In many countries, if you're selling anything, it must be against the official currency. In Brazil for instance, not only you cannot refuse the official currency if you're selling something, but you're also forced to provide change to the buyer if he throws a large denomination bill at you. Not to mention all banking rules.

Sometimes it seems authoritarian people just don't want to think for a few seconds...
How about specifying the means of payment in the contract? Didn't cross your mind?

Thanks Pieter Wuille for the clarification.

I'm not really willing to expose my IP like that. But anyway, I don't think it's a bandwidth issue.

Wow... that's the time my laptop takes to update like, a single week of blocks. And I'm using 6.2.

I can't explain it, but I suspect that the whole process is done in a synchronous way. Like:

• Download a block (bandwidth usage)
• Verify its validity (CPU intensive, plus indexed queries)
• Insert the block in the DB - indexation (IO intensive, and probably O(log) on the index size, or perhaps even O(n), don't know)
• Proceed to next block

If that's the case, there's probably room for some optimization by rendering this process asynchronous and making bulk inserts in the DB. A thread would go downloading blocks, in a torrent fashion. Another thread would go behind it verifying the blocks. And finally a third thread would insert the verified data in bulks on the database. Validated blocks should be kept in a memory index while they are not yet inserted, so that the verifying thread can query them too.

Well, this is all speculation of mine... can someone confirm how is the block download done?

I tend to agree with both of you.

I also have a strong impression that WME is the one to blame here, simply because I don't think CryptoXChange would risk their reputation by "playing police".  The amount also makes it suspicious.
But, honestly, don't you think the burden of prove belongs to CryptoXChange in this case? WME has already said they are denying the withdraw, while he has already submitted the necessary docs - according to his words.

Perhaps the docs were an obvious forgery, perhaps CryptoXChange has strong evidence that WME is a thief, or perhaps they even have a court order restraining them from releasing the money.
But, by the innocence presumption principle, I'd say the burden of proof is on the exchange, not on the guy with his account frozen...

Anyway... these forums aren't a court either. CryptoXChange doesn't have an obligation to justify his actions here. It just might improve their already good reputation if they did, I believe.

What I can understand from this topic is:

• WME deposited a large sum of coins in CryptoXChange, sold them and tried to cash out the amount in USD (~100k according to him)
• CryptoXChange froze his account and is denying withdraw, apparently, according to WME words, because those coins were stolen. I suspect CryptoXChange suspects WME is a thief.

Could WME and CryptoXChange confirm or deny my interpretation above?

Not for me...
When I start my 0.6.2 client after a single day off, the time to synchronize is considerable. The disk works frenetically.

I suspect indexation time is the issue here... does anyone know how the blockchain index is structured? If it is just a sorted disk array for example, inserting anything would be linear on the amount of data already there.
Plus, I believe it would help to do bulk inserts, asynchronously, if that's not done already. This would allow the download+verification to continue while indexation is processing a previous bulk. I have the impression that the whole process is synchronous (download a block, verify it, insert in BD, download next block, verify it, insert and so on...). If that's the case, it could be optimized. Not saying it's easy, but it's possible.

It's not the download itself that takes time. It's processing and indexing the downloaded raw data.

IMHO it's IO time the great bottleneck concerning blockchain update. At least my laptop disk makes a lot of noise.