Armory - Discussion Thread

[etotheipi]

I updated the packages (and md5sums), and they now include the full zope.interface source (with license information), and a short python script to install it for you.  Now, in order to install zope, you just double click on the script "install_zope.py."  Everything else should just be a straight download and install.

If you have not yet tried Armory, please try it now, and let me know if it works from a fresh system without any python-related stuff prior.

[Matoking]

Tried it out, other than some problems with the UI, it looks very nifty! I can use it only on the testnet at the moment, though.

[etotheipi]

Tried it out, other than some problems with the UI, it looks very nifty! I can use it only on the testnet at the moment, though.

Why can't you use it on the main-network?  Is it an issue with Armory itself?   And please let me know what problems you have with the UI.  I can't fix them if I don't know what they are! 

[Matoking]

I don't have enough RAM to hold the whole main network blockchain, that's why.

The GUI issues are nothing severe, it just looks a bit ugly with overlapped text and buttons :
https://i.imgur.com/BOQ6d.png

[etotheipi]

I don't have enough RAM to hold the whole main network blockchain, that's why.

The GUI issues are nothing severe, it just looks a bit ugly with overlapped text and buttons :
https://i.imgur.com/BOQ6d.png

Matoking, thanks.  I have seen that a couple times on systems with screens smaller than my own.  But it doesn't appear to happen on any other tables, so it should be easy to isolate why that's happening.  At least, ugly is better than dysfunctional!  I will look into it this weekend!

Given the previous discussion in this thread about mmap, I might be able to fix the RAM issue sooner than later!  It's not as difficult to implement as I expected (and the madvise() function is exactly what I need to optimize the operation for blockchain scanning).  Linux will get the upgrade first, but hopefully Windows won't be far behind!

-Alan

[etotheipi]

Man I suck at quality control.  I had tested the pseudo-binary solution in Windows, except I used a machine with python already on the path which wasn't part of the install instructions.  I updated install_zope.py and tested it on a fresh Windows7-32bit VM.  Works perfectly now.

Also, it gave me the opportunity to test the XP-32bit binary on Windows7-32bit, which did work.  So I renamed them simply to "Armory_32bit.zip" and "Armory_64bit.zip".  Only the rare few with WinXP-64bit may have an issue.  And I don't have a sample system like this, so I can't test it.  If you do have such a system, let me know how it goes.

I'm still working on the full-binaries, but the issue I'm having is inconsistent, so I don't have a good way to know for sure.  I just have to do some more exhaustive testing.  Thanks for your patience!

[etotheipi]

Wake me up when Armory can transition existing data in. Sorry
for the rant, I have a feeling your app. has a ton of potential, but
I can't get it to do what feels like the very obvious.

znort,

I have actually, explicitly, decided not to allow people to import their wallet.dat.  It's because stupid things happen when you have two clients open using the same keys, and users shoot themselves in the foot.  Not to mention, I don't want everyone blindly converting their entire wallet to a piece of alpha software.  Armory is good, but it needs to survive in the wild a bit longer before I start allowing people to import their entire wallets.  This way, users know to approach cautiously.

I should've explained, that the point was for you to make a new wallet, and transfer some of your money to the new wallet.  If you're comfortable transferring all of it, I won't stop you.  If you have some popular addresses you want to move over, you can use pywallet to get them and import them to Armory. 

Once I get some other features implemented, I will be making a bulk-import dialog.

[fornit]

First thing I tried: import my existing wallet.dat. No go. Why ?
The one thing that a new client ought to do is allow import from
the existing established format. Either I missed how to do this
(likely), or I am flabbergasted that this one unavoidable obvious
feature was omitted. Without it ... Armory is useless.

the existing format sucks and armory has a completely different and imho way superior approach. its better to make a clean cut early than to carry on with a bad solution because of backward compatibility.
its not like there a millions of people out there depending on their old addresses.

[btc_artist]

First thing I tried: import my existing wallet.dat. No go. Why ?
The one thing that a new client ought to do is allow import from
the existing established format. Either I missed how to do this
(likely), or I am flabbergasted that this one unavoidable obvious
feature was omitted. Without it ... Armory is useless.

the existing format sucks and armory has a completely different and imho way superior approach. its better to make a clean cut early than to carry on with a bad solution because of backward compatibility.
its not like there a millions of people out there depending on their old addresses.

Import functionality would not mean changing the Armory format.  You would simply read the old wallet.dat file and then import all the private keys into the Armory wallet.

[fornit]

and then you have a deterministic wallet that is a few bytes big  + hundreds of isolated keys including the backup keys. very useful.

[btc_artist]

and then you have a deterministic wallet that is a few bytes big  + hundreds of isolated keys including the backup keys. very useful.

That *is* a valid point.  In many cases, it would be better to send the BTC to the Armory wallet via a transaction.  Of course, the exception is vanity addresses.

[etotheipi]

Joric succeeded at reading encrypted wallets, and I do want to eventually allow the move, but I want to make sure it's possible to run Armory without running bitcoin-qt/bitcoind at the same time.  Sharing some addresses between the two wallets while also having some independent addresses can lead to you having absolutely no idea how much money you have (and usually over-estimating).

At the very least, I want to allow people to switch to Armory, but I can't reliably create a perfectly synchronous dual-wallet system.  I designed the Armory wallet specifically to be simple and straightfoward, and easy to maintain among multiple clients.  The Satoshi client wallet uses a database engine, which not only requires a separate library, but I also think it comes with extra risks (like the encrypted-wallets-not-actually-encrypted bug 0.4.0).   I will not add any support for Satoshi wallets beyond pulling keys out of them.  

In the future I will not only implement a bulk-import feature, but also leverage pywallet code to do a direct import of the Satoshi wallet, but with a warning to stop using the Satoshi wallet (perhaps a print-backup-then-delete option).  Until then, just create a new wallet and send it some money.

The single-address-import function was aimed more for vanity-gen addresses and Casascius physical bitcoins.

[Red Emerald]

I will not add any support for Satoshi wallets beyond pulling keys out of them.  

In the future I will not only implement a bulk-import feature, but also leverage pywallet code to do a direct import of the Satoshi wallet, but with a warning to stop using the Satoshi wallet (perhaps a print-backup-then-delete option).  Until then, just create a new wallet and send it some money.

I'm excited for this.

[btc_artist]

I will not add any support for Satoshi wallets beyond pulling keys out of them.

Good decision.

[btc_artist]

One question I do have is how do imported addresses and the deterministic wallet work?  You can rebuild the deterministic wallet based on the seed value, and I assume imported addresses are just held completely separate.

[etotheipi]

One question I do have is how do imported addresses and the deterministic wallet work?  You can rebuild the deterministic wallet based on the seed value, and I assume imported addresses are just held completely separate.

btc_artist,

That is exactly right.  There's actually a warning box when you decide to print a paper wallet that warns you that imported keys are not part of that backup.  However, that's why there's also a wallet option labeled "Backup Individual Keys."  Clicking that gives you a list of private keys that you can manually copy/save/print (and a checkbox for imported-keys-only).  The goal was to allow you to be able to get your individual keys if you want to import them into another program, or just create a imported-key-backup to supplement your deterministic backup.

[torusJKL]

I managed to build and run Bitcoin Armory on Mac 10.6.7 + xcode 4.2, looks like it's working fine.
Instructions: http://pastebin.com/K9NYsKRD

Thanks for the instructions.
I tried to use homebrew to install the dependencies.

Code:

brew install python
brew install qt
brew install sip
brew install pyqt
brew install cryptopp
brew install swig

I applied your patches and changed the python path int he Makefile (homebrew uses python 2.7.

I now want to compile BlockUtils using make swig in cppForSwig.
But it does not succeed with the following error:

Code:

      ...
  "_PyObject_GenericGetAttr", referenced from:
      _tmp.9896 in CppBlockUtils_wrap.o
      _tmp.10034 in CppBlockUtils_wrap.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
make: *** [swig] Error 1

Any ideas?

[etotheipi]

I managed to build and run Bitcoin Armory on Mac 10.6.7 + xcode 4.2, looks like it's working fine.
Instructions: http://pastebin.com/K9NYsKRD

Thanks for the instructions.
I tried to use homebrew to install the dependencies.
...
I applied your patches and changed the python path int he Makefile (homebrew uses python 2.7.
...
Any ideas?

Just FYI:  I already applied those patches to the codebase and verified that they don't affect Armory running in Windows or Linux.  The only thing that might need to be modified, still, is the Makefile (but I'm pretty sure that was patched, too). 

After Joric posted, I patched, tested and committed it, then modified the directions slightly and posted them on the Building Armory from Source.  Probably doesn't fix your problem, but it's worth mentioning since I don't think I responded to Joric's post directly.

[Red Emerald]

I managed to build and run Bitcoin Armory on Mac 10.6.7 + xcode 4.2, looks like it's working fine.
Instructions: http://pastebin.com/K9NYsKRD

Thanks for the instructions.
I tried to use homebrew to install the dependencies.
...
I applied your patches and changed the python path int he Makefile (homebrew uses python 2.7.
...
Any ideas?

I had some trouble building python libraries in the past with homebrew.  I think I had to manually set ARCH.  I think I put something like this in my .bashrc and then didn't have to worry about it anymore.

Code:

export CFLAGS="-arch x86_64"
export ARCHFLAGS="-arch x86_64"

When I get to my laptop, I'll check.

[torusJKL]

Just FYI:  I already applied those patches to the codebase and verified that they don't affect Armory running in Windows or Linux.  The only thing that might need to be modified, still, is the Makefile (but I'm pretty sure that was patched, too). 
[...]

I pulled the newest changes and added the export flags.

Code:

export CFLAGS="-arch x86_64"
export ARCHFLAGS="-arch x86_64"

Now it builds without problems. :-)
Thanks.

I'm now confronted with having to build python-twisted. Looks like it is not part of homebrew.

Code:

***Python-Twisted is not installed -- cannot enable
   networking-related methods for ArmoryEngine
Traceback (most recent call last):
  File "ArmoryQt.py", line 39, in <module>
    from armoryengine import *
  File "/Users/gbuki/Documents/git-repo/BitcoinArmory/armoryengine.py", line 8322, in <module>
    class ArmoryClient(Protocol):
NameError: name 'Protocol' is not defined