Armory - Discussion Thread

[cypherdoc]

will this client ever get arm support? i ask because i want to buy a raspberry pi, and that runs arm.

Ctoon,

It'll be a while before Armory will be lite-enough to work on such light-weight hardware.  However, the beauty of the offline transactions technique (based on BIP 0010) would make it feasible to use very inexpensive hardware solely for signing offline transactions (because you don't need the blockchain, you only need to be able to run ECDSA code).  But I don't think I'll be doing that... I just don't have the experience with alternative architectures.

But again, my stuff is open source, BIP 0010 is public, and my wallet files are well-documented.   I bet someone more-suited for the job could make it happen and I'd be happy to help them.  I am excited about the possibility of the offline tx technique to enable super-light-weight, inexpensive, signing devices that could be used for two-factor-authentication-like scheme.  But full Armory might be a stretch.

i use an Ironkey that has a malware scanner built in on top of the encrypted internal chip.  this combined with desktop antivirus/malware should be pretty effective in preventing malware from infecting the Ironkey would it not?

[etotheipi]

@etotheipi
Out of curiosity:
What is your stance on BIP 0016 ?
https://en.bitcoin.it/wiki/BIP_0016
https://bitcointalk.org/index.php?topic=56969.0

I fully believe in the goal of OP_EVAL and BIP_0016, and I believe it is a hard problem to solve safely.  As found with OP_EVAL, enabling a sub-scripting system with recursion in a system that was intentionally not Turing-complete, opens up a can of dragons.  Unfortunately, I've been so focused on Armory development, that I haven't gotten too deep into the discussions on it, so I can't form a valid opinion on any specific proposal.   But I do believe that the goal of these proposals is extremely beneficial to BTC in the long run.  (although, it would be nice to get my client out with the old rules before having to support new ones right away).

i use an Ironkey that has a malware scanner built in on top of the encrypted internal chip.  this combined with desktop antivirus/malware should be pretty effective in preventing malware from infecting the Ironkey would it not?

I've heard good things about the Ironkey.  For the offline wallet interface, the biggest threat is hidden USB-key viruses, so something with built-in-AV probably helps.  But without some kind of updating mechanism, it's built-in A/V could quickly become outdated and useless against evolving threats.  I think more importantly, having A/V on the online system and disabling any kind of autorun-on-mount capability on the offline system are the most proactive way to avoid these problems. 

But even without that, the offline wallet system is probably the absolute safest way to manage large sums of BTC, despite being fairly complicated.  Yet, I believe Armory has actually made it usable by ordinary users (now I just need to get the system req'ts down to "normal"), and hope others will help me test that part and let me know what they think.  It was one of my prime motivators for starting Armory.

[cypherdoc]

i use an Ironkey that has a malware scanner built in on top of the encrypted internal chip.  this combined with desktop antivirus/malware should be pretty effective in preventing malware from infecting the Ironkey would it not?

I've heard good things about the Ironkey.  For the offline wallet interface, the biggest threat is hidden USB-key viruses, so something with built-in-AV probably helps.  But without some kind of updating mechanism, it's built-in A/V could quickly become outdated and useless against evolving threats.  I think more importantly, having A/V on the online system and disabling any kind of autorun-on-mount capability on the offline system are the most proactive way to avoid these problems. 

But even without that, the offline wallet system is probably the absolute safest way to manage large sums of BTC, despite being fairly complicated.  Yet, I believe Armory has actually made it usable by ordinary users (now I just need to get the system req'ts down to "normal"), and hope others will help me test that part and let me know what they think.  It was one of my prime motivators for starting Armory.

i really appreciate this product.  i too look forward to offline tx capability in a simpler way.  thanks.

fyi, Ironkey updates the malware scanner online each time i open it and scans the contents of the Ironkey.

[paraipan]

........................

..................

i really appreciate this product.  i too look forward to offline tx capability in a simpler way.  thanks.

fyi, Ironkey updates the malware scanner online each time i open it and scans the contents of the Ironkey.

lol, and you believe it does only that...  

(sorry for posting off-topic, i'm amused by ppl who still believe "scanners" do only what they're supposed to do)

[etotheipi]

Conspiracy theories aside, it should be noted that no sensitive data touches the USB key, ever.  Not even on the initial wallet setup.  You transfer only a watching-only wallet from the offline computer to the online computer.  And when you spend money, only transaction data is sent back and forth.  The only thing that the offline computer adds to the USB key is a signature, which is going to end up in the blockchain, anyway.

Of course, if the manufacturers of IronKey wanted to do something nasty, they would have access to your entire system, not just what's on the key.  So perhaps it's moot.  But at least, you don't have to worry about someone else getting ahold of a key you used for Armory's offline wallets.  There's nothing they can do with the data being couriered with that device.

[matsh]

Also donated, this effort must be rewarded!

[etotheipi]

Thanks to everyone who has donated!  You guys rule.  I already took my girlfriend out for a nice dinner on the donations I've gotten, and she does feel appreciated

Of course, I will not discourage donations, but I do desperately need folks to help test the software.  Besides the caveats already stated, and the zero-conf transactions which should be implemented soon, all major features work.  I'm aware of build-issues on non-Ubuntu-10.04, and working on better cross-distrib support.  Windows works great if you can get through the build instructions without stabbing yourself.  If the Windows instructions really are prohibitive, I might have to distribute a pre-alpha binary, but that makes it difficult to push bug fixes and have testers pull the updates right away. 

Please let me know if there's something holding you back.  And if anyone uses it for main-network with real BTC, please print out a paper backup of your wallet.  The wallets do appear to be very robust, but it's alpha, and whatever money you have will be recoverable with a paper backup under any circumstances

[SgtSpike]

I'll test it as soon as there's a Windows binary available.  But after spending many hours building the standard Bitcoin client in Windows, I took a vow to never build anything in Windows again.  It's just not my kind of gig.

[etotheipi]

I'll test it as soon as there's a Windows binary available.  But after spending many hours building the standard Bitcoin client in Windows, I took a vow to never build anything in Windows again.  It's just not my kind of gig.

I've heard that the Satoshi client is challenging to build.  However, I have thoroughly documented the build-process for Armory and tested it in MSVS 2008 from a fresh install in Win 7 x64.  It did work, no problem.  I request you give it a shot (just follow the directions), and if you hit any snags, feel free to stop.  But I did spend a lot of time on those build-instructions precisely because I know how terrible it can be for others to figure it out.

[fornit]

Follow all the steps above.  Open the ArmoryEngine_MSVS_2005.sln file.  Make sure to select “Release” mode and “x64″ (or Win32 if only 32-bit OS).  Build-all.

cant find that file.
however there is a PyBtcEngine_MSVS2005.sln

[etotheipi]

Follow all the steps above.  Open the ArmoryEngine_MSVS_2005.sln file.  Make sure to select “Release” mode and “x64″ (or Win32 if only 32-bit OS).  Build-all.

cant find that file.
however there is a PyBtcEngine_MSVS2005.sln

It looks like you didn't switch to the "qtdev" branch.  This project was forked from another project of mine (PyBtcEngine) and I forgot to rename the solution files until after I forked qtdev.  Everything is on the qtdev branch.  It will all be merged into master for the alpha release.

[fornit]

yay it works!

interesting facts:
1. it works with msvs2010
2. it doesnt work with swig for linux
3. it doesnt work without python path variable
4. it doesnt work with python path variable without reboot
5. doing serious stuff at hours were most people sleep isnt as time efficient as linear arithmetics might indicate (see 2., 3. and 4.)

actual testing will follow another day. only one thing i noticed: it stops responding when you try to close it.

and btw msvs2010 ends with:

3>  SWIG_compile_dll_MSVS2005.vcxproj -> Z:\fremdprojekte\BitcoinArmory\cppForSwig\x64\Release\SWIG_compile_dll_MSVS2005.dll
3>PostBuildEvent:
3>  Description: Combine compiled libraries and PyQt gui into .exe
3>          1 file(s) copied.
3>  python: can't open file '../setup.py': [Errno 2] No such file or directory
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: Der Befehl "copy x64\Release\SWIG_compile_dll_MSVS2005.dll ..\_CppBlockUtils.pyd
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ; python ../setup.py py2exe --includes sip,hashlib -d ../ArmoryStandalone
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073:
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073:
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" wurde mit dem Code 2 beendet.

any idea what might cause this?

[etotheipi]

3>  SWIG_compile_dll_MSVS2005.vcxproj -> Z:\fremdprojekte\BitcoinArmory\cppForSwig\x64\Release\SWIG_compile_dll_MSVS2005.dll
3>PostBuildEvent:
3>  Description: Combine compiled libraries and PyQt gui into .exe
3>          1 file(s) copied.
3>  python: can't open file '../setup.py': [Errno 2] No such file or directory
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: Der Befehl "copy x64\Release\SWIG_compile_dll_MSVS2005.dll ..\_CppBlockUtils.pyd
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: ; python ../setup.py py2exe --includes sip,hashlib -d ../ArmoryStandalone
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073:
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073:
3>C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppCommon.targets(113,5): error MSB3073: :VCEnd" wurde mit dem Code 2 beendet.

any idea what might cause this?

fornit,

I'm glad you were able to get it working and that the build-instructions apparently were sufficient  

The error is actually an extra build-step that is unnecessary for testing purposes.  It uses py2exe to collect everything into a single standalone directory and .exe file.  It involves getting py2exe, pywin32 and finding msvcp90.dll.  But I figured no one would really need it except for me, to build binaries for my first release.

As for closing the app, I don't know why it's so terribly difficult to get qt4reactor to shut down!  I finally got it smooth in Linux, but Windows is still unpleasant.  I'll make an effort to fix that, ASAP.

I hope you enjoy Armory!

P.S. - I just fixed the Armory shutdown issue -- right click and do a git-pull to get fixed version.  At least, it won't freeze, though Python itself sometimes stays open.

[fornit]

pulled the new version.
now i get this this error on startup:

   Wallet (2gTHGzUV5):      "Test Wallet"    (Encrypted)
Traceback (most recent call last):
  File "armoryqt.py", line 1612, in <module>
    form = ArmoryMainWindow(settingsPath=options.settingsPath)
  File "armoryqt.py", line 66, in __init__
    if self.abortLoad:
AttributeError: 'ArmoryMainWindow' object has no attribute 'abortLoad'

[Matoking]

The Windows build instructions for SWIG portion seems to be incorrect

(You should now see 3 subdirectories in cppForSwig dir:
cryptopp, reorgTest and swig-2.0.4)

The SWIG_compile portion failed because it couldn't find swigwin-2.0.4 folder

   
Creating temporary file "c:\Users\Janne\BitcoinArmory\BitcoinArmory\cppForSwig\Release\BAT00000C51685384.bat" with contents
[
@echo off

swigwin-2.0.4\swig.exe -c++ -python -classic -outdir ../ -v CppBlockUtils.i

which means you need to download swigwin-2.0.4, NOT swig-2.0.4 like the build instructions say. (I was building on 32-bit Vista)

The build still seems to fail because I have Python 2.7 installed in D:/ instead of C:/

2>LINK : fatal error LNK1104: cannot open file 'python27.lib'

EDIT :
I got it farther this time, although it still fails with this error

3>LINK : fatal error LNK1104: cannot open file 'cryptlib.lib'

[etotheipi]

The Windows build instructions for SWIG portion seems to be incorrect

(You should now see 3 subdirectories in cppForSwig dir:
cryptopp, reorgTest and swig-2.0.4)

The SWIG_compile portion failed because it couldn't find swigwin-2.0.4 folder

   
Creating temporary file "c:\Users\Janne\BitcoinArmory\BitcoinArmory\cppForSwig\Release\BAT00000C51685384.bat" with contents
[
@echo off

swigwin-2.0.4\swig.exe -c++ -python -classic -outdir ../ -v CppBlockUtils.i

which means you need to download swigwin-2.0.4, NOT swig-2.0.4 like the build instructions say. (I was building on 32-bit Vista)

The build still seems to fail because I have Python 2.7 installed in D:/ instead of C:/

2>LINK : fatal error LNK1104: cannot open file 'python27.lib'

EDIT :
I got it farther this time, although it still fails with this error

3>LINK : fatal error LNK1104: cannot open file 'cryptlib.lib'

Ugh.  I don't know how to setup these things to accommodate non-"standard" configs (such as python being in a different place than C:\Python2X).  However, the cryptlib thing should work if you compiled the cryptlib project in MSVS.  You should see, a cryptlib/win32/output/release directory in the cppForSwig directory.  It should be created, and cryptlib.lib will be in there if you compiled that project.

Maybe I really should do binaries.  Leave the compiling to only the people who want to have to develop/modify the project.

Fornit, I just committed the fix for that.  I think I accidentally only commited one of two files impl the windows-close fix.  It should all be there, now.

(EDIT:  I just fixed the swig-vs-swigwin part of the directions on the webpage.  Sounds like both of you got caught by that typo.  Thanks Matoking)

[fornit]

new error on startup:

  File "armoryqt.py", line 1602, in <module>
    import qt4reactor
  File "Z:\fremdprojekte\BitcoinArmory\qt4reactor.py", line 353, in <module>
    from win32event import CreateEvent, MsgWaitForMultipleObjects
ImportError: No module named win32event

[etotheipi]

Man, this stuff is hard.  I re-enabled some dependencies I had removed, hoping it would help with the shutdown issue.  It didn't.  So I removed them, again.  Sorry!

[cypherdoc]

........................

..................

i really appreciate this product.  i too look forward to offline tx capability in a simpler way.  thanks.

fyi, Ironkey updates the malware scanner online each time i open it and scans the contents of the Ironkey.

lol, and you believe it does only that...  

(sorry for posting off-topic, i'm amused by ppl who still believe "scanners" do only what they're supposed to do)

feel free to elaborate.

[cypherdoc]

ethotheipi,

i already have a non encrypted wallet generated offline stored on my Ironkey.

what would be the best way to get it tx'd into Armory on an offline computer?