Topic: Armory - Discussion Thread - page 115. (Read 521761 times)

AFAIK, Alan *IS* Armory. 

Only client I can bear to use, even if the RAM requirements (- and it seems almost guaranteed to crash if certain parts wind up on virtual RAM) and need of maintaining the blockchain make it nearly unusable in my situation. I go to great lengths to be able to use Armory, because even while it currently has critical flaws, it's the most flexible and powerful client I've ever used. Alan's a freakin' rockstar in handling support issues, too. It's actually unnerving how interested he is in ensuring users have good experiences.

I really can't imagine a better way to donate money for the fundamental growth of Bitcoin and the ventures it spawns than to send it to Alan.

So we wait for the next proper working version of Armory ?

I applaud your decision!
Thank you for doing the right thing, sacrifying short-term development for long-term goals.

In fact you are the dev here I trust the most, be it technically, vision, endurance or incorruptable.
Not implying I see issues with other devs, but you I trust the most.

It will be a big day once Armory is self-contained, without any external component (like bitcoind). It's in the far future still, but it will be a milestone for the Bitcoin ecosystem as a whole.

Oh, are you a paid full-time Armory dev yet? If not, we have to change this! :-)

Ente

Thanks for the update. All your work is much appreciated.

Update: (25 June, 2013)

Things have been hectic.  Very hectic.  I am quite aware about the usability issues, and I have been making some progress on the "persistent blockchain" update for Armory, but not at nearly the pace I had hoped.  Other critical priorities have cropped up.  I will explain more about these priorities in a week or two.  I just wanted to assure those of you who still follow this thread that development does continue, despite things looking rather stagnant lately...

On the persistent blockchain front: I have found myself in the awkward position of deciding to just make an identical version of Armory that uses LevelDB, or to actually upgrade huge parts of the codebase as long as I'm tearing it all up and putting it back together, anyway.  It seems that the best solution is the latter -- I've always been a fan of short-term sacrifice for long-term gain.  Even though it's slowing down the resolution of the RAM issues, a lot of what I am doing now will benefit multiple other things I have on my TODO list, including the new wallet stuff that will come shortly after persistent blockchain upgrades.  

What I'm talking about is things like properly handling and indexing multi-sig scripts, P2SH scripts, and compressed public keys.  Additionally, I'm trying to make the whole thing easily extensible to both partial/lite/pruned operation (storing only data necessary for computing balance and creating transactions) and also super-node operation (maintaining a full address-lookup index for immediate balance/UTXO queries for any address).  These are all things that I need to do eventually, anyway.  For instance, I had claimed that the new wallet format was nearing completion before getting sidetracked by this stuff, but I was still going to have to upgrade a bunch of blockchain utilities and re-test it to be compatible with the new wallet functionality.  I might as well kill 7 birds with one stone.

It looks like I've found a coherent way to fit all this together.  And it means that many of these changes can be implemented and tested in one rigorous round of testing, instead of rewriting and re-testing multiple times.  More importantly, after the first persistent blockchain update, it will be much tougher to modify the blockchain utilities, because users will have persistent databases that will need to be rebuilt to accommodate changes.  And that may be quite painful.  If you were wondering why it was beneficial for me to do full scans on every load and not save any blockchain data between loads.... that is why (simple!).

That's all I have for now.  I'm excited that when I'm finally done with this, Armory will be miles ahead of where it was before.  So many problems will go away.  Until then... you'll all have to suffer while I take my time doing it right

Turns out it was entirely my own fault.

I had added the option

nolisten=1

to bitcoin.conf, in order for bitcoind not to consume too much outgoing bandwidth (nodes that want to sync the block chain generally connect to nodes rather than let nodes connect to them, so this avoids most clients that want to sync the entire block chain).

I have another problem that I hope you can help me with though.

I frequently experience Armory losing connection to bitcoind.

In the function


in armoryengine.py I added a line to print the reason for the disconnect using this line:


And the result is the following lines appearing very frequently in the CLI output (several times per second):


The text in the lower right corner keeps flashing between "Disconnected" and "Connected [...]".

There's a secondary bug associated with this. After letting Armory run like this for a while and then closing Armory, the disconnected/connected notifications keep on reappearing after the program has been closed for a long time. I think the reason is that they happen so frequently (several times per second) so there are thousands of these notifications queued up. And with each notification having a timeout of 10 seconds, they just keep reappearing until the queue is empty (long after the program is shut down).

Perhaps it would be necessary to, when displaying the notification, check whether a previous notification is still being displayed, and only display a new one if the previous notification is no longer there (more than 10 seconds have passed since calling self.sysTray.showMessage()) or perhaps cancel the previous notification, if that is possible.

Even if there is no Armory client for MeeGo ... there is BitPurse a client for MeeGo Harmattan (n9).

http://khertan.net/pages/bitpurse (Available for free in Nokia Store)

Donation is accepted

Hello,
As this is a Armory discussion thread i have a general question about armory. I know if you store a paper backup of a wallet, it holds the data for all past and future addresses that wallet ever creates. The root and chain hold a key to sequence. But theoretically for how many addresses in the sequence does armory check to see if there are any transactions on it? As in there can be a billion address possible in the sequence of bitcoin address that wallet generates i guess

Ditto what Rampion said.  Armory is an awesome client.  We really appreciate all the hard work you put into it.

You deserve it all Alan. Armory is a must have for anyone serious with Bitcoin. Keep up the good job!

THANK YOU!

I have been receiving substantial donations recently, but donors frequently don't identify themselves, so I have no one to thank!  In recent past I have gotten quite a a few 0.2-1.0 donations, and been taking my fiancée out to nice dinners with it .  I have been meaning to broadcast a thank-you post, then this donation from yesterday reminded me to do it!


People in this community are quite generous, and I'm thrilled to see people are impressed enough with Armory to make such substantial donations!  It means a lot to me.

So thank you!
-Alan


P.S - If you want to identify yourself to me--publicly or privately--I'll be happy to send you a T-shirt and Armory-branded USB key.  This goes for anyone donating the equiv of $50 or more.  I have only a few T-shirts left from the original crowdfunding a year ago, all black, L or XL (and maybe an XXL).  >= $20 gets a USB key (I'd do it for less, but these branded USB keys are surprisingly expensive when you don't order 10,000 of them!).

..one of the things I love about how you work - you look forward and solve possible obstacles before anyone comes up with them! :-)

Ente

If you look at the code, I do have a condition that warns about compressed keys... but I guess the "This number is too big" warning somehow takes precedence.  So I had thought about it... I guess I just didn't do a good job

https://github.com/etotheipi/BitcoinArmory/blob/master/qtdialogs.py#L2427

Good, it's no news then!
Maybe put some hint into the error message?
"Error importing.. invalid.. maybe compressed?"
So people don't throw away good keys or similar.
Nah, probably not important at all.

Cheers!

Ente

Ah yes.  Armory doesn't support compressed keys, yet.  They were going to be supported with the new wallet format, but that got put on hold for obvious reasons.  Once RAM-reduction is done, maybe I'll finally be able to finish that.

Until then, Armory can't handle compressed keys.  At all.

I found something completely different:

- using the Schildbach Wallet on Armory
- exporting the (only, primary) key from there
- trying to import it into Armory



This is a compressed key:

https://en.bitcoin.it/wiki/Private_key

Seems like Armory doesn't recognize them? 0.88.2 here.

https://www.bitaddress.org "Wallet Details" reads all kinds of keys and shows both compressed/uncompressed public and private keys from it.

Ente

Probably
Yes, you should be able to copy everything from the directory where Bitcoin-Qt stores its blockchain to the similar directory under Linux (.bitcoin/blocks - be aware that .bitcoin starts with a dot making it a hidden directory).  You should definetely copy all blk*.dat files, and probably also the index and rev*.dat files.

Good luck!

Same problem here. And I'm running 32 bit windows on my laptop. Can I solve the issue by creating a bootable USB running ubuntu (64 bit), and installing QT + armory? And will I be able to transfer the blockchain across rather than having to wait for QT to sync (which would probably take a week)?

I run bitcoind often to test a script I'm making that communicates with bitcoind. And I need to run bitcoind with the -blocknotify parameter, so I can't run it through Armory. So it's possible a new block file was created by bitcoind, while Armory wasn't running.

What happens if a new block file is created (say, blk00024.dat) while Armory isn't running? Will Armory load blocks from this file when it starts again?

I haven't moved any block files or anything. They are in ~/.bitcoin/ as they've always been.

Gah.  This is familiar.  I think jl2012 had a similar problem at one point.  The issue had to do with Bitcoin-Qt being detected, but failure to successfully open a connection.  It had turned out to be a problem with a timeout parameter. 

It's also possible that there's a problem with the blockfile location...change anything recently?