Perhaps so - but unfortunately I don't reside in Australia so it's not really something I am going to really be able to pursue (especially over a sum of $50).

It is certainly a worry though when money just "disappears" and such events do not inspire confidence in using banks in order to purchase BTC.


Cheers,

Ian.

I had started using WBX to buy Bitcoin but got caught up with their bank account being "frozen" near the end of November 2011.

I received an email from my own bank today telling me that ANZ (which was their bank) has stated that it will not return my money (not sure if that means the bank just decided to keep all the funds from the frozen account?).

With the very real chance of seeing your money just disappear like this I would be very wary to use any exchange that won't *guarantee* to return your funds in case of their issues with their banks.


Cheers,

Ian.

I lost AUD $50 due to their account being "frozen" by ANZ - although I've been assured the money will be returned I am still waiting to get my money back or even for a reply from the bank (after 2 months).

Great - I think that means my wallet encryption approach is safe then (as I never run the client to do more than a small number of transactions at a time).

Hi all,

Just wondering exactly when the standard client will generate new keys in your wallet. Will it do so only exactly when the last key in the key pool has been used or will it do it before that?

The reason for the question (and depending upon the answer the reason perhaps for a change request) is that I keep my wallet encrypted using external software which via a script I use to run the client decrypts and after the client finishes executing automatically re-encrypts the wallet (I am not using the Bitcoin wallet encryption).

My concern is that if the new keys are only generated when the pool is totally exhausted then if something terrible happens to my computer whilst the wallet is being re-encrypted then I could potentially lose BTC that was received via a newly generated key (this would not be a problem if new keys were generated whilst a number of "old keys" are still available to be used first).


Cheers,

Ian.

Very interesting tools and something I am very interested to use with my own future open source project.

Just a couple of questions:

1) Any possibility of optionally using MySQL?

2) Will these tools work in Windows also?


Cheers,

Ian.

Ouch - that's not good.


In bash the ~ is short for the "home" folder so for example if I do ls ~/*.txt on my Linux box it would be identical to ls /home/ian/*.txt.

So I'd expect there to be a .bitcoin directory below the home directory of the user that you used to install Bitcoin (if I used "ian" then on my machine then the full path would be /home/ian/.bitcoin/wallet.dat).

I tend to agree with legolouman that things are not looking good with this wallet file (i.e. I seriously doubt it will work by just moving the file to Linux).


Cheers,

Ian.

Well I guess if you are going to use separate addresses per customer (or maybe per sale item) then this could indeed become a problem.

I was thinking more of the "home user" but in order to work well with either type of user (if a simpler wallet persistence mechanism were to be entertained) then a configuration option would need to be added.

As for Amazon accepting Bitcoin - I wouldn't hold my breath. 


Cheers,

Ian.

I just read the following advice on another similar thread:

1. Make sure you have a backup of the wallet.dat
2. delete all files except wallet.dat from the APPDATA\bitcoin directory (not using windows, but I think you should be able to find it)
3. start bitcoin-qt.exe then wait for the block chain to download..a few hours if I recall correctly

Apparently this worked for the other user with a similar problem to yours so maybe give this a go (be sure to backup everything you are going to delete just in case).


Cheers,

Ian.

Hi all,

After following a couple of recent problems on this forum that people are having trying to recover corrupted encrypted wallets that seemingly got this way due to Bitcoin being shutdown unexpectedly (although not whilst actually generating keys) has made me wonder why the wallet is being stored in the DB?

Is it because the wallet size is expected to be potentially be too big to buffer in RAM?

Is it because it needs to be written to at some other time apart from when issuing a new transaction?

Why not just store it in a text file (plain/encoded) which is read/written in its entirety when the need arises and kept closed at all other times.


Cheers,

Ian.

I gather that Berkeley DB is included with many (most?) Linux distros so from a console I can type the command: db_recover

If you are not running Linux then you may be able to find the relevant utility here: http://www.oracle.com/technetwork/database/berkeleydb/downloads/index-082944.html

You need to make sure it is the correct version (I think I had read something about Bitcoin changing to Berkeley DB 4.8 a while back).

I assume then you would simply open a command prompt and change to the Bitcoin app data path and type "db_recover" (with whatever path prefix might be needed).

Once again I have never used Berkeley DB nor played with any of the Bitcoin source so advice from anyone that has more relevant experience should be better trusted than my own.


Cheers,

Ian.

Oops - my bad - should have been "%ProgramFiles%\Bitcoin\bitcoin.exe -debug" (i.e. with quotes).

In any case if you are also seeing:

EXCEPTION: 22DbRunRecoveryException       
DbEnv::open: DB_RUNRECOVERY: Fatal error, run database recovery

then I guess the debug.log is not really of that much help as I assume that is just saying it can't open a DB because it thinks it is corrupt.

I am guessing there is probably some sort of DB recovery tools out there (a quick search found me http://pybsddb.sourceforge.net/ref/transapp/recovery.html) but I've never played around with Berkeley DB myself and so am not sure exactly whether it would help or not. If the problem was just that file closure didn't occur correctly then I'd assume such a recovery tool should be able to fix things up but if the problem was more serious then it will probably do nothing to help at all.

In any case make sure you've kept a copy of all original files before playing with any such tools!


Cheers,

Ian.

If you click on Start -> Run and then type: %ProgramFiles%\Bitcoin\bitcoin.exe -debug

then this should do the job.

The file "debug.log" should appear in the same folder as your wallet (assuming you are using the normal folder for that).


Cheers,

Ian.

I think it may be problematic running the older version (as the Berkley DB version changed sometime recently).

Have you tried starting up your 0.5 version with the "-debug" option?

You might be able to find out more detail about what the problem is (the file "debug.log" hopefully would contain something useful after the crash occurs).


Cheers,

Ian.

Understand - seems that the conversion from unencrypted to encrypted is something one needs to pay very close attention to (on my system my wallet is kept encrypted by an external encryption tool and is only unencrypted when I run the client which I only do for a brief time per day and every day after running I take a backup of the encrypted wallet and keep several such backups at several different places).

It will all depend upon exactly what has gone wrong with the encrypted wallet - not sure if the debug.log file will provide any clue as to what exactly it is finding wrong with the file.


Cheers,

Ian.

Hi,


I would be a little cautious about giving out your "wallet.dat" file to anyone you don't know or whose reputation on this forum (or elsewhere) is not well known.

It might be time to read up a bit on wallet recovery steps - one first thing to note is that if you have even a fairly old wallet backup it might well have the private key(s) required to recover your BTC as a key pool of usually 100 are created when your wallet is created (the rescan option might be required if starting the client up with an older backup).

Also whatever you do make sure you keep a copy of the current wallet.dat (if you do end up still deciding to give it to someone else).


Cheers,

Ian.

Speed came good - will be trying the $5 AUD deposit soon.

This is good news and hopefully will start to get the trading volume up.

The "How It Works" text still only mentions the charge as $15 so you might want to fix that up and also currently (around 5pm AEDT Dec. 28th) the site is running extremely slow.


Cheers,

Ian.

The other standard approach for a Linux app would be to use the "getpass" function if the password option (i.e.g walletpassphrase) has been provided but without any value (although this will require changing the source).

A rough idea is as follows:

if( has_option( "walletpassphrase" ) && option_string( "walletpassphrase" ).empty( ) )
   password = getpass( "Enter password: " );

If coded this way then the password would never appear in history or even need to be seen visibly on the terminal screen (you need to roll your own function using _getch to achieve the same thing in Windoze).


Cheers,

Ian Knowles.

Interesting - I live in Beijing (have done for 5 years now) and the price of a taxi to/from the international airport (one of the bigger taxi drives you are likely to take here) has only gone up by around 15% in that time (from around 60 RMB to 70 RMB going from the airport to the CBD area).

That being said it is correct that the price of food (and pork especially) has increased a lot and wages haven't kept up as much but I haven't noticed any significant drop in the popularity of people going out to eat "Yuxiangrousi" (the most popular pork dish) here. Perhaps people are just buying less new (or "real" brand) clothes instead.


Cheers,

Ian.