I hope it makes it into 0.7, because once you got used to it, it's really nice and handy. I'm glad Luke-Jr ported it to 0.6.2

I invested some time trying to narrow down the cause of this. By summing up debits+credits, grouped by addresses (from the exported transactions), I narrowed it down to two addresses. One should still contain 0.001btc, the other 0.058btc. The displayed balance lacks exactly those 0.059btc (coincontrol doesn't show them either). A rescan didn't fix this either, so I installed pywallet in a clean VM. I launched 0.6.3 to create a new wallet, shut it down again and started to import all tx_k and tx_v related to those transactions with the address missing 0.058btc, but pywallet failed to import two transactions (0.03btc and 0.015btc). Not sure if that's related to the missing 0.058btc since it's only 0.045btc. So I switched the wallet with the empty one again, only imported the key for that one address and then ran Bitcoin-Qt with the --rescan option. When that was finally done, I was greeted with an unspent balance of 0.058btc.

Now I think about importing every single private sec key from the pywallet dump into a new wallet (either via pywallet or bitcoind's importprivkey) and do a rescan to fix everything. If that succeeds, I should be safe to delete the old wallet, or am I missing something?

I noticed the "About Bitcoin-Qt" says 0.6.3-beta while this topic says 0.6.3

Will coincontrol be merged into this version too?

Does this version fix the bug where the balance is miscalculated (getbalance("*") vs getbalance())?
In 0.6.2, I have a 0.059btc difference between what the client displays, and what the csv exports.
Blockchain up to date, all exported transactions are confirmed.

While I don't want to stop anybody from doing whatever they want because they assume something is wrong, it would be a good idea to invest a little time into research, since that is faster and more reliable than blindly formatting, especially since rkhunter generates false positives too.

http://askubuntu.com/questions/1537/rkhunter-warning-about-etc-java-etc-udev-etc-initramfs
Also, on Ubuntu there should be debsums which can be used to verify packages.
Of course you can always reinstall, but you'll get the same messages again.

Yup. You wouldn't be pissed if you worked on a (luckily small) project with someone who, after you did your part of the deal, just decides not to pay?

While I have "only" lost the time I spent working for him, I can still warn others, no?

Which is true. I sent him an encrypted archive containing the script.
I discussed all the details and requirements with him and then finished the job.

Then it's a bug that all others transactions to myself show up? I've been using coincontrol to move around a few of my coins from one address to another (yeah, I shouldn't care about that, but sometimes I'm just like that) and each of those gets listed. Without the sending/receiving address and the amount though, see my bug report a few posts earlier here (well, the amount shows up, but only if you double click a transaction). I understand that automatic coin-change transactions don't need to be displayed, but when I manually create the transaction, I expect it to be listed.

As for coin-change in general: it would be nice if the change would go to the address from which coins are send. Or if there was an option to display all transactions, even automatic change transfers.

Ran into another bug:

I sent some coins (using coincontrol) from one of my addresses (A) to another person (B) and decided to send the leftover amount (essentially the change) to one of my addresses (C).
The transaction to the other user just shows up fine in the transactions tab, however the one to myself is missing in the list.
Since the involved balances are all correct (A to B is ok, change went to C, A is empty), I assume it's just not displayed in the transaction list.

I don't have an account there, maybe someone could push it to github?

On 31. May, he offered a 5BTC bounty for a script: https://bitcointalk.org/index.php?topic=84467

We discussed the requirements in PM and I told him that I'll work on it after he gave me a test account. It looks like he accepted another user for the same job too.
discordian666 definatively was online after I sent him my PM and before I delivered the result, so he could have easily told me that my work was not needed anymore.
Unfortunately, the other user handed over his solution without getting paid first.

After I sent my results, discordian666 decided not to react for a few days, so I sent a reminder on 2. June.
He replied, asking me to wait a few more days until he gets some BTC to pay me.
The next reminder I sent on 7. June to him and he asked for my BTC address (which he already had).
On 11. June, I told him that I'll only wait until 15. June before making it public.
He's been online after that, so he received my PM but decided to remain silent.

Well, today is the 16. June. I offered him numerous times to sort this out in PM, but he chose to ignore all this.

What if the blockchain itself gets changed? As in, not only changing how parts/all of it are stored, but also its format.
If a client needs to verify an input, it shouldn't have to scan the entire cloud-chain. Instead it sends off a request for input validation to the network, and e.g. the clients who store those blocks which prove the inputs will reply with an udp-ACK. With enough ACK's from different clients, it's safe to assume that the input indeed exists. Kinda like DNS.

My opinions about this so far:

- SatoshiDice is legitimate. It may not try its hardest to make the most efficient transactions, but you will always have clients who aren't perfect. SD just does what might happen in 2-3 years anyway, but by lots of different users. SD can use the system only within the given limits; if it would do something wrong, transactions would get rejected. Basically it boils down to the underlying protocol restrictions: spammers for example are really hated, but they operate fine within the SMTP-RFC.

- Someone mentioned "trusted nodes": that's what SolidCoin advertised so heavily. And what failed. Giving control to few nodes might blow everything up.

- Restricting the heavy users won't help either. That's similar to the ISP who advertises with "unlimited downloads" but later throttles you when you download >1GB/month.

What about changing the way the blockchain is stored? Instead of having everybody store the full chain, they could store only 1-2% of it. 50-100 users then would have the entire chain, and with tens of thousands of active users, there would still be hundreds of sources for each block.

Clients could join a swarm when connecting which sort of represents the entire chain. Although clients would only store fractions of it, the entire blockchain is always available. Pretty much like a Bittorrent swarm is still fully functional as long as every single block is at least on one seeder's machine. You'd only need a small index file (think of blockchain.torrent) which handles the checksums of blocks (note that I'm not talking about bitcoin-blocks, but data-blocks, eg 10MB chunks). Add an option to let users decide how many % they want to store and voila, someone can decide to provide a full copy.

When sending coins from one of your addresses to another one of your addresses, the client only displays an entry saying "transaction to yourself" without listing the amount or the from/to address.
While this isn't a bug, it makes keeping track of your coins difficult. Blockchain.info for example lists the transaction just like every other one; I suggest that the client should do the same.

Noticed the same. Payment has gone way downhill in the past weeks; down to the point where it's not worth it.
I haven't done a task for a long time there. Especially since the tasks seem to require more work while paying less.

Asking for help is a good thing, especially if the person learns from it. But don't shoot yourself in both knees by trying to save some time by being lazy.

Suggesting that a problem doesn't exist anymore simply because error notices are turned off is not a good thing.
Just like the train that still will hit you, even though you closed your eyes and don't see it coming.

Code should not produce errors/warnings/notices when "operating normally". Usually it's a simple error like in this case and easy to fix.
If you don't fix it, you'll miss the more serious errors simply because of the size of the error log.
If you turn error messages off, you'll miss every chance to fix an error before it blows up right into your face.

Which is done by "developers" who later end up in forums asking "HALP my site got ownzored n I dunno why lolz"

Encryption is not about data protection (as in, failure protection). You are talking about RAID which you already have (also, RAID is not a backup).

Of course you can backup this data (and you should). USB drives aren't really expensive and you can get a few 2-3TB drives pretty cheap. Freefilesync has proven to be pretty nice for my requirements. Remove the default partitions, create a single new partition on the drive and use this one to create a Truecrypt volume (not a container) with a decent encryption.

Truecrypt containers/partitions don't really care about a bad block. You can (and should) save the volume header somewhere since this block is the most critical part of a volume as it is needed to verify your passphrase.

You need to come up with a backup plan. The key is to keep your backups automated (because you will get lazy and do them less often over time and only realize this when you're screwed). But you still want to check them occasionally to make sure your automation is still working correctly. It's simple to test: a week or month after you started your backup strategy, simulate a worst case: do not touch your main system (don't even boot it), but try to recover everything you need from your backups. Did it work? Good. Did it fail? Fix it quickly. You might find very obvious mistakes you didn't realize: like storing a complex password for your Truecrypt container in Keepass, which you stored inside your encrypted backup disk...

A backup is not a backup as long as something like a drive failure can ruin it (because you will find out that the USB disk fails when you need your backup). Always keep your backup on two drives at minimum. One drive died? Oh well, plug in the other one and restore everything to a new drive. Note that I'm not talking about RAID-1 here, but two completely independant drives to which you backup your data (although data on them both is identical).

You might want to look at the BC Math functions

Typo or freudian slip?

It was swissmate who replied, not me.

Funny, my Firefox doesn't know EssentialSSL. Opera doesn't have any problem with the certificate issuer.
Somewhat a false alarm it seems.