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

Armory crashed on me and now it has been scanning the block chain for over 20 minutes.  Kaspersky is reporting problems with python27.dll.  What is going on.  I can't get to the wallet that I just deposited to? 

It's not just you. Probably eats about 2.5 GB on memory right now.
Etotheipi (Alan) is working on fixing that.

Is it only my Armory online-client or does it generally consume a lot of memory (Win 7, 64bit)?

You don't see it, but Armory actually opens a localhost port in order to catch duplicate instances of itself, and handle Bitcoin URIs.  If Armory is opened a second time, it fails to be able to open that same port for listening (because the first instance is already using it), and quits instead.  If there was an argument on the command line, Armory2 sends it to Armory1 over that port, before exiting.  This is how Armory pops up when you click on a link, and also prevents your wallets from being corrupted when multiple instances collide.

Hi, my Max OSX firewall is asking me if I want ARMORY to accept incoming traffic. Why is this? I thought armory was relying in Bitcoin-QT, which is the one doing the listening... Am I correct?

Just curiosity, because even if I don't allow armory to accept incoming traffic, it works OK when broadcasting offline transmissions or displaying received funds.

Will try to catch it at home!

Ente

As usual, can you email me a log file?  Or copy any errors you see in the log file here.  I suspect there's an error being thrown that is usually some code punctuation out of place or something.  It's usually a quick fix, and usually results in buttons/commands looking like they do something, but then not doing it at all.

Sorry, didn'r follow up on the last few pages.
I just noticed:
I have an encrypted wallet. I want to add a comment to an address or transaction, I doubleclick it and type away. The comment isn't saved, though. I am not asked to enter my passphrase neither. And I don't see a manual way to unlock the wallet (without creating a tx).
Armory 0.87-beta

Ente

I'd like to see a couple features in the client (both windows an linux versions).
Do you have a system for allowing bounties?

$20 in BTC - Allow labeling the sources of coins and adding an option for seeing that in the list instead of the destination address.
Example, I want to see all the coins coming into my wallet from XXX address and I want to label them all as YYYY and sort it to view them all in a cluster.

Great work, I guess the problem is getting more developers to help in creating and improving the code.

It's funny you say that, because I spent the last week pulling my hair out trying to accommodate all the situations to make "auto-management of Bitcoind" the default without confusing people too much, but also try to leave "self-management" available (which may be forced on OSX, for now).  So far it seems to work, quite reliably, too! 

Strictly speaking, the two won't be "merged", code-wise.  But it will be transparent to the user.  I'm just finishing up the process of helping the user download and install Bitcoin-Qt in Windows.  Once Bitcoin-Qt is installed on the user's system, they'll never see it again (unless they want to).  I'll hopefully be releasing a testing version for Windows, soon, then people can dig in and see for themselves. 

No worries.
Your time, your priorities

I have tons of ideas, 'but lack technical knowledge for now.
Best to start with the basics, 'solid foundation is important.
Hopefully one day I will be able to help the community.
Meanwhile, I talk around about Armory.

I didn't read enough, but it seems you will try to merge Armory with the main Bitcoin client.
Or 'make it transparent. Easiness of use is a good thing.
If that's where you're going, 'great to make it the default setting.
Many user will probably appreciate that Armory does on it's own the client's management task.
But try to keep an option for those who would like to have the management for themselves.
If that's not a headache.
('so that in future those trying to use Armory with alternative blockchain/cryptocurrency have it more easy.)

Good continuation.

@alexanderanon

It might work being 50 days behind, but probably not.  You'd be lucky if it does work, and doesn't start choking on all the data that Bitcoin-Qt is sending it.  The new version will actually just run it in the background for you, and won't even let you connect until it's synchronized -- because users have so many problems when they do it early

I know backups are confusing, which is why I made this backups page.  There's a better one, coming soon, but that at least has most of the information you could want.

The answer to your question (directly), is that if your wallet is encrypted, your digital backup will be, too.  The encryption is very strong, and the attacker needs to know something about the passphrase in order to break it.  So in that case, you'd be safe.  But you'd probably also forget the password in 2 years when you need it, making that digital backup not very useful (especially if you are trying to restore from backup because you forgot your passphrase!).

I always recommend a paper backup, which is unencrypted.  Similarly, if your wallet is unencrypted, your digital backup will be too.  In both cases, if someone steals it, they will send all your coins to their own address, and your online Armory will show an outgoing transaction to an unknown address.  You won't see anything on the offline computer, because it doesn't have network access (the offline computer doesn't even show balances, it's only for "signing the checks").  If you have online armory open, though, you'll see it right away.  And you won't know that anything is wrong until it's too late.

Let me just reiterate one point:  the vast majority of use Bitcoin cases are threatened by online/virtual threats, not physical threats.  Unless you have a specific reason to worry about physical security of your paper backups, you should use the unencrypted one.  Because, if you use the encrypted one and forget your passphrase, it's just as good as not having any backup at all!

---

Hey thanks!  Unfortunately, the other currencies are not in my priorities list, but "simple" variants like LTC can probably be made work with only changing a few constants and updating a couple of functions.  I can offer advice to someone making that leap, but I don't have time to do it myself and debug it, etc (also, I don't use the others coins, so I don't even know where to begin)..

Congrats etotheipi !
I upvoted your comment on wired.com
That's not much, but that's the least I can do to congratulate you for your time-consuming wonderful work.

Your major update on v.0.88 seem interesting.
Yet, I have this little dream to - one day - be able to use your convenient offline wallet interface with other cryptocurrencies (NMC & LTC in priority). That would be awesome. 'sure I'm not the only one to think it.
'might need to do special Armory fork/version per currency if you definitely mix it with the client.
But 'whatever.

My moral support to continue the good job

Hello, new armory user here. Quick question:

If bitcoinqt is not synchronized (let's say i'm 50 days behind), can I still run armory and have it connect to qt up to its partial synchronization? I don't have any significant bitcoin income to justify staying current, so my qt client often gets a month or two behind.

Also, if a digital backup is made of an armory wallet file, for an offline wallet, and this backup is somehow stolen and spent, would the offline armory wallet still display a balance as if nothing had happened? Thus, I would only discover the theft if I tried to sign an unsigned transaction from my online armory, at some point in the future, and find (to my horror!) that the private keys needed to sign the transaction have been spent.

Yes, a few days ago.  I followed the instructions here: https://gist.github.com/FiloSottile/3646033
but instead of applying the patch to the Makefile, I went through it by hand and made the same changes.  I also had to remove $(STATICPYTHON) from the command line where the shared object (.so) is built.

Also, be aware that he refers to another page on how to build the cross compiler, and below that writes that you also have to enable building the C++ compiler.  If you overlook that you waste three hours of compiling!

I cannot walk you through it, as I will go offline for a week or so in half an hour


EDIT:  You will also need to install a number of dependencies on the RPi, the error messages when attempting to start Armory without them will point you in the right direction.  I chose to take it online and install them with apt-get, the truly paranoid should probably move the packages with an USB stick, although if the RPi never goes online after the wallet has been created I am not worried (and the yet non-existing wallet-stealing malware could have infected the installation image, too). 

But if you do that, you might just install all dependencies on the RPi and compile there.  It may take forever, but should complete unless there is too little RAM to compile the huge _wrap.cpp file that Swig generates.

Has someone successfully compiled current Armory version for Rpi?

Linux users:  Please help test!

https://bitcointalksearch.org/topic/m.1655941

I'm working on the Windows side of it, now.  I'll update that post when its ready.

Check out this bling!



Got another cert just for code signing that is kept exclusively offline, but I'm not sure I can use it for OSX builds without bringing it online, or getting an OSX system offline (which will complicate the release process, for sure).

It'd be awesome if someone could figure out whether it's possible to sign OSX *.app files using Linux... so far it's not looking promising, but I'm sure I'm not the first person that's wanted to do this.  It looks like it's possible with Windows installers using mono and/or osslsigncode.  I really want to be able to sign all installers from a single computer.

+1 did my part I only use armory for cold storage and it makes it so easy!

Idiots. Upvoted, come on people it takes 2 seconds!