I fixed it!
For the curious, technically inclined:
The problem appears to be that when a transaction is created, the keys of the bitcoins being used are added to the transaction itself inside of the wallet. Therefore, deleting the transaction in the raw db of wallet.dat will also delete the keys of the bitcoins that the transaction had allocated for itself!
I fixed this by using Sipa's fork of the Bitcoin client, which is a client modified in such a way as to detect and fix conflicts between a wallet's tx's and the blockchain. However, I had to modify it for my purposes, since there really is no conflict -- the transaction is just the result of an unrelated bug
What I did was add an RPC command to revert a transaction using Sipa's functions: all I did was call wtx.MarkConflicting(true), and then wtx.WriteToDisk() for my buggy transaction. This gracefully did all the magic of removing the transaction from the wallet, as well as restoring the bitcoin keys to their original, un-tx'd selves
I am reading about more and more people who have the same problem as me, where sending the entire contents of a wallet results in placing the bitcoins in limbo for all eternity. Sipa's got a good thing with his fork; I highly suggest to the powers that be that they merge it, as well as a debug RPC command to revert any transaction which has zero confirmations -- why not make it easier for people?
For the curious, technically inclined:
The problem appears to be that when a transaction is created, the keys of the bitcoins being used are added to the transaction itself inside of the wallet. Therefore, deleting the transaction in the raw db of wallet.dat will also delete the keys of the bitcoins that the transaction had allocated for itself!
I fixed this by using Sipa's fork of the Bitcoin client, which is a client modified in such a way as to detect and fix conflicts between a wallet's tx's and the blockchain. However, I had to modify it for my purposes, since there really is no conflict -- the transaction is just the result of an unrelated bug
What I did was add an RPC command to revert a transaction using Sipa's functions: all I did was call wtx.MarkConflicting(true), and then wtx.WriteToDisk() for my buggy transaction. This gracefully did all the magic of removing the transaction from the wallet, as well as restoring the bitcoin keys to their original, un-tx'd selves
I am reading about more and more people who have the same problem as me, where sending the entire contents of a wallet results in placing the bitcoins in limbo for all eternity. Sipa's got a good thing with his fork; I highly suggest to the powers that be that they merge it, as well as a debug RPC command to revert any transaction which has zero confirmations -- why not make it easier for people?