Send it to my screename, at gmail dot com.

I actually, already have those addresses marked in the address list as "[[ Change Received ]]" with an appropriate description in a tool tip.  And there's a little "(?)" helper above the output list when viewing a transaction that kind of explains it.  But that only helps the patient users.  A lot of people don't take the time to try to figure it out, and would rather write me a frantic email and have me explain it to them. 

Those coins become "new" the moment you use them.  So they left your Bitcoin-Qt wallet as old, no-fee-required coins, but they entered your Armory wallet as young coins.  If you sent 0.1 BTC, you're going to have wait 10 days for those coins to mature (1 BTC matures in 1 day).  The fees were supposed to be insignificant in the short-term, only to discourge people spamming the network.  But the price rise has made not entirely negligible anymore.  But $0.07 still isn't so bad compared to the alternatives.

There's been a lot of discussion about how to improve the fee logic to be adaptable to... life

By the way, I get the exact opposite problem.  Armory is too transparent about this:  it shows all your change addresses, and if you double-click on a transaction it shows all outputs, including change.  I have had multiple people email me and say "Help me I've been hacked!  Armory sent all my coins to this mysterious address I didn't authorize!"  If they look closely, I identify that address is part of their wallet, but people still get uncomfortable.

I'd really like for change addresses to be transparent, but it's not always possible.  At least not if you're going to give the user lots of information about their transactions.

I don't mean to go troubleshooting in this unrelated thread, but perhaps this topic is essentially closed anyway (question answered).  So I won't feel guilty about it. 

There seems to be a problem with some existing Bitcoin installations, where the block data gets corrupt and Armory can't read it.  That's why it gets stuck.  And also why I'm changing the stuff under the hood to avoid this in the future.  It has led to me recommending that users redownload the blockchain until I have a more-robust solution in place. 

It's not ideal, by any means.  As I said, the price of security and features (in this case) is usability.  Luckily, once you get over the usability curve, Armory is actually qiute pleasant, but the setup can be a pain for some configurations.  I'm working on making this easier.  Until then, I don't blame people for glossing over it when it doesn't work out-of-the-box.  I hope I can make it work out-of-the-box, better.

Alternatively, I kind of like "Bitcoin routing numbers", which gives it the feel of a bank which people are already somewhat familiar with.  Or something like it.  It gives it the feel of "This code tells the network how to route the money to the person you're paying". 

It's not the output amount that is the problem (unless it is less than 0.01), it's the age of the coin(s) being spent.  It is an unfortuante that this is so inconsistent and confusing.  But it's not a problem with Armory, it's just the way the network works, and you don't necessarily have control over when you have to pay a fee.  Luckily, the fee only 0.0005 which is about $0.07.

I don't have any recommendation for you, other than you might just have to pay the fee

#2 was jdillon's original point, and the one I was supporting.  But not in the context of non-final transactions -- I thought the post was about replacing already-final transactions, and I was pointing out there was no way to avoid some miners doing it, and thus undermining the usefulness of them.

But five posts back, I was pointing out my own revelation that any such arguments as made in #1 (already final tx), are necessarily applicable to #2 as well (replaceable tx).  And pointing out to readers that there are two distinct contexts here, that have been kind of jumbled together in this thread.   This revelation bothers me a bit, because the fact that already-final zero-conf tx are useless was not news to me.  But the fact that tx replacement may also be useless for the same reasons is unfortunate.  I hadn't considered that the same arguments applied.  

But I don't think it's a lost cause.  It's feasible that such transactions/contracts are useful enough because they aren't typically made between zero-trust parties... usually there is some degree of association between them, and the quantities of money at stake doesn't have to be very high.  And perhaps, if you only plan a couple dozen replacements, it still works as long as you reduce the locktime each time.  

It was really just food for thought.

My post was not about how it is at this moment, but under the assumption that tx-replacement become standard at some point.  It would become standard under the assumption that it would be useful for a variety of things discussed in the community over the past couple years.  I was just pointing out that it's not so clear-cut if you assume that miners will not follow "ethical" replacement rules.

Unfortunately, building on top of that "bloatware"  is the best way to maximize your security and avoid hard forks.  Which is fairly important for a piece of software that advertises maximum security.

It won't be,  in the future,  but it's the best solution available right now.   All apps trade off various dimensions of security for convenience/usability.  You clearly don't prefer this tradeoff. Oh well.

Yeah, it's got some usability issues to get over.  But it is a widely used app for people that are serious about Bitcoin security.   Like many advanced tools,  it may take some patience to get setup.   You'll notice that the website doesn't say anything about being for new users.

This is why you use a solution like Armory (which is what the original OP is talking about).  The paper backup holds every address ever generated by the wallet.  Including change addresses.  You don't have to worry about it, it's completely transparent to you.

(1) Restore your wallet
(2) Send coins
(3) Destroy your computer.

Armory will send change to the next address that is already backed up by the paper backup.

I've spent a lot of time thinking about this, discussing it here, and on IRC with smart people.  I have some extra clarification and context to this discussion that is worth mentioning.  Apparently, my strong argument in favor of this is equally applicable to a feature of the network I had not realized would also be broken.  Not that it changes my argument, but it does expand the breadth of consequences of accepting that this will happen (which I still strong believe is true).

We need to separate the two concepts and make sure we're talking about the same thing:

(1):  You have final transaction that is sitting in miners' memory pools, waiting to go into a block.  Now a second final transaction comes along spending one of the same inputs, but with a higher fee.   What does the miner do?  Well, the current default behavior is to drop it and mine the first transaction they see.  This is the behavior of the majority of the network right now, but there is nothing stopping individual miners/pools from modifying their source code to do the "unethical" behavior of replacing the original with the higher-fee transaction.  This is what I originally thought this thread was about:  a call for a patch to make this "worst case" equal to the "best case" to prevent the system from adapting to a false reality.

But there's another situation we would all like to depend on (and perhaps, have assumed will be usable in the future),  but which is equally subject to the above argument:

(2):  You have a non-final, replaceable transaction that is sitting in miners' memory pools, waiting for the locktime to expire so they they can mine it into a block.  Now a second transaction comes along that meets all the requirements of transaction-replacement (increased sequence numbers, etc).   The intended behavior is that the miner will drop that the original transaction and replace it with the new one.  There doesn't even have to be an increased fee, especially because it's essentially zero-cost for the miner to update their memory pool with the new tx.  However, for similar reasons above... the miner doesn't have to replace the transaction, and if there was economic incentive to mine the old one (perhaps a second transaction with a huge fee that spends an older version of the replaced tx), then there's nothing stopping them from ignoring the replacements.  The original (to-be-replaced) transactions are completely valid to mine after the locktime, leading to a standard race between good and bad miners.  This allows for one party in a HFT (rapidly-adjusted micropayment) contract to have some probability of screwing over the other party.

This is troubling, because there's a lot of cool things that become possible with transaction replacement, but nodes are not obligated to replace transactions, they only have to allow it if they want.   Fortunately, these two situations are not exactly identical.  One thing that might save #2 is if you can change the locktime on the replacement to a couple blocks sooner, to almost guarantee it can be mined by honest parties, before the older one can mined by dishonest parties.  But I don't know if you can change the locktime on a replaced transaction, and it would severely limit how many replacements could be made.  But still better than nothing...


One last thing to consider is that, in #1 the exchange is usually happening between parties that have never met and have zero-trust (or at least one direction has zero trust).  Merchant has zero trust of this random customer that just walked into the store.   But #2 has the pretense that the parties already have some association with each other, and thus >zero trust, or else they wouldn't be setting up this replaceable/contract with each other.  It doesn't stop it from happening, but it does imply that one party may have recourse if the other one screws him over

I think it's confusing only because the original "address" terminology has been so widely used.  But to someone who is completely new-to-bitcoin, that that string of 33 letters is a "code" that lets you send money to that person/wallet.  There are millions of addresses in your wallet, but they all go to the same place:  they all go to one person/wallet.   It should be that your wallet is really your "identity" and addresses are temporary payment codes that the network understands to route the Bitcoins to your wallet.

And not re-using addresses is more of a best-practices thing.  For privacy reasons, and [super-]long-term security reasons (super-long = decades).  A lot of people don't realize the privacy implications of constantly reusing addresses and irrationally decide that it's best to re-use them.  Making them "one-time payment codes" furthers the notion that they should not be re-used unless you have an explicit reason to.  Yes, there are reasonable reasons for doing so, but it should not be the default.

Log file?

• You only need to backup your wallet once, ever
• You can backup your wallet to a single sheet of paper with only 4 lines, which is superior in may ways to digital backups (inexpensive, durable, hidable, visual integrity)
• Multiple wallets interface to segregate your funds into different categories or security tiers
• The absolute easiest offline wallets imagineable.  You can keep your coins offline, but it only takes 1-2 minutes extra with a USB key to move coins from it like a regular wallet.  Your online wallet produces the exact same addresses as the offline wallet, but the online wallet cannot be compromised (well, your privacy can be compromised, but not the security).  You can easily transition from an online to offline wallet, if you want.
• Create clickable payment requests to copy into emails or webpages
• A lot of really advanced features if you switch to "Expert" usermode

I'm sure there's more stuff, but those are the things that are probably the most appealing.  You can pare it down to what you find most impressive.  The cold storage thing is critical though:  I'm constantly running across "wishlists" on the forums, of people wishing that .... well Armory existed (listing all these features without realizing it already exists in Armory).

By the way, if you do a lecture about it.  Spend some time getting to know it.  Use the offline wallet feature.  And be sure to add the warning about resource usage.  It's still very heavyweight, and not suitable for all computers (the offline version will run on anything, though).  This will be resolved in the next month, but until then, it may not be usable by everyone.

Some links:

https://bitcoinarmory.com/using-offline-wallets-in-armory/
https://bitcoinarmory.com/armory-quick-start-guide/
https://bitcoinarmory.com/get-armory/

I do have to admit:  talking about "the Bitcoin" kind of makes me cringe.  That's not the normal grammatical context we use.  Either "we are talking about Bitcoin" or "we are talking about the Bitcoin system/network/protocol".  Otherwise, I perused the content and it looks like good information and context.

I'm still amazed that people spend so much time talking about Cold Storage and never even mention Armory.  Armory has been doing this for over a year (an eon in BTC time), and is the most trusted and intuitive solution for Cold Storage.  I'm up to about 10,000 downloads per month!  Yet somehow, so few people actually know about!

I guess I need better marketing.

That sounds like a fair trade!    I promote you, you put up a lecture about "Cold Storage" and Armory. 

The blockexplorer would be cool, too, but it's probably no short amount of work if you are not familiar with Armory code and/or python and/or PyQt.  I'd like people to have the functionality but it's not high priority for me, and in the end I'm not sure that many people would use it...

I would want to see the course first, before promoting it.  But there is definitely a shortage of informational material out there, so most likely I'd be down.  I could at least put a link to you on the website, and maybe in the help section. 

I might put up a bounty to create a block explorer out of armoryengine.  I know it's possible, because I've done it.  But I don't have time to do it, myself.

Again, in the sample_armory_code, there is actually a full script for parsing the blockchain since the inception of SatoshiDice, and collecting every bet that's ever been made, calculate bet statistics, profits ,etc.  Dooglus maintains that thread now (and script), but it demonstrates what is possible with armoryengine. 

Granted, I mentioned that full blockchain scans from the python side will be really slow.  So dooglus updated his script to maintain memory between calls.  It's just a caveat worth mentioning if you want to do full scanning, not just point-and-click exploring.  The C++ code can scan the entire 7 GB of blockchain in 2-4 minutes.