I noticed this little # symbol in the lower left corner of the transaction window. When I hover over it, it expands and tells me where I am in the list. Is this meant to be just a debug thing that should be taken out before final release of 0.93?



Yep, truly impressive, even when loading a supernode from an HDD.

So far, so good. But then, maybe I've just been lucky?

0.92.99.3 fullnode on Windows 7 here. Armory is fully synchronized, not apparently doing anything, but the CPU usage averages about 22-24% of a core (6% total), whether the Armory window is visible or not. It did not do this in earlier versions (certainly not in 0.92, and I don't think it did it in 0.92.99.2).

I had issues (i.e. a crash) with it building the db for a supernode earlier, but I know that I don't have the very latest version (waiting for a Windows build), so I won't repeat that.

0.92.99.3, the text below "Armory is disconnected" has a broken tag, "br>", visible.

Yes, unconfirmed txouts can be spent. With the understanding that complications like double spends and transaction malleability mean that those two transactions may not end up in the blockchain as you expect.

Miners can include and exclude whatever transaction they want from the blocks they mine. If they want to build upon previous blocks, though, they have to accept the whole block as-is.

What this means in practice is that each individual miner has very little control over what ends up in the blockchain. Even if e.g. the top 80% of hash power decided to exclude your transactions from their blocks, that'd just mean you have to wait 5 times as long for your first confirmation. Unless they're willing to reject blocks that contain your transaction; this could be a sort of 51% attack, but it's only effective if the colluding miners control >50% of the hash power.

You need to update the block header after every hash to change the nonce, and at least every 4.2 billion hashes when your nonce value hits its maximum. If mining software doesn't already keep the timestamp within, say, 5 seconds of the true value, it could (I'm almost certain) easily be modified to keep it at the right time without significantly affecting your hashrate.

You will, of course, broadcast it immediately upon finding it; you can guess that 50% of the network will get it in 4-5 seconds, so simply set it 2:00:05 or so ahead of your very-accurate "current time".

(Armory 0.92.99.2 supernode) Attempting to sweep the private key 5HpHagT65TZzG1PH3CSu63k8DbpvD8s5ip4nEB3kEsreAnchuDf (listed at http://directory.io/). The window shown here opened itself rapidly many times:



Until there were enough open to cause Armory to crash:



This was repeated in the log file 43 times:
2015-01-16 07:15 (INFO) -- ArmoryQt.py:3523 - finishSweepScan
2015-01-16 07:15 (INFO) -- ArmoryQt.py:3404 - createSweepAddrTx

This is part of why increasing the maximum block size is a very good thing, IMHO. Let's say blocks were averaging 500 KB before the dropoff. If we're limited to 1MB, your scenario will play out: unconfirmed transaction pool grows and grows, people have to pay higher and higher fees to be put at the front of the list (this would incentivize more miners to join, but it would take a lot of fees to even be noticeable compared to the block reward), etc. until the difficulty can adjust two times. If the limit were already sitting at a max above 5 MB, then confirmation times go up, but transactions still make it into blocks in a timely fashion.

The same thing happens when adding/removing the encryption from a wallet.

I found another bug related to changing ownership: the tooltip on Security doesn't update immediately, it updates whenever you close and reopen the window. Here are two images with it showing the wrong tooltip due to this bug.



Also, the images show that Armory thinks 2 addresses were used by this wallet, though 3 really were (all 3 have had 1 tx sent come in to it, no txs out).

Is the "ignore list" option meant to be disabled when deleting a wallet? Why is it shown at all?

My supernode database file is 85.2 GB. This is 2.6x the size of the old Armory DB. Is this size expected? Can someone report the size of the new Armory's fullnode DB size? (I'd imagine it doesn't vary significantly from machine to machine)

85.2 GB - new Armory supernode
32.9 GB - old Armory fullnode
31.5 GB - Bitcoin Core
26.6 GB - raw blockchain

No, it was set to My Wallets. I have a correction: there's still something wrong, but it's not what I reported at first. Immediately after changing a wallet from Watching-Only to Offline (i.e. specifying that I own it) while My Wallets is selected, the transactions don't appear in the Transactions tab and the balance of that wallet does not show up in the Maximum Funds, etc. balances in the lower right. I can force them to update by modifying the Filter selected on the lower left.
The reverse also occurs: a change from Offline to Watching-Only is not immediately reflected in the transactions/balances.

(using 0.92.99.2 now)

Adding a wallet on my supernode instantly shows the balance in the Available Wallets pane and the transactions, as expected (woot woot! The wait almost feels like it's worth it to see that ). However, the balances in the lower right are not immediately updated. I can force them to update by modifying the Filter selected on the lower left. I can email screenshots documenting this if needed to clarify (for privacy reasons, not posting it publicly).

Armory has finished scanning transaction history! The dialog announcing that seems to be responsible for crashing Armory, though.

I saw the dialog saying "Blockchain loading is complete." etc. I didn't check the box, and I clicked Ok to close it, and noticed Armory was no longer running. No error in the logs, logs not even updated in several minutes.
The next time I tried to start Armory, I didn't see that dialog, the Armory window opened, and it crashed with the same sort of nondescript error window shown here: http://imgur.com/a/t63L7
I tried to start Armory a few more times, and each time it crashed after I clicked Ok in that dialog. So I checked the box to not show it again (I think it crashed one last time here), and opened Armory again, and it worked this time: I can view balance, all seems well. Sending my logs to contact@bitcoinarmory.com right after I post this, in case it helps find the problem.

It's difficult to say how many human miners have given up. But if what you're really asking is how much hash power has dropped off (which is the most relevant thing here: is the block chain stalled, or is it progressing like usual?), that's an easy question to (approximately) answer. Just look at the chart at https://bitcoinwisdom.com/bitcoin/difficulty. While it's lower than it was recently, the hash power is still enough that the seconds per block is about 640 (target is 600), not stalled at all.

Also, an update on the transaction scanning: I moved it from my HDD to SSD and now the estimate is 8 hours, and disk IO is about 30-80 MB/s. Maybe there's a lot of random access going on, not just linear access? That would explain why it's running so much faster, even though my HDD's linear access is much higher than 1-3 MB/s.

During the transaction scanning of my new supernode, if I close Armory, it attempts to shut down, then crashes. http://imgur.com/a/t63L7
The logs don't record any errors, just that a stop was requested:

I don't think I've ever seen leading zeroes on hexadecimal used in the way you describe. "0x" is the usual prefix to show it's hexadecimal, or if you're filling out 1 byte (2 hexdigits), you include a leading 0 on 0-F, not just A-F. If I saw a leading zero on an otherwise-ambiguous number, I'd assume it's octal (base 8​).
https://en.wikipedia.org/wiki/Hexadecimal is a good resource.

It is possible to assign a bit value to permutations, but I couldn't tell you exactly how to do it. You can't assign bit values directly to cards (at least in the way I'm thinking), because 52^52 > 2^256. It is very similar to Project Euler's Problem 24. By analogy for a 3-card deck: assign each permutation a number value.
1: 012
2: 021
3: 102
4: 120
5: 201
6: 210
Represent this as a 3-bit value. That's your private key, with ~2.6 bits of entropy. This analogy can also show you why a straightforward conversion like "represent each card as a base 3 digit in the number, then convert to binary" won't work: 222_3 = 26, which would require 5 bits to store in binary, not just 3.