Interesting... haven't seen that one before.  Perhaps I just need to bump up the time that Armory that waits before declaring that it failed...

You were told it wouldn't broadcast when you created it?  Or when you tried to actually broadcast it (you were able to broadcast it, it showed up on the ledger, but said it failed?)

Just a quick update... I'm on the absolute verge of the "real" release, with all the features completed for beta.  The issue is that restoring paper backups and importing wallet files, sometimes causes Armory to hang, and I've spent my whole day trying to track it down.  Unfortunately, it's not consistent, so I still haven't even been able to isolate where it's hanging.

On the upside, it hangs after it's done doing the wallet recovery scans, so it's okay once Armory is restarted.  I just can't release beta like that...

When I do find it and fix it, I will go into "pencil's down" mode and focus on testing.  A lot of testing.  And I will need help. 

---

Reposting the downloads for 0.84.1, because I'd still like people to help test that if they can.  I don't know how long it will take to track down this wallet importing, but bugs found in 0.84.1 are still relevant to 0.84.2 and I can fix it before I release.

Armory 0.84.1-almost-beta

Ubuntu/Debian 64-bit (*.deb)
Windows 64-bit (*.msi)
Windows 32-bit (*.msi)

Yes, there were other problems with the transaction beyond simply accumulating signatures.  But the point is, it would be nice if things didn't just fail cryptically, or if it could be avoided altogether.   The avoidance solution is more of a software thing, but perhaps the device should recognize when its own limits are about to be exceeded.

And, in posting about this in another thread, multiple users mentioned that they were likely to run into the same situation.  I bet businesses will run into it a lot -- your offline wallet is really intended for collecting, not spending.  A lot of people will collect money to the offline wallet for months before they decide they want to do something with the money.   And, if a business uses offline wallets to serve their 500 customers per day, then they'll be trying to execute one of these transactions each day!   Or a much larger one once a week.  I've been thinking about making a special warning message in Armory for this, with recommendations about splitting it into multiple transactions... but I haven't acted on it yet. 

Fair enough.  It's actually more consistent your way, anyway.  I was just concerned about users plugging in their device and having the key maliciously overwritten, but it sounds like you got that covered.

---

Also, I just mentioned this to someone42 via PM, but I want to throw it up here -- I recently got a bug report because someone was having issues signing a transaction that had 483 inputs !?!  The transaction itself was 120 kB, and the supporting transactions to be transferred to the offline system was a couple megabytes.  I hadn't really realized that such huge transactions were "feasibly likely", and it might be worth thinking about how to deal with that situation.  If you can handle signing 500 inputs and the RAM and bandwidth to push that much data around -- great.  On the other hand, some transactions just shouldn't be possible (500 kB+ won't ever be accepted by the network).  Maybe it's more of a software issue to prevent that... but I wanted to throw it out there as a corner case that should be considered.

I recommend the hardware switch because you don't want to make it too easy to overwrite the current master seed in the device.  In fact, you don't want malicious software on your desktop to be able to issue the overwrite request without your permission.  Having a user confirmation perhaps solves this, but does make it subject to user error, and especially dangerous for users that don't back up their seeds.   Personally, I would prefer a HW switch and maybe even require a screwdriver to get to the switch, since it will be used so infrequently...  but I can understand not wanting to do it.  Just more food for thought.



Yeah, I was inelegant in my phrasing, and that's exactly what I was suggesting -- no custom addresses, and only pulling off the master public key.  I wasn't sure if you were allowing the public key to be accessible from the device

However, in my own thought-experiments, I thought it was a good idea not to even allow access to the public key through the device (or maybe provide an option to not store it).  The reason is -- if it's actually really difficult to get the private key off the device, and the thief doesn't actually know how much money is protected by the device, they have a lot less incentive to try to break it.   If the public key is accessible, they know exactly what their reward will be breaking it.  But there's a lot of versatility advantages to letting it spit out the master public key...

FYI, I've been meaning to talk to sipa about unique wallet identifiers, but haven't yet.  In the current incarnation of Armory wallets, I had used a combination of the root address and the first address after it to create a mostly-unique 6-byte ID for the wallet.  This was so that a given combination of root seed and chaining algorithm would have unique IDs.  Chaining algorithm doesn't have to be part of it with standardized BIP 32 (maybe just food for thought)... but I think it is appropriate to add an identifier scheme which would solve your problem.

After talking to Jim via PM, I wanted to clarify and expand a point about my recommendation for a hardware switch to upload wallets.  I think it should be considered:

1.  (clarification) The ability for the user to upload keys does/should not have to be the only way to use the device.  But simply one of a couple different options for initializing the device.  This accommodates all types of users, especially pursuant to my next point...

2.  (extra point) As we know, Bitcoin users of all backgrounds have a tendency to not trust anyone or anything but themselves.  For this reason, they may not be inclined to trust this device that could've been malciously designed, or tampered with to produce keys that can be predicted by someone else.  However, if they can use any application of their choosing to upload their own source of entropy, the device would have no choice but to use the user's trusted entropy instead of its own.  Not to mention that users doing this would be much better prepared to create paper backups and watching-only wallets.   

In the absence of the device communicating the private keys out some side-channel, this makes the device trustworthy to a much wider base of security-focused users.    Yes, some users would use the built-in entropy generator.  But there are plenty of users for whom the extra key-input channel would improve both security/confidence, as well as convenience (to make backups and watch-wallets).

By the way, I already started implementing BIP 32 in the "newwallet" branch of Armory.  I didn't realize anyone else was looking at it, yet.  I have some HMAC and CKD unit tests in Test_HMAC() in BlockUtilsTest.cpp.  I was waiting for sipa to get back to me with his results, but so far no one else had implemented BIP 32 to measure against.

Armory won't have BIP 32 supported for a bit, but it would be nice to iron that out before I continue with my new wallet implementation.   (it sounds like there's no hurry)

Please keep me in the loop so that I can help accommodate users who want to use this HW with Armory.

Are you not interested in being compatible with Armory?  Or rather, getting Armory compatible with it?   Armory offline wallets basically already do this, they just require bigger hardware (laptop), and less secure transfer method (USB transfer using bulky operating systems).  I always wanted to expand to dedicated hardware just like this, but my hardware skills are nil.

I'll offer my advice anyway, even though no one asked for it:  there are lots of ways to do this kind of device, but there's one mode of operation I think it should have:  the device has a hardware switch on the back behind a little door that is accessible, but impossible to flip by accident.  The switch allows for uploading new wallet data.  Data that is uploaded to the secure chip is not downloadable -- it's a one-way channel. 

The user creates their full wallet using Armory/Multibit/Electrum on a temporarily-offline computer (live session), they print off a couple paper copies, create a watching-only copy, then they flip the switch to allow uploading the wallet to the device.  Copy the watching-only wallet to the online computer, stash your paper copy in a safe-deposit box, and then flush the original copy on the computer by rebooting.  Now you're ready to go.

There's other modes of operation to consider, but I think the flexibility of managing the wallet initially from a laptop/desktop is ideal.  This gives lots of options for watching-only wallets, making address lists, etc. 

The device could also have a separate memory bank for downloading the watching-only wallet from it.  This isn't ideal, since it tells an attacker how much money it's protecting (if they didn't already know), but it provides excellent versatility.  Maybe not the best idea, but good food for thought.

This stuff is already available in Armory, it just uses a different wallet format and data transfer format (BIP 10).  Theoretically, if you adopted both, it would work with Armory right now, and you'd have the rest of the cold-storage software infrastructure completed already.  Of course, standardizing on BIP 32 is the path forward, and Armory will be implementing that...  Also, I've been seeking people to help design a new BIP 10, so maybe you'll be inspired to help.  You need to make sure that you accommodate multi-sig transactions, too ... make sure the transfer protocol accommodates pushing P2SH scripts, and the device knows how to sign them.

Oh!  What about mempool.bin.  It's possible for that to be corrupt, too.

Because that is such a common cause of crashing, I put logic into 0.84.1 to detect when Armory fails to load more than 3 times, and automatically delete mempool.bin.  Even if that's not the problem, perhaps you can check for me that it is at least detecting it.

(1) There's a new entry in ArmorySettings.txt called "FailedLoadCount".  That should be incrementing every time it crashes
(2) The log file will eventually start reporting "<X> attempts to load blockchain failed.  Removing mempool.bin."  It should happen every time after the third failed load.

Can you at least check for me that it is doing that?  Though, if it is doing that, then it is removing mempool.bin, and there's nothing more for you to try.  So far...

You know what?  I bet there's a problem with one of your wallets.  One of of them is corrupt, maybe? 

Can you temporarily relocate your wallets out of the .armory directory and then reload?  I bet it will start, then.

New testing release:  Armory 0.84.1-almost-beta

Ubuntu/Debian 64-bit (*.deb)
Windows 64-bit (*.msi)
Windows 32-bit (*.msi)

This is definitely not a perfect release.  But most of the issues are aesthetics in windows.  The little "busy" icon does not even show up while the blockchain is loading.  Windows XP was lightly tested, but I'm relying on you guys to help me with that one!  

However, I think I quashed the bug causing crashes when new blocks come in while scanning.  If you do experience the crash, just restart! (and then report it to me)  I added a manual-entry window for "bitcoin:" URLs, in case Armory doesn't properly register itself with your OS (you'll see it on the send-BTC dialog).   And I did some more polishing...

Please try it!

Are you running it from the command line?  Does it get through blockchain loading then crash?  Mid-loading?  I wonder if it's a wacky set of blkXXXX.dat files, which has turned out to cause issues in the past.  But since those blk files are so damned big, I can never get anyone to send me one so I can debug it

Speaking of that, does it work in --offline mode? 

If that works, sounds like a scan issue.  I know it's a pain to redownload the blockchain... but if you are feeling generous with your time/bandwidth, could you rename your blk files and redownload and see if that solves it?  If so, I can open the guest acct on my system for a night for you to scp the blk file with the problem.  Not there yet, but I am getting frustrated by this...

Hold off on that... I'll give you a version that has the blockchain-loading bug fix. 

In fact, it's already committed.  Try it.

Just an update:  I got heavily distracted this week by the election, and then some intensity at work, but now I'm back to my every-Friday-off-to-work-on-Armory (what I promised from crowdfunding back in March... I'm still doing it!). 

I was planning to tackle this bug I confirmed the other day, but now I can't reproduce it!    I'm trying to slow down blockchain loading on my system to trigger it, but it's not where I expected it to be.  At least, I'm doing some other productive things while I wait...

I have two major bug fixes to do before 0.84.1: 

(1) this bug to do with new blocks while loading blockchain,
(2) slow processing new blocks with large wallets (there's no reason it should take 10s to scan 1 new block, when it just scanned 200,000 blocks in 40 sec)

Then hopefully some more polishing and minor feature updates.  I'm thinking of adding a raw-transaction-broadcaster, too (expert interface).  Any demand for that?

---

Anyone here still testing 0.84?  It appears to work fine if you get past blockchain loading, making it still usable for testing.  Anyone have any more comments about it?

---

Finally, I just started filling out a Frequently Asked Questions page on the Armory website.  I've decided to take my own shot at describing Bitcoin despite the excessive number of descriptions already out there, but I won't be offended if someone thinks there are better introductions to it. 

This FAQ page will be linked from the first-load screen when users first install Armory.  So, I'd like that page to be useful, and simple.  I have a short list of questions that will be added (I'm not done, yet), but feel free to recommend more.

FYI, I previously posted on this topic, finding that  block 125,552 had a hash that would've been valid at 36,000,000,000 difficulty.  Apparently block 125,552 has finally be dethroned...

You are right, there is no alternate chain for change addresses.  It is possible to end up with accidentally re-using an address once, especially if your server is very active in giving out addresses.

However, in version 0.82 I added a new feature to the Expert interface (in the GUI) that lets you specify the change address to use.  It allows you to send change back to the first input address (may be better than the alternative), or you can supply your own address.  You can't specify another wallet yet, but I want to allow that, eventually.

However, the new wallet format that will come after beta, is based on endless discussion with Pieter Wiulle (bitcoin-qt dev), and that will result in wallets, by default, having two different subchains for each wallet -- the second chain will be used solely for change.  The new wallet format is a ways off (hopefully Beta isn't!), but it is coming.  For now, it sounds like switching your desktop to Expert usermode is your solution.

Thanks for that picobit.

While I don't know much about OSX, I do want to point out that I removed the BSDDB dependency in Armory.  So the steps that involve configuring and installing that can be removed.  It was because the BSDDB was only used for migrating pre-0.6.0 Bitcoin-Qt wallets, and those have been "out of style" so long that I finally removed the feature altogether.

Maybe it's okay to leave those steps, since I might add it back in one day.  But if someone is getting stuck there, they should know that it's unimportant.

I should've stated that differently -- it's not impossible to parallelize general BSTs, etc, but since we are dependent on the underlying structure of the BST (which is not a normal requirement of BSTs in other applications), insert order must be strictly adhered to, and thus each insert operation must be completed in order before the next can be applied.   By definition, that is a serial process.  Along with that, sub-branches of the BST are not independent, so it's more complicated to even have the storage space split up, since rebalance operations may shift nodes from one thread's storage space to another.  It's not an impossible task, it's just an unnecessarily complex one.

And I have a tough time believing that no one in the future will ever benefit from sub-tree independence:  with the BST, lite nodes can't even maintain their own little sub-trees for their addresses, because the structure of that subtree could change due to unrelated inserts nearby.  Or, the subtree could induce a rebalance itself, and change the root of the subtree that has to be tracked which may include other nodes it doesn't care about.

With the trie structure, sorted first by address then by OutPoint, a lite node can maintain sub-trees of each of its own addresses, insert and delete elements in any order, and roll back its subtree on reorgs without having to care about anyone else's OutPoints.  And all using simple, standard insert and delete ops, found in any textbook on the subject.

But, I have to agree that the first implementer of this stuff is likely to set this standard.  I was hoping to persuade the folks who are working on it now, that the trie structure is not only the simplest, but the most flexible and robust.  Apparently, I'm not succeeding.    I better get back to fixing Armory so that maybe one day soon I can work on this problem, too