Currently trying Maged's idea of restoring a backup bitcoin folder. Less than 2 days behind, should be up to date soon and know whether I'm all sorted. Damn it! Ended up with the same 5 unconfirmed transactions! Why would that be if they never ended up on the network? 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...)
|
|
|
why don't you ask your angry customers to provide details on the transactions they did?
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.
|
|
|
Well, the easiest solution at this point would be to revert to a recent backup of your wallet (you have one, right?) and double-spend these coins by sending the entire contents of the wallet to another of your addresses.
If I do this will it mess up the 120 or so transactions I've done since the corrupted transactions? 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.
|
|
|
I'll celebrate the day when I can do the same. I tried dropping them in September and profits went to zero Instead of dropping them completely, have you tried offering a more competitive price for bitcoin purchases? http://www.bitcoinmoney.com/post/23551708288/discount-for-cashMaybe if customers see they have a financial advantage in using bitcoin, they'll at least be motivated to learn about it.
|
|
|
As a matter of course, MtGox should be providing victims such as yourself with the IP addresses, logs/timestamps etc of recent accesses to your account.
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 being arrested for simply swearing in public is fucking ridiculous.
Maybe??? https://www.youtube.com/watch?v=zwoqzb5R6vwThere are certain posters that consistently post garbage, but it's the price we may for free speech and non-censorship. And they don't ruin the overall experience.
+1 Plus, you may ignore these posters.
|
|
|
Than crypto not one time told that my wires has sent already but nothing i got! They lie me I have skype logs
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.
|
|
|
He had this hw-device... wonder what's become of it.
+1
|
|
|
A chart like this could be on bitcoin.org.
|
|
|
Sure, whats the problem with that? What prevents you today from making a contract that you will trade, say, a computer for bitcoins, gold or pidgin shit? If you want to call pidgin shit money because of that, be my guest. Then we already have competing currencies.
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.
|
|
|
If by money you mean legal tender, I dont fancy that idea either. If anything can be legal tender, someone may want to pay off his debt to you by paying in metric tons of pidgin shit and you would have to accept it as debt settlement if he delivers enough of it.
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 too sure about that, but wouldn't that kind of issue be helped by forwarding port 8333 (at router level)?
I'm not really willing to expose my IP like that. But anyway, I don't think it's a bandwidth issue.
|
|
|
have you tried 6.2? it downloaded all blocks for me in about 20/30 mins yesterday
Wow... that's the time my laptop takes to update like, a single week of blocks. And I'm using 6.2.
|
|
|
The slowdown between #100k and #120k is quite dramatic. I'm not (yet!) familiar enough with bitcoin internals to know if this is expected behaviour. Can anyone explain it?
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.
|
|
|
If you're going to communicate -publicly- with an exchange and air out your dirty laundry, give some details. Post your personal information, what happened, and back it up with evidence so that people can help you. Otherwise, be prepared to be told to shut up by everyone.
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.
|
|
|
Please speak proper English so we can understand what you are saying. I haven't heard you explain this before. All you mentioned was that the site had it's domain name for sale and was purchased some time ago. what do you mean you bought them from 3rd party? ....
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?
|
|
|
Thing is, many of these things were mitigated - quite a lot - with 0.6.2 version. It really shouldn't be taking so long.
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.
|
|
|
|