Is it possible that it took 3 hours for the transaction to get 1 confirmation?  When it first appeared, did it have one confirmation?  Or was it already confirmed.  Armory has a problem (Windows only) that it doesn't remember zero-confirmation transactions between loads.  So, if it takes 3 hours to get one confirmation ,and you restart Armory right after you send it, you won't see it for that long.

Adding that right now...

Port 8333 is the default listening port for Bitcoin-Qt.   I am not familiar with proxies at all, and never really used any custom CLI options with Bitcoin-Qt.  So I can't really comment any further on this.  But if someone can give me a short list of what needs to be done to get Bitcoin-Qt-already-connected-to-tor, to play nice with Armory, I'll happily post it on my website.

Also, Armory does a version check when it first opens, which can be disabled by going to "Help-->Armory Version..." and clicking "Never check for new versions".  Someone complained about that.  There's also an "online check" to determine if the user has an internet connection -- basically it just checks for google.com.  That can be disabled via --skip-online-check on the CLI.

Just an update that's hasn't been mentioned here:  evoorhees says that they just switched to the per-TxOut method of computing lucky numbers, instead of per-transaction.   That means that bets on SD are no longer correlated:  you get a different lucky number for each output in a single transaction.  If betting continues exactly the same way, SD will have the exact same expected profit, but with much lower overall variance.  It will cut down quite a bit on those enormous swings.

Is Bitcoin-Qt finished synchronizing with the network?  How long has it been since you sent it?  Does blockchain.info show it as having any confirmations (you can right-click on the address in your wallet and click "Show on Blockchain.info")? 

If it has confirmations in Blockchain.info but Armory doesn't show it, then it's likely that for some reason Bitcoin-Qt isn't up to date (still synchronizing?).  The current block (as of this writing) is 215,197.  What does it say in the bottom-right corner of Armory?  If everything is normal, it should say something close, like "Connected (215197 blocks)".  If that doesn't match the latest block on Blockchain.info or blockexplorer, please check Bitcoin-Qt.  In the bottom right you can mouse-over the green checkmark and it should say 215,197.

None of the binaries are on the "official Armory page".  All the links to current versions are links to the s3.amazonaws.com storage.  I've been lazy about GPG-signing the testing versions because it's already a lot of work to make them, and the Armory signing keys are offline.  If it's a high-demand feature, I can make it happen (though, it's not very convenient for Windows users...)

Well, I guess I'm not done with the links, yet.  I'll have to spend some time on my VM to fix them.

But everything else should be fixed.  At least, everything that I starred previously.

One thing that wasn't mentioned yet was that there's not currently a mechanism for replacement.  Locked transactions can be "introduced" into the blockchain fairly easily, and nodes will accept them and hold them in their memory pool (and thus drop conflicting transactions), but they won't forward otherwise-valid replacements, and only miners with custom rules will mine them for you.  If you want to replace a time-locked transaction, you're going to have to mine it yourself, or go find a miner to agree to help you.  Once a replacement is mined (or even just a regular transaction spending one of the inputs), all nodes holding the time-locked tx will see the conflict and drop the one in their memory pool.

So, if you can create the tx, you can get the "time-delay" aspect out of the network right now, but you have to work pretty hard if you use the "replacement" aspect of it.

P.S. - Congrats on being the most well-spoken, research-driven, single-post Newbie I've seen on these forums

COPIED FROM ARMORY DISCUSSION THREAD

All bugs previously reported (and acknowledged) have been fixed, thus the bounties are reset (if something still doesn't work that I starred before, you'll get a bounty).

---

Updated Windows installers for testing version 0.86.6.  

https://s3.amazonaws.com/BitcoinArmoryReleases/0.86.6-testing/armory_0.86.6-testing_win64.msi
https://s3.amazonaws.com/BitcoinArmoryReleases/0.86.6-testing/armory_0.86.6-testing_windows_all.msi

Linux users can just checkout the "testing" branch.  Please test payment-request/clickable-link copy&paste in Windows.  The link copying works in Linux, but it didn't appear to work in my Windows VM, and I'm not sure if that's a VM-ism or real.   The original reason it didn't work was because I used:


And it turned out I needed this <meta> tag in Ubuntu:


If this doesn't work in Windows, can anyone recommend how I might get it to work in Windows?

Updated Windows installers for testing version 0.86.6.  I compiled it before that first round of QR code inclusion, but I will have a separate testing release for that when it's done.

https://s3.amazonaws.com/BitcoinArmoryReleases/0.86.6-testing/armory_0.86.6-testing_win64.msi
https://s3.amazonaws.com/BitcoinArmoryReleases/0.86.6-testing/armory_0.86.6-testing_windows_all.msi

Linux users can just checkout the "testing" branch.  Please test payment-request/clickable-link copy&paste in Windows.  The link copying works in Linux, but it didn't appear to work in my Windows VM, and I'm not sure if that's a VM-ism or real.   The original reason it didn't work was because I used:


And it turned out I needed this <meta> tag in Ubuntu:


If this doesn't work in Windows, can anyone recommend how I might get it to work in Windows?

It is, but also necessary.  I need to make an Android app eventually.  And a buddy of mine has already been able to put a wrapper around the Android-Bitcoinj libraries and wrapped my current (soon-to-be-outdated-but-easily-updateable) detereministic wallets algorithms.  I think my first goal will be the simplest:  try to make it possible to use an old Android phone as your offline signer -- though, I haven't quite figured out how to xfer the data yet.  At the very least it should be able to be able to serve as a second-signer and get the data via email and special URL format...





I definitely want to make a corporate version (and charge for it!).  It would probably have to be locked down a bit, though, to prevent employees from swapping their own addresses in for the customer payment addresses.  Actually, there's some other ways that would be fun to discuss right now, but I want to get back to putting all these QR codes in

Clearly you don't understand that paper -- which describes the most basic, and widely-known QC algorithm out there.  "Grover's Algorithm" is the first thing you learn in a class about QC, and is the most basic and widely known algorithm out there.  All it does is cut the effective number of bits in half for brute force searching.  If you are trying to guess a 160-bit password, it'll be like an 80-bit password on a QC.  If you are trying to guess a 256-bit value, it will take 128 bits.  

For reference, the Bitcoin network has performed approximately 2^68 hashes in the entire 4 years it's been operating.   A long ways off of 2^80 to "guess" a 160-bit password. The bit sizes of the chosen algorithms are big enough that even one half the number of bits is still considered secure.  And when QCs come around, we only have to double the number of bits in our key sizes and the attackers are back to where they started.  Hardly "blown open".

I'm starting to be swayed by the idea of having some kind of "lite" mode Armory that follows the Electrum model.  Hell, maybe I could even use the Electrum servers!?  I don't like the reduction in security and the centralization... but it's really not that bad.  It seems to be limited mostly to DoS issues/attacks, not loss of coins.  On the upside, having that as the default mode for a fresh install would bridge the interplanetary-sized gap between Armory and new users (and users with less resources).   I'm going to think about that one...

By the way, I finally spent the time to figure out how to make a custom QRCodeWidget:



I've got some work to do the clean these up and then I can start putting them all over the place.  Right now, the places I can think of are: get-new-addr window, address properties window (from wallet properties), payment-request/clickable-link URL, and menu-based address book [the one where you're just browsing instead of selecting])

I kind of wish Satoshi had just named these units himself.  "I decree that we will use these names for the different units."  Even if they weren't good names, they probably would've stuck, just like everything else in this system.  At least there would be a baseline to refer to if there was some decision to deviate.  Then we wouldn't need any more discussion about what to name them (since no one can agree since it's so awkward having 8 decimal places).

I'm under no illusions about the limitations imposed by the RAM usage.  At the moment, Armory is a power-users tool, and it is still serving its purpose even if less users can access it (I'd rather have a toll that provides unique capability to 60% than one that provides the same thing every other program provides, to 100%).  I definitely will get to the [final ] RAM-reduction step, but it turns out that my half-step between here and the full solution was more like a 95% step.  In that case, I might as well just do the full solution and skip the partial solution that would be obsoleted by the full solution anyway.

Besides things like QR codes, my top concern is making multi-sig useful.  With the new wallets, I will be able to setup linked wallets, and make interfaces for creating and storing complex transaction types.  Strictly speaking, the new wallets weren't necessary for this purpose, but there's about 20 things fixed at once with the new wallet design, and this feature is on that list.    Even if usage is limited by the RAM requirements, some people will use it and help me improve it... while I work on the RAM-reduction

Yes!  On my whiteboard behind me (with my ToDo) list, I have a "QR Code Marathon".  Basically, I need to look something up before I can implement it, and that one thing is probably stupid easy, but it's been preventing me from feeling like dealing with it for the last couple months.  And there's like 10 places I wanted to use them....

I'll bump that up on my priority list.  It definitely needs to be done.

OKAY!  I think the bounty system is working.  I have paid out about 21 bounties of 0.1 BTC each, and another slightly bigger bounties for helping me fix things.  A special thanks to subSTRATA who went on a marathon clicking spree and vacuumed up most of those bounties.  AND I got around to fixing some other things I've been meaning to fix for a while!  Most importantly:

• Changed the "Imported" column in addr list to show order-created (or "Imported", as appropriate).  Includes sorting.
• Create Clickable Link / Request Payment to Address now has a working "Copy to Clipboard" button.  It turns out that when you copy HTML to the clipboard, you need a <meta> tag prefix to help the receiving app know what's up.  In this case, it was <meta http-equiv="content-type" content="text/html; charset=utf-8">.
• 19 other bugs/suboptimal features!  Mostly:  more descriptive errors/warnings, catching empty entry boxes, strange behaviors with some sequences of events (like changing wallet labels and then backing up individual keys resulted in unprintable 0x00 bytes in the output), etc.  Should be a smoother experience overall.

It's super late, so I'll compile windows versions tomorrow.  But I might as well let the non-Windows users get cracking at the "testing" branch and let me know if anything strange pops up.  Especially look at the two new features above.

---

I've also been tackling the new wallets at full speed (before this bug-fix marathon tonight).  It's turning into a massive effort, but it's also turning into something pretty cool -- the new wallets are going to be highly flexible, extensible, and hopefully somehow not overly complicated at the same time (is that possible?).  I don't know, but at least Armory will be able to use it for some cool features!  But it's probably still a few weeks away before I can get a unit-tested version safe for public testing, and will probably be missing some more advanced features (like chain-code encrypted label/P2SH files that can be safely put in dropbox for persistent backup).   Most importantly, it's setting up everything I need for linked wallets, so I can do two-factor auth with desktop and phone.   Just don't hold your breath for it...

Just a random update:  I was updating the top post and want a check on my math for the question:

"In a post-Reiner-Tree world, how much data must a lite-node download to know its balance and spend its coins, from scratch?"

Okay, so, I will assume a wallet has 100 addresses each holding 2 UTXOs and no information/history. 

Pre-Req: Need the headers for the main chain and meta-chain:  meta-chain doesn't exist yet, but let's assume this is 2 years after implementation of meta chain (assume starting now).  There will be about 24 MB of main chain headers, and 8 MB of meta-chain.  Total:  about 30 MB.  (NOTE: If this is eventually integrated into the main-chain coinbase headers (at the risk of invalid blocks if it's wrong), then there is no extra data to download.

Also note, this data may simply be bundled with the app, so it doesn't really feel like a "download" to them.  It will be longer to download the app, but start up basically instantly.  For the remainder of this discussion: I assume that we've already downloaded the headers.

Balance verification info:  Before you even download your own balance and UTXO list, you need to collect and verify the tree information pointing to your addresses.  Once you have that, you can download the data itself and know you got the right thing.

Here I assume d'aniel's idea about merkle trees at each level.  That means the for a single address, I need to download 15 hashes at each tree level to verify that tree-node:  480 bytes per node.  For efficiency, I'll always just download all 256 hashes at the top level (8kB) and the 480 bytes at each subsequent level. 

I assume that the network is "big", with trillions of UTXOs, thus having to go down 6 levels to get to my address.
I assume that all 100 addresses have a different starting byte, maximizing the data I have to download by not sharing any tree-nodes below the first level. 
So the amount of data I download is Top Level (8kB) + 5 more levels (480 bytes * 5 levels * 100 addresses).

Total verification data:  ~250 kB

UTXO data itself:  After you get the verification data, you need the actual UTXOs.  We assume 100 addr * 2UTXOs = 200 UTXOs.  Each UTXO consists of its 36-byte OutPoint followed by its value (8B) and TxOut script (~26 B).  So 35 bytes/UTXO * 200 UTXOs = 7 kB.

Total:  30 MB for header data downloaded once.  After that, you can throw away all wallet information and re-download on every application restart for 250 kB/100 addresses.

As I look at this, I realize that this is pretty darned conservative:  since the individual tree-nodes are compressed, the last 2-3 levels will require only 3-7 hashes each, not all 15.   So probably more like 150-200 kB to 200 UTXOs.

Am I neglecting anything?  This seems pretty darned reasonable!

You should really think of "message signing" as exactly what it sounds like: you putting your "approval" on a message.  "Proving ownership" isn't exactly what you do with signatures -- you should sign messages that you agree with.

Don't:  "To verify your identity sign this string using address X:    "x83jkflj432jlkjsjfwe"
Do: "You have requested that operation <Y> be completed, please sign the following message "I submit approval of operation <Y> on 18:43 EST Jan 2, 2012 and all rebates should be sent to Address <Z>"

You're not "proving ownership", you're proving that the person in control of that address agrees with the signed message.
Never sign anything that isn't has any ambiguity about its meaning.

I've actually made that suggestion directly to the operator -- I already told him that 250 BTC bets are insane given the apparent bankroll (well, it was when the site only had 2k BTC profit, but even at 30k it's "high").  But not separating bets out using TxOutIndex lets someone change the effective bet-size to far more than 250 BTC.  It would be quite scary (for SD), to see their entire profit disappear in a day because someone was able to makes bets in excess of 4% of the entire site's bankroll.

So, he responded saying he'll investigate what it would take to make the change... apparently they haven't taken it too seriously, yet... but maybe these ridiculous swings will change their minds.