We're not comfortable with the performance yet of that many addresses.  But there's nothing technically wrong with doing it, but you might want to wait for version 0.91 which has dramatically improved performance.  It's not perfect, but I'm running with 27k addresses now (online) with no problem in 0.91.  And it was pretty slow in 0.90. 

Don't interpret slow address generation as a sign of anything.  The address chaining operation is very computationally intense, but actually using those addresses is fine, no matter how many there are.  The only thing to be aware of is that you will have to generate as many addresses on your offline computer as you are on the online computer.  Or generate them on the offline computer first before exporting the watching only wallet.   If you've already split them, it's no problem, but you'll have to go into expert mode in the offline computer and click on "# Addresses Used" in the wallet properties and tell it to generate 100k.  Once they're generated, it will have no problem doing offline signing for any of them, it just needs to be aware of those 100k.

Actually, I had been meaning to update that window to use a proper tableview, which would have customizable field lengths like you want.  It just never made priority, because tableviews require writing a tablemodel, and I was too lazy at the time to set it up all.  It should be done, though.  And wouldn't be hard.



We'd also like to have that at some point, but it would really complicate the main ledger.  We'd need a separate window that would pop up with the fitered/sorted view.  Again, very doable, just not a priority.  For now, if you really need it, you can export your transaction history from the "File" menu, and then open the output in Excel/OpenOffice to do the searching & sorting.  Obviously, not ideal, but it might be better than nothing.


I typically don't accept pull-requests directly, because most of them are super simple things that I can just fix myself, and I'm also trying to avoid mixing copyrights from a bunch of random people on the internet.  This project is 99.99%+ my own code, yet someone who contributes a couple lines might be able to claim some kind of mixed copyright.  So usually I just fix the bug that they identified in the pull request. 

However, if it's a substantial/large contribution, and you don't mind signing a copyright waiver, we'll happily merge it!  And usually we give a small reward in exchange for the signed waver -- the value is typically very small, but shows our gratitude and makes the waiver more legit (showing that both sides of the agreement are benefitting).

FYI, I'm not positive about this because I'm not that familiar with Tor, but I believe when using Tor, all connections appear to be from 127.0.0.1... so it's not necessarily safe in all  environments.  Someone please correct me if I'm wrong...

We put in a fix for some of the most serious slowness issues.  There was some inefficiencies in the way it stored and scanned live unconfirmed transactions, that only became apparent when the network volume picked up in recent months.  0.91-beta should have that fixed.

Don't use the testing version yet.  Simply close Armory, go to your ~/.armory directory and delete mempool.bin.  Restart Armory.  mempool.bin will reaccumulate, but it should take a couple days for it to bog down your system again, then simply redo it.  0.91 will have this fixed.

Let me know if that's not it.  (also, how big is your mempool.bin, before you delete it?)

I neither endorse nor discourage signing like this.  There's a lot of ways that this kind of signing could be abused, such as Ken simply knowing someone who has 1,500 BTC+ who would be willing to sign such a message for him (it doesn't really hurt the person who signs on his behalf).   

Ideally, your message would be something like:
("Ken Slaugher and ActiveMining have full control over this address which, at the time of signing, has 1,500+ BTC.")<signed by Address X, which has 1,783 BTC>

However, this is most effective if you know a particular address in advance.  i.e. You are already aware of a specific address holding 1,500+ BTC, and you want Ken to prove he has control of it.  Though it's still not fail-proof, if somehow Ken knows who owns that address and gets them to sign for it (but better than Ken simply needing to find anyone with 1,500 BTC and sign it).

With all that in mind, if you don't have a particular address in mind, the best you can do is:
The address associated with the signature can be looked up on something like Blockchain.info to verify the money held by it.

You can do this easily with Armory, even if it's not an Armory wallet.  You can create a wallet on an offline Armory instance (such as in a live session), and import the private key to the wallet.  Then you can go to "Tools"-->"Message Signing" from the main window and use that private key.  I don't recommend doing this with versions of Armory older than 0.90-beta.  The old message signing interface was garbage, but was updated in 0.90-beta, and you can now make signed message blocks.  The signed message block could be copied to USB key or exported somehow, then the offline/live session destroyed. 

As said above though, given the circumstances, I'm not sure how useful this will be.

You are trying to run it as a bash script.  You need to run it as a python script:

"python armoryd.py".

Also, as someone else noted, you'll need to download the txjsonrpc project and put it in your base directory (there should be a txjsonrpc dir next to armoryd.py).  Or actually get txjsonrpc installed -- it's an extra dependency not needed by regular Armory but needed for armoryd.py.

At the very least, the scanning is fixed in the latest version currently in testing (0.91-beta).  0.90 rescans every time there's a crash, but we determined that was wholly unnecessary.  A couple pages back I posted a testing version you can try.  You'll have to rebuild and rescan the first time, but you shouldn't have any rescanning after that unless you import or sweep private keys. 

Though, that testing version is a still a bit too young for most people.  I think we will have the new version officially out in a couple weeks.

Whoops -- I misspoke.  You definitely have to recreate and re-sign, if you're going to increase the fee.  The directions I gave above are given to people whose tx get stuck because of network issues, not fee issues.  In those cases, they just need to rebroadcast -- but you'll definitely need to recreate and re-sign it.

What is the status of BIP38?  I haven't been following the discussion. 

However, the new wallet files will have a much more flexible design that will make it easy to add new encryption and key-stretching methods, etc (including all the other goodies, like multisig, P2SH, compressed keys, etc).  If BIP38 becomes well-supported, I'll happily add it to the list of supported key-encodings in the new wallet files (or can be added even after the wallet files are done)

Okay, so you fell into a dead spot in the fee logic.  We recently discovered a bug that causes Armory to under-calculate the fee for certain kinds of transactions.  This was already discovered and fixed for 0.91-beta (will be releasing a proper testing version of it soon).    This affects a very small number of transactions, but it appears you fell into that crack...

As for resolving it... you could consider using Help->Clear All Unconfirmed, then restart Armory (and Bitcoin-Qt/bitcoind, if running it manually).  Then try re-sending the tx.  If it was an offline tx, you will be able to simply rebroadcast (don't need to recreate and re-sign it).  The success of this operation depends on how many peers you are connected to that still remember it. Once there is a critical mass that have forgotten it (maybe 10-20%), your transaction will go through

Does 0.9.0rc2 install to a non-standard location?  It'd be good to have a heads-up that things like that are changing...

Hey, are you talking about the testing version posted 2 weeks ago (0.90.99)?   Or the 0.90-beta on the website?  Either way, glad to hear some positive feedback, just wanted to get clarity on it.

In order to help diagnose problems, Armory will by default, ping google to check for availability of outbound internet connection.  If google.com can't be reached, Armory will go into offline mode.  As a backup, it will check microsoft.com, as well, but only if google can't be reached.

Armory will also contact bitcoinarmory.com, which may forward a github link with new-version information.   It is just a text file that contains signed version information (we commit the changelog to versions.txt in the master branch, and Armory uses that to identify when new versions are available).

Either or both of these can be disabled using:

--skip-online-check
--skip-version-check

If you are using tor, you'll have to skip online check anyways, as that will always fail when using tor proxies. 

Good question, I haven't tried it!  My guess is:  yes, but the interface may not be all that useful, probably "[Non-standard address]" instead of the address string you're expecting.  That's something I'll have to investigate... (feel free to try it and tell me what happens)

I just submitted a ticket to the blockchain.info support desk.  I also confirmed with gmaxwell that he sees the transaction confirmed on his blockchain, as well.  Definitely a BC.i problem.

Ultimately, this doesn't mean anything -- BC.i is not "bitcoin"... they are just run a service that lets you browse the network easily, but their window seems to be a bit foggy.  It seems that everyone else has a better view of the network than they do.
 
The implications are simply that anyone using blockchain.info to verify payments, etc, will not agree with you.  It seems you may have to wait for BC.i to figure out what happened, and if that's a problem, point the other party to non-BC.i websites (or their own desktop wallet) that shows the transaction is actually confirmed.  I'm not sure how they can be out of sync for long... maybe it's a DB problem?  Maybe they'll fix it soon.

I suspect this is actually an issue with blockchain.info:

(1) blockr.io shows it with 375 confirmations
(2) biteasy.com also shows 375 confirmations
(3) There's no reason for such a large transaction with a sufficient fee, to not have been mined after 2 days

Maybe blockchain.info is on a fork?  Or simply, their software is misbehaving?  Either way, it seems like Armory is correct

The addresses that start with "3" are P2SH addresses, usually used for multisig.  Armory version 0.90 and previous did not support sending to these addreses, but the new version to be released soon (0.91) will allow it.  It's up to them to deal with their own P2SH addresses, and how to create and spend from them.  But Armory will keep using the ones that start with "1", such as creating change addresses that start with "1".  Armory has no mechanism to spend multisig txOuts, even if it has some of the private keys.

As soon as this next version is out, my number one priority is finishing the new wallet design, which will suppot BIP32, multisig, P2SH, compressed keys, and a variety of other things.  It will also allow you to migrate your existing wallet to the new format, and continue using your existing wallets.  Though you won't get the benefits of the new BIP32 stuff.

Kind of.  There's a bug in 0.90-beta, that forces it to rescan way more often than it needs to.  This is dramatically improved in the new testing version (0.91).  It won't rescan unless you just import addresses or wallets. 

Unfortunately, if you leave Armory off for a couple weeks, it has to catch up with the latest blockchain history, which can be kind of slow (though it should only be a few minutes).  But there's not much we can do about it.

It can be done, but it's made intentionally difficult, because running two instances of Armory using the same wallets is guaranteed to corrupt your wallets.  And of course, all the extra data... most of the time the user simply double-clicked to open it again, not realizing it's already open.

If you really want to do it for whatever reason, then you can open the second Armory instance using


Interport can be any unused port, and is only for detecting multiple instances (which is why you must change it to run multiple).  You must change both datadir and interport at the same time if you don't want to corrupt your existing wallets.

Can you send us a log file?  Or post any seemingly-relevant errors you see at the end of of armorylog.txt or armorycpplog.txt?   It's especially interesting to us if the DB build & scan used to work but doesn't with the new version (because we added stuff that was intended to catch and handle errors in blk*.dat files... maybe that code is misbehaving?)