What you are describing is not a "reversed transaction" but simply a transaction that apparently never got broadcast.

The Bitcoin-Qt/bitcoind client does not send out a spend transaction until it has reached sync.  So it could have been perfectly bad timing where just before when your transaction was communicated to bitcoind (which is what Armory uses underneath I believe), that client discovered a block at a greater height and did not send the transaction. 

Now when the client is restarted it does not automatically re-broadcast a transaction.  The bitcoind needs to remain running, sometimes a half hour or (or longer maybe) for any transactions to get re-broadcast.

So, at this point -- make sure you've left everything running for a long enough period to make sure no spend transaction is just waiting to get re-broadcast.

If that doesn't change anything then I'm pretty much out of suggestions.  If the Bitcoin network doesn't know of your transaction (e.g., blockchain.info doesn't have any knowledge of it) and your client isn't re-broadcasting it then either the transaction was invalid and no peers will relay it or it somehow never got saved. 

The bitcoind wallet uses BDB so I suppose if that got taken down with a crash and the database wasn't closed that a rollback in the local BDB wallet.dat database could have occurred to the point it was at prior to you sending the payment.

If this is to an address in your own wallet, there's nothing really to worry about if the transaction were somehow later be re-broadcast.  If it was to some other party, one way of ensuring that the lost transaction becomes moot is to spend those coins with a new transaction.  So if your wallet has 1.123456 BTC, send a payment to an address you control with all 1.123456  (less transaction fee) so that even if that missing transaction were somehow to resurface at some later time it would not be a valid transaction (as you've since re-spent those funds).

The wallet contains keys in a key pool.  So a backup taken today will already include the keys for my next 100 transactions where a new address is generated for change (or where an address is generated because I clicked New).

So any recent backup probably has all the keys you've used ... unless you do a lot of SatoshiDICE wagers or that kind of activity.

Wallets can be restored, then another one restored without any impact.

You will want to launch the client with -rescan though the first time after each restored wallet.dat.

Redo your math.  It is 1/100th of BTC/USD, so about $0.44 at current rate.

Except that is not the mandatory fee assessed low priority transactions.   If you have low priority transactions, you will be assessed 0.0005 BTC per 10KB.   If you have a high priority transaction, there is no mandatory fee.

This has been this way since version 0.4 or something like that. 

If you are being asked to pay a 0.01 BTC fee it is because you have a low priority transaction that is huge.   How does one avoid this?   Stop using bitcoin as a micropayments network.  If someone is sending you bitcoin dust (like SatoshiDICE does for losing payouts), then stop patronizing that service.

Oh.  Minor detail.   

You are actually asking how to securely remove a bitcoin wallet from your system  (or the more extreme, remove any trace that Bitcoin was ever on a system ?)

Know that deleting a file does not necessarily delete the file (that's why they have "undelete" tools).    So if you had a wallet without passphrase encryption, and then you delete that wallet.dat, there are ways of still recovering the keys.  There's even a nice utility to scan your hard drive to find it:

Bitcoin private key/wallet.dat data recovery tool!
 - http://bitcointalk.org/index.php?topic=25091.0

It isn't just the duration, it is space in the memory pool.  As that space fills up, older transactions get bumped out.

Nope.   The best you can do is export all the keys, create an empty wallet, then import the keys except those you don't want.

Your transaction is still valid so you definitely shouldn't be sending a new transaction. 

The transaction will likely get included in a block at some point.  Is it currently showing on blockchain.info as unconfirmed? 

This was actually a good example to help describe this.

When the plea came for miners to downgrade to v0.7, those pools (and large solo miners) who had already solved the six or so blocks on v0.8 (v0.8 was ahead by about six blocks at that point) had the option of continuing on v0.8 instead of abandoning those blocks (and the bitcoins they would earn) when downgrading to v0.7.  Let's say these miners held their ground in order to try and keep the bitcoins from those six blocks.    

It would soon be apparent that the plea was being ignored by enough miners and that there was still plenty of hashing on v0.8 such that it would take a long time for v0.7 to catch up.  So instead it would then be those mining on v0.7 that would be faced with a decision:
 - a.) Do nothing and continuing to mine against a fork in which every block stays orphaned
 - b.) Upgrade to v0.8 (which could take hours or days to complete)
 - or c.) Implement a fix and start mining using it.

If the BDB issue was fixable, there would likely have been a bunch of frantic development and testing performed and code slipstreamed into production.  (i.e., option "c.)" would have been chosen)

So if there was a fix, that code would have been running by pools and large solo miners before there was even an release published.      Source code containing the patch can be transferred via a pastebin/gist/text file/e-mail attachment in most instances.     It wouldn't be forced on them, but when choices are limited, the path of least resistance is often chosen.   Fixing v0.7.x (again, if it was fixable in a reasonable amount of time) might have been the outcome instead.  

Eventually releases with the fix would be published through the more formal process (built and tested prior to release, etc.) so that even those who don't build directly from the source code themselves can switch over and resume mining on the longest chain.

This process isn't uncommon.  There have been vulnerabilities where the developers share the remedy with pool operators, large miners and others before sharing the fix publicly.  So building from source code is something most pools and large miners are prepared to deal with.

You sent bitcoins to an address that Camp BX gave you but now you don't know what that address is?

What tool or site did you use to send the payment (or request a withdrawal) from?  Usually there you can see a record of your withdrawal to know what Bitcoin address those coins were sent to.

2013-03-11 Arstechnica: Major glitch in Bitcoin network sparks sell-off
https://bitcointalk.org/index.php?topic=152129.0

Yup.

Using Blockchain.info you can paste the Bitcoin address you sent the funds to.  It should show your transaction.  If that transaction has six confirmations, then Camp BX should be crediting your exchange account for that deposit.

 - http://www.Blockchain.info

Ok, if your v0.8 client is sync'd it should now show everything correctly.  Did the problem resolve itself?

 - http://en.bitcoin.it/wiki/Contingency_plans#Alerts


There is an authority, it comes from the longest chain.  That is reached through consensus.

Right now the longest chain is block 225453:
 - https://blockchain.info/block-index/357985/000000000000031803e492a0103154d243c9945ef78dbdba42a1ecfdb5bc5dbb

So normally a miner would be building off of the block at the greatest height and now working on extending that ... building the next one, 225454.

Except we know that that specific one is created using v0.8.  And it will be orphaned.  And a miner that solves an orphaned block gets 0.0 BTC as a reward for that effort.  Miners can only spend generated coin from blocks once that block has 120 confirmations.

So now a (large) majority of miners are now running using v0.7, and the block with the greatest height that v0.7 client knows of currently is this 225445:
 - https://blockchain.info/block-index/357992/000000000000012966aca980b406faa35b4c7abcc896846794f2c3f6f9b63aa0

So even without an authority ordering miners around, miners do what is in their own best interest.  Everyone on the same blockchain chain.  And to get there, dropping to v0.7 was the quickest way to get there.

Sure the v0.7 nodes could have known of the transactions but there were fewer v0.7 blocks and the contents of the blocks were different from the v0.8 mined blocks.

I'm not expecting that this happened, but some of the new nodes that downgraded from v0.8 wouldn't yet have those "not-yet-onfirmed-in-v0.7" transactions in their memory pool, which opens a truck-sized hole for someone attempting a race attack.  

So I'lm not sure I'ld call it a "theoretical" risk.  If there was one or more successful double spends as a result I wouldn't be surprised, and had someone prepared in advance for this and had perfect timing and good luck, significant losses for a couple exchanges could have been the result.

 - http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12  

There might have been a couple reports of issues on the 11th.  The times are UTC so this starts on the 12th.

Did it really disappear or just did it revert back to unconfirmed?

The reason the exchange rate is lower at BTC-E is because of the cost to move money there is higher.   So essentially the price there is in equilibrium with the price elsewhere.   That's how markets work.   If there was a cheap path from Dwolla to BTC-E, the price would rise to where it is on par with the other Dwolla-enabled exchanges (Camp BX and Mt. Gox).

There are multiple valid solutions for any piece of work.  Any hash at or above the specified difficulty.  So for a given unit of work, eventually someone else will also find a hash that meets the minimum difficulty requirement. 

But even that doesn't matter as the work to be performed changes with every new transaction or when work on a new block is started.   So a miner that solves a block but withholds publishing the solution harms the pool.   Over a period of time the pool can determine that a specific miner is doing this and give that miner the boot.

Even when that is discovered, it isn't worth going back and re-doing that work because since that time the work has changed (as now there are new transactions or new blocks or both).

BFL speculation is an olympic sport around here.