I'd also point out that Armory 0.87 still seems to work on my little old Macbook Air (OS X 10.6; 4GB RAM; 128B SSD). Not sure it will much longer, and tbh I'm surprised it does now. Kinda cool that it does though
I believe it still works on Linux and OSX systems with 4GB if you are running nothing else. Windows has significantly higher resource usage for some reason. It's most likely that Armory uses the same amount of RAM, but Windows likes to eat up 1 GB of RAM just to use the OS, whereas Linux uses like 100-300 MB. Meh, it won't matter shortly  |
|
|
|
At the rate the bitcoin blockchain grows in size, 2.2x the growth worries me a lot more than 1x growth. It really shouldn't. Doubling the storage requirements is mathematically very little. If you can afford to store 10 GB, you can almost assuredly afford to store 20 GB. If you can afford to store 1 TB you can almost assuredly afford to store 2 TB. It really isn't about what you can afford, it's about what you can do. If you're on a laptop with an SSD, you have 128GTB, maybe 256GB if it's a new one. Sure that's enough for now.... but what's this 2TB you're going to plug in to your laptop and how is it going to work? roy The point is that increasing disk space on an arbitrary system is usually much easier then increasing RAM. Most consumer motherboards currently max out at 32 GB, and the blockchain might be that big 12 months from now. You can get yourself a crazy $10,000 server that is expandable up to 192 GB of RAM... but even many older consumer PCs now can hook up a HDD through (e)SATA and get 2 TB for less than $100. |
|
|
|
|
That is the intention. Unless I misunderstood you. The goal isn't "This message has a valid signature!" It's "This message has a valid signature from address 1xyZaQb". Or rather: "This message has been signed by the same person who sent you 42.83 BTC yesterday." If you have previously transacted with someone, then you know what address you're looking for. I agree, it's easy to be misused/misunderstood by people who don't understand what they're doing, but that also doesn't mean it's useless.
The use cases I imagined were anonymous, paid services. You can use signed messages from the funding address to authorize requests to your account with that service. They don't care who you are, they only care that the same person that funded that account is signing the message.
Am I missing something?
|
|
|
|
It's probably a seriously non-trivial thing to do, code wise. Mostly the reason I was curious is that this kind of update would effectively double the hard drive demands of bitcoin since you'd have the 11.9 GB of the blockchain that bitcoin-qt manages, and the (presumably also) 11.9 GB of space that Armory would require from what you mentioned earlier. 24 GB is kind of a lot of space just to be able to keep Armory running happily, even in the era of hard drives with a lot of space.
2.2x the blockchain size is a lot of space especially when the blockchain is 50 GB. But if you're going to go put 128 GB of RAM in your server, it'll be a lot cheaper to just buy a single 2 TB HDD for $80 which will sustain you for another year or two even at absolute maximum blockchain growth. Also, the alternative is that you only hold 1x the blockchain. Obviously, it's less than 2.2x, but it's the same order of magnitude, which means if 2.2x is enough for you to be concerned, 1x is still a lot. A workaround that doesn't involve any work for me: make yourself a RAM disk and put all the data on there. It should be fast as hell. But of course, everything goes poof on a power-cycle. As I said, I'll think about how it might be done. Especially if DB performance becomes a real issue. But I might wait until that happens before I put too much effort into the RAM solution. |
|
|
|
Got it! The error was misreported making me think it was a problem with python-twisted, but it was a problem with a the zope.interface module which is used by python-twisted. The "zope" module doesn't have an __init__.py file and py2exe can't detect it to put it into the exe bundle. The solution was to make an empty __init__.py in the C:\Python27\Libs\site-packages\zope directory after installing zope. That's it! Will need to remember to put that in the build instructions... 248 MB RAM usage on Windows. Solid. I guess it's still high for a "regular" desktop app, but it's nothing out of this world anymore  Importing and sweeping appears to be working correctly. Wallet restore -- it works, but you have to restart Armory, or do it in offline mode then go online. There's also some important updates to the backup system that needs to put in before anyone goes and uses it. So all that is in the works tonight and tomorrow, then I'll create a standalone executable (signed) that people can use for pre-testing and funds recovery. Should be in the next 48 hours. Andy (currently my first and only team member) is helping setup a new Windows installer (using NSIS) that will Do The Right Thing when it installs Armory -- no more mysterious errors that require uninstalling and reinstalling Armory. It will also have more installation options. And it will look slick |
|
|
|
The bad news is that the process of creating a .exe file is failing, and may take a bit of work to fix. py2exe has given me quite a bit of trouble in the past, and when I did get it working I had no idea what I did.
Would cx_Freeze help here? EDIT: Also, pyinstaller might be an option. cx_Freeze is an option. But py2exe has been pretty darned reliable once I get it working. Every Windows release I've made since Armory v0.5 has used py2exe and I'm happy with it. And of course, it's already integrated into my build system. If I'm desperate, I may investigate other freeze-app options, but I think I just need to figure out once and for all why py2exe is not behaving the same on all my build systems. |
|
|
|
I'm glad to hear the Windows build went through properly.
Regarding the speed issue and LevelDB: I suspect it's due to the implementation of atomic types and routines used in leveldbwin. That project is made for msvc 9 and 10, which don't support atomics and as such rely on full memory barriers and software mutexes, which are considerably slower than atomics. LevelDB is natively a C11 POSIX library.
I am going to try building the port folder on msvc11, with native atomics support. As I said before, I suspect compiling this part is all it'll take to get any version of LevelDB to build properly.
Regarding py2exe: I have no experience with Python, however Windows development is all about DLL compartmentalization, i.e. maintaining the armory core and the Python GUI part separately. I didn't get the impression that this is what SWIG does. I'd assume if there was a way to simply link the Python code to DLL binaries, it would considerably simplify the py2exe part, by limited its scope to the GUI code and an exporting header of sorts. Then again I may be totally out of my league and talking out of my a**.
The py2exe thing is not your problem. Definitely mine. And it's not related to the .dlls, I have all that under control. It's that py2exe bundles up a working python project, and all its dependencies into a standalone directory with an .exe file. I assume it embeds the python interpreter in there. Technically the .exe works and links properly, but py2exe is not bundling some of the needed python libraries. Armory successfully loads all the SWIG modules and all the related .dlls, but can't finish initializing because the py2exe never put the python-twisted libraries in the embedded environment and I get a python error that twisted is not found. At the moment, I'm going to see if I can manually inject the twisted libraries into the output library.zip (which holds all the python dependencies). If that works, it will give me an option for producing Windows .exe until I have time to fight py2exe. |
|
|
|
I have a question about the upcoming RAM-reduction update. Will there be any option for people to turn off the more hard-drive intensive version of Armory and keep the RAM-intensive version for people who have a lot of RAM? I don't know if this would be a major pain to code or not, but it'd be a nice feature to have.
I guess, for now you could just keep using the old version. But going forward, it will be kind of tough to do what you just suggested. However, there will be lighter-weight modes implemented that will use less RAM and HDD, though, it might have slightly watered-down functionality (not being able view arbitrary transactions or fees on some incoming tx). I'll keep it in mind, though. I'm sure there's lot of server applications where the user has more than enough RAM, and would prefer the performance. At the moment, while there's only one version of Armory that everyone uses (no super-node, regular-node, lite-node split), RAM is much more scarce than HDD space. But these kinds of things are great to keep in mind so I don't burn any code bridges if there's a chance they will be in high demand in the future (when I've got different modes). |
|
|
|
Updates: Linux: The app technically works, but it's got some serious usability bugs. Importing, sweeping and restoring wallets causes the app to freeze until it finishes. It also frequently freezes when new blocks come in or it checks for a new version. Quite a few other quirks, too. But all these issues are related to usability -- the core functionality seems to be in excellent shape! The app successfully saves its entire state between loads, and only takes about 10-30 seconds to startup and pickup where it left off (longer if you haven't loaded it in a while and Bitcoin-Qt/bitcoind needs to catch up). Also, building and scanning (on all OS) is much slower than I was expecting. Again, it's only a usability problem, and I am aware of multiple places that I missed optimizations that would improve all this. I plan to dig into those when I get out a testing version. Windows: The good news is that I got everything compiling and working in Windows using native python (thanks goatpig!). I haven't gotten very far into Windows testing, but so far it appears to work the same as the Linux version though even slower (probably related to the ancient version of LevelDB that i hope goatpig will help me figure out how to upgrade for another 1 BTC ). The bad news is that the process of creating a .exe file is failing, and may take a bit of work to fix. py2exe has given me quite a bit of trouble in the past, and when I did get it working I had no idea what I did. Therefore, it technically works on Windows, but only if you install python and like eight different python packages. When I do finally get py2exe working, I can put out a pre-testing-testing version that should let people get access to their funds but not use it for regular use (it's going to be very rough around the edges). For those inclined to compile on Windows, I can tell you that part of the process has been restructuring everything. All the old MSVS 2005/2008 projects have been destroyed, and rebuilt with MSVS 2012 Express. This makes it free to compile (if you register MSVS w/ Microsoft), but it's still going to take a bit of tinkering. If someone wants to try it, I can post a list of packages that need to be installed. OSX: If anyone wants to help with this, please let me know. The new LevelDB stuff needs to be compiled & tested on the OSX side, and I have no idea how much of a PITA it is. Perhaps Red Emerald is in good shape to try this out. Great! Thanks for the update. Waiting for this with much anticipation (OSX and Windows). I forgot to mention that RAM usage on Windows looks to be about the same as Linux. 600-700 MB while the DB is building, then about 300 MB under normal operation. In exchanges for the improved load time and RAM usage is 14 GB of disk space used for databases (which will be reduced in the future, but this was the easiest implementation for now). So it's only a tad more than Bitcoin-Qt itself uses, which is about 11-12 GB currently (i.e. the storage efficiency of all that data in Armory's LevelDB database is only about 10-20% overhead). |
|
|
|
Updates: Linux: The app technically works, but it's got some serious usability bugs. Importing, sweeping and restoring wallets causes the app to freeze until it finishes. It also frequently freezes when new blocks come in or it checks for a new version. Quite a few other quirks, too. But all these issues are related to usability -- the core functionality seems to be in excellent shape! The app successfully saves its entire state between loads, and only takes about 10-30 seconds to startup and pickup where it left off (longer if you haven't loaded it in a while and Bitcoin-Qt/bitcoind needs to catch up). Also, building and scanning (on all OS) is much slower than I was expecting. Again, it's only a usability problem, and I am aware of multiple places that I missed optimizations that would improve all this. I plan to dig into those when I get out a testing version. Windows: The good news is that I got everything compiling and working in Windows using native python (thanks goatpig!). I haven't gotten very far into Windows testing, but so far it appears to work the same as the Linux version though even slower (probably related to the ancient version of LevelDB that i hope goatpig will help me figure out how to upgrade for another 1 BTC ). The bad news is that the process of creating a .exe file is failing, and may take a bit of work to fix. py2exe has given me quite a bit of trouble in the past, and when I did get it working I had no idea what I did. Therefore, it technically works on Windows, but only if you install python and like eight different python packages. When I do finally get py2exe working, I can put out a pre-testing-testing version that should let people get access to their funds but not use it for regular use (it's going to be very rough around the edges). For those inclined to compile on Windows, I can tell you that part of the process has been restructuring everything. All the old MSVS 2005/2008 projects have been destroyed, and rebuilt with MSVS 2012 Express. This makes it free to compile (if you register MSVS w/ Microsoft), but it's still going to take a bit of tinkering. If someone wants to try it, I can post a list of packages that need to be installed. OSX: If anyone wants to help with this, please let me know. The new LevelDB stuff needs to be compiled & tested on the OSX side, and I have no idea how much of a PITA it is. Perhaps Red Emerald is in good shape to try this out. |
|
|
|
Give it another shot when I get the new version released. You will probably be pleasantly surprised by it.
Is there an ETA? OR "when it's done"?  I just got the new branch working in Windows, finally. And a lot of issues I was having are resolved. This means I can probably have a pre-testing version available in the next day or two. However, I wouldn't recommend it for regular use, since it will be pretty rough around the edges. But it will be sufficient for getting your coins out if you've had them stuck in Armory for a while. Of course, I keep making statements like that and I haven't been able to stick to them. I really should say "next week" and then everyone will be happy when it's Saturday I'm not going to rush it, but all the stuff really is working quite well, including the cool new backup center... |
|
|
|
Unfortunately I'm in the middle of switching over to Electrum now. Armory maybe loads half the time and when it does it takes about an hour to get a proper balance. Not sure what's up with this wallet, but it's more work and time than I really have to spend. I double click on Electrum and it loads/syncs in about 30 seconds, and doesn't need huge amounts of memory or speed to work. I'm not bashing Armory, I actually wish I could still continue to use it, but the past 5 times when I needed access to my BTC I wasn't able to access them. Right now my index got corrupt "somehow" and has to re-build itself so I'm letting that run over night, then just sending my BTC to my Electrum address. Too bad, the potential and security was there but the reliability wasn't. Good luck with future upgrades.
Unfortunately, the blockchain corruption is probably a Bitcoin-Qt problem, which I don't have much control over. Nonetheless, you do avoid all that with Electrum. But rebuilding probably won't fix it. You have to add checklevel=2 to your bitcoin.conf or upgrade to 0.8.5. Or maybe it really is Bitcoin DB corruption... Give it another shot when I get the new version released. You will probably be pleasantly surprised by it. |
|
|
|
Can we perhaps expect 3d printed wallet backups from some new version of Armory? Might be worth looking at the materials properties of the various 3D printing substrates out there, see whether there's something with compelling durability.
It certainly would be easy to print a sheet of plastic with your paper-backup info either etched in it or extruding. That would be fairly durable, as well. Especially if you did it with the nylon filament which is like 16,000 PSI and stretches over 100% before breaking. |
|
|
|
I'm curious to know if there is any push to improve the Armory interface? For a user like me it works just fine, but someone who is newer to Bitcoin, I could see how it could be very uninviting.
This is in our plans. One of the investors has a software company and is planning to contribute some manpower to redesigning it. Right now it uses all the vanilla PyQt buttons and widgets, etc. But it should be easy to subclass everything and make prettier versions of them (like buttons with images instead of raw text), which will make it look better. And also we will be redoing some of the dialogs and interfaces. It's just not high priority for me or my new developers, but it is part of our plan going forward as we try to implement a lite-version that is better tailored to new users. Ok. Any timeline of when that might get done? Working on some Armory video tutorials with someone to reduce the technical hurdle for people who want to use Armory. These will of course have to be updated as the interface changes. If I can get a very rough idea then I can kinda plan ahead. I would guess it won't be in the next two months. We have our plate pretty full, and we'd prefer to work out the higher priority stuff (like RAM reduction, new wallets, HW wallets) without dealing with the interface upgrades. Well, and training our new employees |
|
|
|
I'm curious to know if there is any push to improve the Armory interface? For a user like me it works just fine, but someone who is newer to Bitcoin, I could see how it could be very uninviting.
This is in our plans. One of the investors has a software company and is planning to contribute some manpower to redesigning it. Right now it uses all the vanilla PyQt buttons and widgets, etc. But it should be easy to subclass everything and make prettier versions of them (like buttons with images instead of raw text), which will make it look better. And also we will be redoing some of the dialogs and interfaces. It's just not high priority for me or my new developers, but it is part of our plan going forward as we try to implement a lite-version that is better tailored to new users. |
|
|
|
Nice logo. Only two monitors? Heh, I sorta had an image of you looking at five different OSes at once on different screens.
I'm tempted to buy a Maker's Bot 3D printer some day. They sound like they work pretty well.
Three monitors actually. I paid extra to get the 1920x1200 resolution versions, too Also, you don't get a photo of me looking at all the VMs, but this screenshot should captures something very similar  That's why I have 32 GB of RAM |
|
|
|
You have to indicate both header and lib folder to msvc unless you install a pay version. You can register these folders globally in msvc options rather than just link them to each of your projects. Not sure how it's done is vc11 express. Ima look it up
It actually complied the leveldb.lib without linking the lib folder to the project. I only included the header and it was happy. That's odd, i had to link atl.lib to it. Regardless, as long as it's built, the rest is irrelevant. I selected "Use of ATL -- Yes". Maybe it figured it out based on that? |
|
|
|
You have to indicate both header and lib folder to msvc unless you install a pay version. You can register these folders globally in msvc options rather than just link them to each of your projects. Not sure how it's done is vc11 express. Ima look it up
It actually complied the leveldb.lib without linking the lib folder to the project. I only included the header and it was happy. |
|
|
|
C:\WinDDK\7600.16385.1\inc\atl71 -> this is my include folder for all header files
C:\WinDDK\7600.16385.1\lib\ATL\i386 -> this is where the libs are. I picked i386 cause leveldbwin only support x86. However x64 binaries and libs are available if you wanna try a x64 compile.
I'm curious about your install folder, namely its build version (mine is 7600.16385.1 as you can see)
Ugh! Why is Windows search so terrible?! I did a full "search" of the C-drive and it came up with nothing. But I just followed the path you mentioned and I found it. Alright, I'll manually add that to the "Additional Include Directories" and see where that gets me. |
|
|
|
|
@ goatpig
I am trying to follow your solution on Windows 7, 32-bit. Everything has been smooth except for ATL. I installed the 7.1.0 WDK, but it still can't find atlbase.h. I have searched the entire harddrive looking for it, but can't find it. I reinstalled the WDK and rebooted and it's nowhere to be found. I did some googling and found posts telling me to install the 7.1.0 WDK... I wonder if it has to do with 32-bit OS? I can't imagine the header file would, but I'm grasping at straws here... any advice?
|
|
|
|
|
Show Posts
