I think you'll find the argument should be -daemon rather than -deamon (although am not certain that this is the cause of your problem).


For further information about the DB error you'll need to check the "debug.log" file.

You just need to start bitcoin-qt - it will automatically create a new wallet and start downloading the block chain (note that the latter step can take a very long time depending upon your internet connection and hardware).

While you are waiting for the block chain download you might want to start trying to work out your wallet "pass phrase" as this needs to be something very long (and best to be mixed with alpha-numeric and other symbols) and something you *cannot* forget (or your wallet becomes "read only").

Actually this was what originally confused me (I had no idea that I could pay *without* having a Walletbit account) so am glad you have changed that and made it more obvious that you can pay with a normal wallet (not wanting to hurt your business but we are all in the Bitcoin business after all).

I can confirm this (the only issue I've had in the last 10+ years was plugging in a friend's USB flash drive to find it was infected which luckily my AV software detected before anything bad actually happened).

That being said it is certainly not as easy to protect a Windows install vs. a Linux one.

Assuming the collision of HASH(t1) and HASH(t2) is performed with MD5 and

[t1 - in hex]
d131dd02c5e6eec4693d9a0698aff95c2fcab58712467eab4004583eb8fb7f89
55ad340609f4b30283e488832571415a085125e8f7cdc99fd91dbdf280373c5b
d8823e3156348f5bae6dacd436c919c6dd53e2b487da03fd02396306d248cda0
e99f33420f577ee8ce54b67080a80d1ec69821bcb6a8839396f9652b6ff72a70

[t2 - in hex]
d131dd02c5e6eec4693d9a0698aff95c2fcab50712467eab4004583eb8fb7f89
55ad340609f4b30283e4888325f1415a085125e8f7cdc99fd91dbd7280373c5b
d8823e3156348f5bae6dacd436c919c6dd53e23487da03fd02396306d248cda0
e99f33420f577ee8ce54b67080280d1ec69821bcb6a8839396f965ab6ff72a70

then the collision hash is: 8bcec679bc54a3634116e859d16c32d4

but if instead of HASH(HASH(t1)) we do HASH(HASH(t1)+t1) (where the + means append) then we get:

HASH(HASH(t1)+t1) = 3d4d97fb6f2b9638a4b881e7db1aefaf and
HASH(HASH(t2)+t2) = 78849bd73dda9f9c1a946d06766d08f2

So maybe one possibility down the track would be to change the double hashing technique?

From the source:

Thanks for that.

Well best of luck with this model - I'll even gift you the extra amount I sent in order to be able to send the amount that I had wanted to send in the first place (I can look after my own bitcoins so won't be using this service again).

I used Walletbit in order to purchase a VPS and was very unimpressed by the following:

1) I deposit the "exact" btc amount for my bill but you guys took a "fee" from it (you really think you can charge buyers?).

2) What is the point of the silly password type thingy (why not just paste in a btc address?).

I will not be using this website again and could not recommend it to any buyer at all sorry.

I think that this is indeed something necessary - in playing with Walletbit in order to purchase a VPS I was hit with a "hidden" fee that meant that the exact amount I'd sent for the payment was (upon arrival at their website) no longer enough (with no warning at all) requiring me to then muck around sending another tx just to cover their "hidden" fee.

This kind of experience will turn 99.99% of the "general public" off ever using Bitcoin at all (regardless of the "real cost").

The fees are minimal - so the seller should pay them!

I didn't notice the option to pay without Walletbit (perhaps some minor UI change might make this more obvious) - but thanks for letting me know that this is possible (I am assuming I can pay directly when my next bill is due then).

Sorry - 2pm - in which timezone (I am in China and it's 10:25pm here now)?

Okay - finally got the payment through but now according to the Due Invoices list it is still unpaid - is this something that will fix itself up soon?

[edit] that did fix itself up - just waiting for the actual service to come online now...

And it gets worse.

I have the 1.27 BTC required but when I put in the Secure Card code (another annoying part of Walletbit which I am now beginning to really dislike) I get the following:

Amount is larger than your available balance

(according to Walletbit my balance for the payment address is: 1.27570450)

So what is this - another fee I have to pay Walletbit in order to pay you guys - or do I have to wait for x confirmations first (I am hoping the latter)?

(if it is the former rather than the latter then how about you just send me a btc address and I send you the btc directly minus the fees from Walletbit that you guys have just cost me)

Am trying this out now but was a little miffed to find that because you are using Walletbit I have to pay some sort of fee to them (it is quite a minimal fee but is not a nice experience to have a payment processor charge the buyer rather than the seller).

I think it can be made rock solid but only if the computer you run it on is never again connected to the internet (or any network or other computer just in case it was in any way compromised).

Another poster mentioned about creating QR codes which would make it convenient to transfer the encrypted private keys with an "air gap" (so there is no need to even use a USB to transfer the encrypted private keys for backup purposes).

Perhaps you missed that.

I really like the QR code idea a lot - am not sure if most GPG public keys are small enough to fit into a QR code but if so then I think that the combination of vanitygen and GPG could provide an extremely secure (and indeed "air gapped") method to generate wallet addresses.

Thanks for the neat bash script (I figured the program I whipped up shouldn't be needed for Linux but having worked for so many years under a standard Windows environment I have become accustomed to writing small programs to do such things).

I assume to do the 2-factor implementation you would assign a variable to the output of the first gpg call and then feed the password plus this into the second call?

Using a standard encryption phrase is absolutely no better than using none (just as you can very easily log in to non-secured routers by using "standard" passwords like "admin" or "master").

The problem with the pass phrase is that it needs to have enough entropy to be useful (so something easily remembered will be of little use) but if it is forgotten then the user loses all their bitcoin.

As a user will start with zero bitcoins (and then perhaps get some very small amounts from faucets or the like) there is really no need to pressure the user into trying to come up with a strong pass phrase (which they might easily forget later). It is something they can perhaps work on over a period of weeks before deciding to encrypt their wallet (my pass phrase is over 40 characters and includes numbers and special characters but it was not something I could have supplied "on the spot" and still be able to remember months or especially years later).

Although maybe not perfectly clear (due to the need to scroll down a bit) I think the Wiki page does specifically points out that "datadir" (and one other option) are "program argument only" options whereas others can be set in "bitcoin.conf" but then "overridden" by "program argument".