By the way, if you change address comments, I want the ledger to update all the address-relevant transactions appropriately.  That's why I prefer it be dynamic.


If you double-click on the comment field in the ledger, it will set the comment just for that tx.  Same with the address list in the wallet properties.  If you double click any other field, it will show you the transaction details (or address properties).  Maybe I should add a button to the tx details dialog to let you change the comment right there, for those that didn't notice the comment updating directly.

I have had a few requests for a search function.  It makes a lot of sense, so I will consider that for the next round of updates (it shouldn't be hard).

That's my address   1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX

The problem is not length, it's how specific of an address you are looking for.  There are about 58³³ possible address, so if you want to find a very specific one (such as 1BitcoinEaterAddressDontSend..), then you have a 1/58³³ chance of finding it on each guess (infeasible*).  However, my address was not a search for a single address, it was any address of all capital letters.  There are about 26³³ such addresses.  So the chances of finding one such address on each guess is 26³³/58³³ = (26/58)³³.  That is actually in the realm of feasibility -- it is about 1/300billion

*  1/58³³ = 1/15599970876632771988160814054146447252125923204784443097088

Awww crap.  I forgot I had to mess with that in order to not have a ridiculously slow ledger when you have thousands of transactions (as you do).  I never quite figured out how to resolve it, and then promptly forgot about it!  The issue is that the comments are dynamically retrieved, because transactions that don't have comments will still display the address comments if there is one.  The sample wallet I had consisted of a lot of tx with hundreds of outputs each, and the search was taking like 2 seconds per operation (w/ GUI freeze).

So, what's the solution?  I'm not exactly sure...

One thing I can do, is sort by tx-specific comments first (which is very fast), then only display address comments on the page shown.  This may look weird -- some fields will appear to be out of order.  But you're probably looking for tx-specific comments, anyway, which will be sorted.  I guess I could also look into supplementing the data somehow to improve the efficiency.  It's a kind of frustrating problem because the slow version works for 99% of users, but is a terrible experience needing to be addressed for the other 1%...

Fantastic!  Now I have SuSE, Gentoo, Ubuntu, Fedora (somewhere).  Maybe I'll start a list of such instructions on the website.  

Two things:
(1) I don't think you need ".so.1.0", I think ".so" is sufficient (since it's just a symlink to .so.1.0, probably).  
(2) Everyone can avoid the Makefile modifications if I could just figure out how to autodetect the .a file, and switch the .so file if the .a does not exist.  Unfortunately, my bash scripting is garbage (my failed attempt is commented out in the Makefile).  Perhaps someone with more bash experience could just fix it for me and then I'll update the repo with it.

This is the biggest "hurdle" for people compiling on non-Ubuntu systems, and I could make it go away if I just got the bash commands figured out.  Then your compile instructions would pretty much be the same as I already have on the webpage.

Anyone want to help with that?

Well, what are you waiting for?  It is real, right now!  "Beta" in this case, actually means functional, stable, and with a complete set of features (not all the features I ultimately want, but enough to use as your primary app).  There's a few lingering bugs, but most are aesthetic, and as long as you create a paper backup you can't lose your coins -- but the wallet code has been in use for 10 months now, and no one has had a problem.

Getting past beta means Armory will have multi-signature tx support, a sister Android app, reasonable system requirements, and full support on OSX.  But, for a majority of users right now, none of these are a problem (most users have sufficient system specs, and OSX users have generally succeeded with RedEmerald's install instructions).

Hi Gyom,

I would do this for you, though I do agree with above that you might be better off saving your money and just putting your questions on the forum -- you will get a lot of great responses, especially in this subforum (a lot of smart people lurk in the D&TD forum).  Or, if you just email me questions, I have a tendency to write elaborate responses for free!      (etotheipi at gmail dot com)

Also, if the questions are deep/specific enough that you can't find the answers here already, it would be educational for others to have the Q&A documented here.

I'm ten steps ahead of you    I already talked to the Bitcoin-Qt devs and got the info, and accommodated it in the code.  You'll see in the 0.85-beta version notes "Preparation for Bitcoin-Qt 0.8+".  It was kind of a pain, because, Armory has to accommodate both pre-0.8 and post-0.8, so I had to autodetect the files and select the correct one. 

For reference, the current structure is that blocks are stored in ".bitcoin/blk1234.dat" of 2GB each.  0.8 will put them in ".bitcoin/blocks/blk01234.dat" of 128 MB each (now zero-indexed, and five digits instead of four).


I believe the issue has to do with Armory shipping with it's own python27.dll.  If you switch between the 32-bit and 64-bit, I think the installer sees the .dll already there and doesn't replace it, not realizing it's leaving you with an incompatible dll.  If you uninstall-reinstall, or "repair" the installation, I think it should work.  Please let me know if that's not the case.

I just wanted to add to this discussion that Gavin once mentioned a very interesting concept:  Bitcoin escrow.  Not the fact that it exists, but the fact that an organization can have partial control over coins through multi-signature transactions, but not enough for anyone to declare they are "in possession" of those coins.  He suggested that this would be legally significant in terms of money handling licenses. I don't know if he was speculating, but it's a relevant concept to consider if it were true.  Basically, it would exempt certain types of services, and businesses might be able to change their CONOPs (concept of operations) to get such exemptions.

I know I'm a little late, but I finally released Armory beta.  Try it out, and please consider it for the next round of BPM!

Exactly.  More explicitly: let's say I were to magically disappear and there was never another release of Armory AND Bitcoin-Qt changed in such a way that Armory didn't work anymore.  What do you do?

• (1) Fire up the last version of Armory you have
• (2) Go into your wallet and click on "Backup Individual Keys"
• (3) Copy and paste your private keys into any other program or service that let's you import keys (blockchain.info is one)
• (4) Continue using your Armory addresses from that other program or service.

So, there is no risk to your funds if I were to disappear -- you would just have to export all your keys to another app.  

And as RE said:  the question about security is really a risk of any program.  If Armory were designed poorly under-the-hood, it may be more susceptible than other programs.  I'd like to think Armory is far above average.  One thing users could do is donate to pay for third-party security auditing of the Armory code.  Even if it were to turn out that there was some problems, the audit would identify them and I could fix them.  But, as far as I know, I've followed most good practices for secure software -- making sure unencrypted data never touches the disk, using well-established encryption techniques, sufficient key-stretching, passing around private keys in RAM using self-destructing containers, etc.

Bugs are also a risk with any program -- especially financial software.  But two things about Armory in this respect:

(1) There's redundancy:  make a paper or digital backup, and you're protected against the 99% most common type of bug:  wallet corruption (or HDD loss)
(2) I have 1,000 lines of unit-testing (unittest.py) just for Armory wallets.  And it paid off: in the last 10 months, that code has hardly been touched because it's so stable and does what it's supposed to.

I hope you can sleep easier, now

Nine months later, Armory is now Beta!  Check the top post for details!

That's an interesting observation on its own.  I'm not sure why HDD stress would cause networking hiccups.  Does it also cause Armory to crash (eventually)? 

However, I'm not convinced that is the source of the crashing problem.  I'm fairly confident that there is something else (i.e. a inf loop bug or something) causing readBlkFileUpdate() to take longer than 10s.  It just doesn't seem possible, even with a ridiculously slow HDD, that it would take more than 10s to read a few kB from disk.

Sorry, don't mean to discount your observation -- I do need to fix stupid networking problems like that.  But my gut tells me there's another, subtler issue...

Thanks Gavin, that looks great -- albeit big, and might take me a while to figure out what to do with it.  But anything helps!  Especially if it already includes Qt (but I'll need PyQt, too).

---

@RedEmerald

I just tried the git tag signing, and it worked flawlessly.  I don't know why I didn't do this before...


That should confirm that the tag is signed by the "Armory Signing Key."  About to do the 0.86-beta release, with CoinControl and the double-tx bugfix.

I'm not sure how that's possible... if it's in the blockchain there's no way to not detect it on a restart.  Unless Bitcoin-Qt isn't fully synchronized.

To be clear, mempool.bin holds only zero-conf tx.  The zero-conf tx is deleted when the same tx is included in the blockchain.  If you delete mempool.bin before it makes it into the blockchain, then the tx won't show up at all, until it has 1+ confirmation.   So if it doesn't show up at all, then... are you sure it made it into a block?  Do you have access to the txid in order to look for it on blockchain.info.  I'd be very surprised if the tx is in the blockchain, is relevant to any your wallets, Bitcoin-Qt is sync'd, AND it doesn't show up. 

I guess an alternative explanation would be something to do with your wallet not recognizing that the tx is relevant to it:  perhaps if somehow your keypool wasn't big enough... did you generate 100s of empty addresses before this one?  However, expert mode now lets you extend the keypool manually.  I doubt that's your problem (especially because the tx showed up before, but it's worth trying if all else fails).



Hmm, I've never seen it happen in linux.  I guess my HDD just doesn't get overwhelmed like that.  However, the disconnect-reconnect fluctuations are a symptom of the problem, not the cause.  Perhaps I should add a mechanism to disable the flickering if there's too much...

The real problem is why it's taking longer than 10s to do something that normally takes 0.2 ms.  My guess is it isn't a "legitimate" failure (HDD taking 2500 times longer than normal), it could be an infinite loop in the readBlkFileUpdate method, or it's somehow inducing a rescan when it's only supposed to be doing a quick update.  The debug output should tell me the last line that was run in readBlkFileUpdate, and also tell me the state of a bunch of different variables at that time.

prezbo,

Are you compiling from source?  I just put the BlockUtils.cpp with debugging calls in my dropbox folder, and it can be copied right into the cppForSwig directory and recompiled.  It's a P.I.T.A. to debug this stuff, because I can't compile in MSVS in debug mode (because I get crazy linker errors for things like not having python_debug.dll, I haven't figured it out, yet), and I can debug in Linux, but the error doesn't seem to happen there.  

So, the best I can do at the moment, is have it spit output to the console every other line, to find out where the problem is (and the state of some variables when it happened).  I might be able to figure it out just from the output... at the very least I can do more intelligent debugging when I figure out the location.  I am putting it out there right now, because I just ran it on my Win7 VM for 36 hours and it hasn't crashed yet...

---

I found and fixed the bug causing double-display in new wallets.  That's a particularly important bug to fix with the recent influx of new users.  That along with coin control is worth a full release, even without this once-per-24hours-crash bug fixed.   I am in process right now, of compiling and signing the installers.  I will also see if I can get git installed on the offline computer and sign the "v0.86-beta" tag, too (after I create it).

I also figured out why so many users were having trouble with the installers in Windows -- I have been trying to push people onto the 32-bit version, and I think when it installs it skips files it thinks are already there -- including things like python.dll which is 64-bit but then replacing everything else with the 32-bit version.  This is also why a repair/reinstall always fixes it.  I'll see if I can figure out how to force the installer to replace everything.

@Ente,

One other thing I could use is more testing.   I really haven't been getting the quantity of eyes on testing versions as I need to catch all these crazy things.  A lot of silly bugs get by me because I can only test such a small subset of everything.

On that note, I just figured out the tx/balance doubling bug:  it is only when you have freshly created a new wallet and receive coins.  It's because the wallet is somehow getting added twice to the application.  I think I can fix that bug and put it into a 0.86 release.  This seems important to fix for new users getting into Armory the first time...

Thanks Ente:

(a) There are no updates on that yet.  If you have the private key, can you import it into the offline wallet and re-create the watching-only wallet and re-import that on your online computer.  Also, even if I had the pub-key import feature, you can't import public-key-only addresses into a full wallet.  Every address in the wallet must have the private key, or not have the private key (it's too complicated to deal with mixed wallets... you would just create a new wallet for that).

(b) The digital backup does include all imported addresses.  However, I'm more of a fan of paper backups, so I recommend printing out the individual keys (select "Imported Addresses Only").  Especially, if you are importing lots of keys and making digital backups, you don't know which ones have been backed up already without loading the digital backup and checking -- it's obvious if you have them printed, though.

(c) I'm not sure I understand this.  There should be no problem running only bitcoind, and Armory should connect to it the same as it would to Bitcoin-Qt.  Unless you are talking about running bitcoind on a different computer...  (it will be possible to connect to remote nodes, in the future, but it's not ready yet).

Time is definitely a limiting factor in the development.  Almost-full-time job, just got engaged, holiday parties, etc.  My fiance knows how much enjoy working on this, and gives me lots of room/time to work on it, but it would definitely help if I didn't have a job.  But I also don't see how I could sustain on Armory alone without converting it to a paid-product model (and even then, I'm not sure the market is big enough, and the stability of Armory is high enough for that).  Right now I'm mostly happy with the arrangement, despite wanting to spend more time on Armory and less at work, but this is the most stable for me. 

People getting more involved in the code would be great.  Though, I understand Armory code base is big and scary  (about 25k lines of code, so far).  It is fairly well-commented, but it's also flush with corner-case catching, error detection, and luxurious informational dialogs which really obfuscate the intent of the code.  It can be tough for someone to see what the code is doing exactly when I've add multiple ways to detect various error conditions and half a dozen message box warnings to accommodate different conditions.  But I'm not sure there's a good way around that...

I was considering making a plugin system for Armory, that would allow users to create new tabs on the main screen.  There's some details that need to be worked out so that it can be done "safely" (or as safe as is reasonable).  That would definitely make it easy for users to contribute new features that could later be merged when they're fully developed.  Though, I'm not sure that's the best way to get other people involved in the code...

It's funny you bring that up, because there has been an extended conversation over the past few days on the mailing list, about exactly that.  There's some debate about the qualities of an acceptable to solution to promote as the default, and right now Bitcoin-Qt being the only "usable" full node implementation wins because we need full-nodes and that's the safest for the network.    But I do agree with you -- there should be a better experience for new users -- and maybe that discussion will yield something like: "Multibit should be default if it implements X, Y and Z and gets some more support behind it". 

But that's not the topic of this thread.  I do think that a plugin system for Bitcoin-Qt is a good idea, and I've thought about something similar for Armory.  Certainly, allowing plugins give more flexibility for non-core-devs to contribute, but at the risk of safety (rogue plugins can be a major security risk).

I think the bitcoin-qt devs have decided that security and stability is more important than "luxury" features like this, that are supported by a variety of other programs anyway (and supported by itself, through the RPC interface).  They'd rather spend the time dealing with network security to maximize the chance that the network survives an attack, or devastating bugs.  I've heard some of the devs suggest that Bitcoin-Qt could become more of a back-end for other programs to leverage, rather than focusing on recreating what those other programs do.

Sure, they are the face of Bitcoin at the moment, and they want to supply a better feature set for its users where possible.  But they have an important job to do under-the-hood that us alt-client developers can't do -- improve the network protocol and security.  But that's why they added an "Alternative clients" section to the main page, to make people aware that  they aren't the only thing in town.

This is mostly relevant:  if users care this much about importing/sweeping keys, they should know that there are clients that support it -- and Armory makes it damned easy.  The downsides of Armory are also relevant, for those who are intrigued by this posting that haven't used Armory before.  Obviously, the discussion still needs to be had whether/how importing makes it into Bitcoin-Qt -- but I think it's appropriate for context to mention that there are alternatives.

The key will not be available in Bitcoin-Qt.  Using Armory is using a new wallet with a new interface, and is unrelated to your Bitcoin-Qt wallet.  You likely won't use your Bitcoin-Qt wallet again.  Not everyone wants to make the jump, but few users that do want to go back (especially users advanced enough to be importing keys).   Bitcoin-Qt functionality is almost strictly a subset of Armory's functionality.  It gives GUI users a ton more stuff (though, Armory doesn't do much for bitcoind users).  I can't imagine ever going back to a wallet that requires multiple backups at risk of losing coins...