One of the concerns that has been raised several times about a >50% attack is that if blocks were not immediately published but instead kept secret whilst continuing to mine ahead then finally publishing all of the blocks at once to form a new longer chain invalidating all transactions that occurred before it was started (which could be all the way back to the last checkpoint).

Although perhaps not a very likely scenario such an attack would be a massive confidence destroyer - so I am wondering would it not be reasonable for a client to reject a new chain if it contains blocks that it hasn't seen that are much older than blocks in the chain it is already building on (or is this already the case)?

And even for bookkeeping they are not very useful (as typical bookkeeping involves keeping track of individual account transactions which basically you can't do with Bitcoin).

That will not do what you think at all (accounts are *not* addresses).

The only way currently for the OP to do what they want would be to use raw tx's (and I wouldn't recommend that unless you really are very sure about what you are doing).

It's not a bug but "just the way it works" - I also had tried using "accounts" initially and after finding more and more problems just gave up on them (as most others have) - perhaps it would be just best to forget about them?

Accounts can have negative balances and are *not* directly related to addresses (except for incoming txs) - perhaps you have another account that cancels out the one that you are seeing (in any case accounts are not relevant to actual bitcoins held).

Advice - if you think of accounting like an accountant then do not use Bitcoin accounts (they are nothing like that and they have led many users to confusion).

Orphan blocks happen fairly regularly (generally only to a depth of 1 and apart from the well known fork problem am not sure if there have been other orphans of greater depth than 1 but it is of course entirely possible).

If your client receives a block that is later orphaned then it will be stored (and AFAIA will not be removed), however, it doesn't cause any problems as these blocks will effectively be ignored once a longer chain has been accepted.

The change addresses have *never* been shown in the UI AFAIA (unless you use the "coin control" patch).

When you send coins Bitcoin basically randomly chooses which UTXOs to use (including the change ones of course). This is by design to help with your "pseudo-anonymity".

Use "listunspent" to get a list of all your UTXOs.

Yes - I feel your pain (I do all CIYAM Open payments *manually* at this stage).

Basically you would need to write an algo that adds all the inputs (which you find with "listunspent") to your raw tx JSON and then add the two outputs (whilst working out the balances correctly to get that right).

It isn't probably that much work (a few hours) but you would need to do a lot of testing to make sure you don't get anything wrong.

In that case you'll find that the "brainwallet" template does *exactly* what you want (you'll just need to use the "listunspent" call to plug in the correct information) - btw - I would not recommend that you use "brainwallet" website with your private keys (although it can be used offline if you are willing to trust it that way).

If you look carefully at the Transactions tab you'll see that it does send the change back to the original *from* address (note the fee is the difference between the amount you send to the other address and the amount that you send back to the original address).

The tricky bit is if you need multiple "inputs" (rather than just the one) - also the brainwallet Transactions tab does allow you to add other unspent outputs but automating this would not be trivial at all.

The docco is https://en.bitcoin.it/wiki/Raw_Transactions but yes it is not really designed for the feint of heart (and is a very easy way to lose bitcoins if you get anything wrong).

Perhaps you could give a more exact idea about what kind of raw tx you will need?

(if it is just taking a single UTXO and sending it all to an address then that is very simple to do - you might also find the "Transactions" tab in https://brainwallet.org to be a helpful template)

You cannot choose *addresses* with account commands instead you would need "coin control" (search) or use the raw tx API.

Basically do not confuse "accounts" with "accounting" they are instead more like "user accounts" (and used by very few people AFAIA).

You could always throw a complaint at SD for sending you dust "message" outputs (there are many here who would be glad if they changed their model).

Indeed you will have your work cut out for you trying to get Bitcoin to work with MSVC although it certainly should not be impossible as all the libraries that Bitcoin uses are available for MSVC but usage of specialised build tools will probably be the thing that makes things hardest.

Actually a new address is added to the pool each time one is used (so the pool is *always* 100 addresses) but otherwise correct.

The best idea to to keep regular backups (I back up my wallet pretty much after every tx) and keep them on different media (i.e. hard drive, flash drive and CD-R) and at different physical locations.

If you are using the Satoshi client then a "key pool" of 100 addresses is stored in your wallet (this can be increased if desired) - thus if you have backed up your wallet it can be fully restored even if up to 100 txs have occurred since that backup was taken.

Fundamentally understand that your wallet contains "private keys" (not bitcoins) - the blockchain (which every full node has a copy of) is the *ledger* of every single tx that has ever occurred.

Provided you have a backup of your wallet then yes it doesn't matter if your computer is destroyed, or crashed, or if your internet connection died - the wallet can be restored and the blockchain contains all the tx's (so your balance will also be able to be restored).

There are some edge cases where your wallet might get "out of whack" (due to a crash or other problem) but at worst you can always restore the backup to a new install to recover (always keep backups).

Also if you do have offline backups of your private keys then your wallet indeed can be reconstructed, however, you need to understand that *change* addresses are normally hidden from you (so after sending a tx bitcoins sent as change back to yourself are then likely to be at a new address that you do not have stored in paper form).

I have been developing a system for paying for contributions to Open Source projects that uses "open book" accounting and provable delivery (in combination with git push request merges).

Such "open book" accounting would also be very useful for NGOs (and has never existed before in any way that could be trusted).

How about being able to send money to anyone anywhere in the world in minutes with basically zero fees and involving no need to exchange anything other than a pseudo-anonymous address?

All UTXOs need to be spent *in full* (if not then the remainder is *fees*) so yes the client can only do one of the two.

Please don't - we really need to work together to get the conventions and specifications at least "singing from the same hymn book".

(maybe "guidelines" to go along with the specifications?)