My wallet finally got in sync after a few rescan and reindex attempts. I still have transactions though from 2013 that show up with 2017 timestap....
Balance looks OK so I'll leave this here.

It shouldn't be the case. Exactly for this reason I tried running the wallet under Linux as well, without luck.
I might now try to run put the datatbase to a NAS instead of the local drive, but I don't see how the drive could be the issue.

Ok, so after downloading the blockchain and re-indexing a few times, I'm still stuck. The outputs below are after that I have reinstalled bitcoin core.


On a clean wallet:

In addition, during syncing my wallet shows transactions with the wrong date. Transactions from 2013 show up as they were in 15/10/2017, which is definitely wrong (aka at 60% blockchain I seetransactions with 2017 datestamp). Re-indexing does not help this.
The drive is healthy, plenty of space and the error occurs regardless if I use Windows or Linux. (According to various scans, no bad sector, is present. The drive is ~6 monnths old, so statistically it should be the smallest "issue factor")
I have even went so far as to completely uninstall bitcoin core, create a fresh wallet and start downloading the blockchain. If I put back my own wallet, I get the error and the messed-up datestamps for transactions. If I let the fresh wallet, it also gives the error (as above).

I would also recommend https://bitcoin.org/en/alert/2017-10-09-segwit2x-safety in addition to what has been posted by -ck.

It has some info on which exchanges / pools will support the hard fork.

In the meanwhile I already started re-downloading the blockchain. The question was more like if this is a one-off issue. Frankly, it's a bit of a pain to download the whole thing again after a wallet upgrade.

Thanks.

Hi,

when I upgraded to bitcoin core 15.0.1 suddenly I got an error saying my database was corrupted. The client prompted for permission rebuilding the blockchain and started syncing.
Since then it keeps crashing with an error


If I restart, it syncs another few weeks of database, but crashes again.

Is there anyone getting a similar issue?

I keep restarting and will see if I manage to catch up eventually, I was just wondering if this is a one-off issue.

Hello,

I am joining to the others and am fairly confident that btcrecover can help you. If you indeed have an idea of what the password might be then you want a token file. This is nicely explained on https://github.com/gurnec/btcrecover/blob/master/TUTORIAL.md#the-token-file.

If, however, you do not want to go the route as mentioned by HCP and give a part of your wallet file to anyone to have a go at it, then you have to do it on your own.

I would approach it in the following way
Step 1.
Write down everything about the password on a sheet of paper. For example: contained full words, any special characters, where could these be roughly, did it start or end with a special character/phrase or word. Also quite important, how long was the password? The exact length is ideal, otherwise you have to do more iterations and more preparation in step 3. If you know the password had the word "cat" in it, but was 30 characters long, well...good luck. If you combined 2-3-4 "standrad passwords" that you use, but don't remember exactly the order or if anything was capitalized, maybe a few special symbols, then your chances are vastly improved.
Step 2.
Create a copy of your wallet file and work with that. Always keep a copy somewhere safe.
Step 3.
Head over to the tutorial linked above and see what you need. Since it is well explained there and I have no information on your password, I cannot help you with anything specific, but you definitely want to look at a "token file".
Btcrecover can mix and match whole words that you know for sure appear in the password; even if you don't know if you capitalized it or it was at the end of beginning.
The remainder of the password where you have no info has to be filled out with wildcards. A clever use of these, e.g. if you know that it was all lower case or all numerical, can also greatly imporve your chances.
You have to spend most of your time on this part where you have to cleverly assemble the input parameters to tell the software what to do later. With well-defined parameters you can be relaxed that running btcrecover for x minutes/hours/days was not a waste of time and you will get something at the end.
Step 4.
Start crunching with btcrecover. This is also well explained in the guide and again without knowing anything about your password and possible hardware, not much can be helped.
If you have indeed "an idea of what the password might be" and fairly decent hardware for number crucnhing, your chances are good.

Good luck!

First of all, Thank you!


I understand, you mean the transaction was made before the computer crash (that had a return address unknown to the January backup) and the restored backup doesn't recognize the address, hence marks it as outgoing.
(Any new keys generated in the keypool after the January backup are obviously lost.)

I interpreted the post such that the transaction was made with the wallet restored  from the January backup . In this case (if the wallet has caught up with the ledger far enough to determine that all the old 100 keys have been used) the wallet would generate new addresses, right?

More of a question here for learning purposes


I am not getting how the return could go to an address about which your wallet does not know. I only see 2 options:

A: If the client knows that all keys in the old keypool have been used up (sync is recent enough), it will simply re-generate new private-public keys. This happens if you unlock the wallet to make a transaction. Hence return should go to a newly (at the time of transaction) generated address.

B: If the client does not know that all keys have been used up (sync not completed up to the point where the last address has been used), then it will send the return coins to an old address in the old keypool (say 99/100), which has already been used before (!), but for which you also ought to have the private key in the old wallet.dat. In this case the return address would have 2 transactions in it.

Please correct me if this is wrong, after all, I am here to learn.

Based on this and the transaction ID, the 13 BTC change was the only input to the return address, so I would say it is a new address generated when you sent the transaction. (Had 13 BTC been sent to a return address that was used sometime after your January backup (I do not see how that would be possible), that address would likely have another transaction in it as well. Being also old, it is quite probably that it was already used.)

BitcoinNewsBR
1. The transaction in the UI does look like if it was sent to an unknown address(mentioned by shorena), as generally return addresses are not shown in the UI. Are you perhaps using an extension/script to show these as well?
2. I think a "Private key for address X is unknown" also appears when you try to dumpprivkey with the wallet locked. I assume this is not the case.
3. Have you tried to sign a message with the return address? I saw this recommended somewhere as to double-check if you don't have the private key for an address.
4. If you haven't already, you could look at the commands listaddressgroupings and listreceivedbyaddress, they might tell you some additional info.

The markets react simply. If one sees that the value of a commodity has dropped somewhere by X%, he/she might want to sell on a different exchange as well to follow the global trend.

Nevertheless, in general I see a 20$ lower price on BTC-e compared to e.g. Bitstamp at pretty much all times. Trends are usually the same, that is true, however, I think it is just the reaction of the global market.

You can check out Firefall at firefallthegame.com. Its pretty fun to play.

I don't know if this has been posted here, but this is definitely worth a read: http://oil-price.net/

It gives pretty nice explanations for oil prices and if you read, you can get an idea about what is going to happen. If every country including now Iran continues to produce oil at the current rate, or perhaps increase to make up for smaller profit margin, I am expecting a very slow "recovery" of the prices.

I find it funny, that people wanted to push fracking out of the market by bringing the oil prices down. Now that the technology has been developed, its profitable at much lower margins and the tables have turned.

Solar panels are tested against storms, snow, hail and similar. So unless you are talking about a tornado, they should be fine outside.


If you check the video again you will see that the whole setup is connected to the mains as well, hence if the battery runs low, it automatically switches to draw power from the grid. So even though the Sun may only provide x hours of operation, the miner will not stop suddenly. For a proof of concept project this is perfectly acceptable, it is cheaper than sizing up the whole system just to run a few more hours.

Hi, due to some schedule issues I was inactive in the past few weeks. Could you please add me back?

Cheers.

Well, I cannot and would not move around that kind of sums on a regular basis. Too much pressure.

Well, not big of a trading, not sure how you would like it, but you can have a go and look at cryptostocks.com

https://blockchain.info/address/1NkmZc8vVzFVYrvCA2g4qhJssUX8S8B4TB shows that the coins are in the wallet.
Have you tried restarting Electum? It is weird that it doesn't show up.Can you see your address in the wallet? Is it synced? Are there any other(previous) transactions being shown?

Nice experiment man! Don't forget to write down the results you get for yourself and for public knowledge as well 

Specifications usually mention 0 deg C as a minimum, because equipment is not tested below that, but this doesn't mean it won't work. Maybe you can even give feedback to the manufacturer saying that you tested it for X time and worked / did not work.

As for your cables, others said as well, look into them. Burned cables are no good. Also, 4A/mm2 can be taken as the rough measure on how much current you can push through a copper cable. Don't go above it when operating continuously.

I understand the issue with chargebacks and everyone's fear of scams. Yet this thread simply exists for promoting a site that will pay me with PayPal for my coins. So, it is possible (from the site's perspective). The only question is, why would I trust the site then?

I was referring to this specific site.


Yes, I am trading directly with an exchange provider. So how come they are happy taking my coins for PP but I can not use PP to buy their coins? Guess if I want to buy BTC with PP I will also have to make my own exchange service and offer an option "sell your BTC to my for PP".