Topic: Armory - Discussion Thread - page 154. (Read 521829 times)

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%...

Right.  Edited the original.

Hey.. windows 64 version .86-beta, sorting columns appears to be broken (probably related to the pagination code I would imagine).

Clicking columns won't sort any of them anymore, which makes finding a transaction difficult.  A global search function would be really nice, too... I have a bunch of wallets and thousands of transactions, so finding a particular transaction in a particular wallet is sometimes problematical.

I'm working on setting up a user overlay for Gentoo so that you'll be able to have proper installation instructions for Gentoo.

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?

Congratulations to etotheipi for reaching beta stage on this fantastic Bitcoin client.  What follows are build instructions for OpenSUSE 12.2 (64-bit).  I did a clean install of SUSE with default packages to find out which were needed for a plain-vanilla install.  If you've been using your system for development, chances are you won't need all of the packages.

1. Install the following packages using your preferred package manager (zypper, YaST, rpm, etc.):

2. Open a terminal window and get the source:

3. Edit BitcoinArmory/cppForSwig/Makefile and change:
to:

4. Build and run as described in the Ubuntu instructions, viz:

So I'm finally quite happy with my offline wallet setup, and I wanted to share it with others.

I have been using a Rapsberry Pi to run the offline instance of Armory. It was hooked up to my monitor through HDMI, and I had an extra keyboard around. When I wanted to perform an offline transaction, I would create it on my main computer, put it on a USB drive, plug the keyboard and USB drive into the Pi, run Armory, sign the transaction, transfer it back to the main computer, and broadcast it.

Last week, I purchased a USB to TTL, and that whole process changed for the better. The cable provides power to the Pi and allows for a terminal login to the device, so I no longer need an HDMI cable, power cable, or keyboard. I merely keep it unplugged, and plug it in when I want to perform a transaction. I log in using screen (screen /dev/ttyUSB0 115200), then run this script which does the following...

Opens a new file called armory.unsigned.tx in Nano, allowing me to paste in the ascii-serialized transaction
Runs this script against the unsigned file
If the file was signed, then display it using Less (at which point I copy it and paste into the broadcast transaction form)
Shutdown the Pi

I'm pretty sure that the TTY device only allows for a single login at a time, so I don't think it would be possible, and certainly not feasible, for an attacker to steal bitcoins from the Pi during the short time that it's connected to my computer. Any thoughts?

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.

Hi. I'm having python27.dll error issues with Armory 0.86, it says it isn't found but I have python installed and those DLLs are in my system32 and syswow64 folders. Every time I install Armory I must copy the DLL from one of those folders and paste it on the armory program files directory. I don't know why does that happen.

Red Emerald, etotheipi, I can sleep easier now, thanks a lot for explanation

As I understand, the format of the blockchain data itself isn't changing, just the database that indexes it (which Armory doesn't use at all), so there should be no problems.

So bitcoin 0.8 has some changes for the blockchain storage IIRC.  Will this break your blockchain loading?  Have you started working on support for this?

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

Even if development is abandoned, the version you already have installed will probably still work.  If bitcoind (or even the entire bitcoin network) has changed in a way where Armory is not compatible, then you could still load the program offline, export your private keys and import them into newer software.

These questions don't really have any more to do with Armory than they do with any piece of software in existence. 

tl;dr The armory software and the private keys are pretty separate, so no, there is no risk of losing coins even if etotheipi were to pull a Satoshi and disappear on us.  Barring some attack that completely destroys the bitcoin network, your funds are fine.

etotheipi, I have a question...maybe you will find it strange and offensive, please excuse my ignorance.

Can I really trust Armory?
I mean, if I choose to use it as offline storage for relatively significant sum of bitcoins, what hypothetical risks will I face? Say I have paper backup and go to coma for 2-3-5 years, then I wake up. I can imagine some problems:
1. You will abandon developing
2. Some sort of attack to encryption
3. Attack to keys generation
4. Critical bug

Am I right? I think it is more philosophic question, or about intuition and professional experience. Is there a possibility that I will lose my bitcoins? Thanks.

no armory never crashed for me. u forget the cache from linux for the HDs, if you fill them up then you cant read until everything is written, if the cache is big enough (as for me) then it takes sometimes longer than 10s or if the HD is really slow. just try it yourself

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...

drive the HD load to 100% (dd if=/dev/zero of=$HOME/junkfile bs=1024M count=10), at this time i always see lost and reconnect in a loop.

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.

i can confirm this happens on linux too! it happens only if the harddisk is under full load and bitcoind dosnt respond fast enough (just a guess that this is the problem). Armory thinks he lost the connection due to a short timeout setting (just guessing). is this possible?