Armory crashes for me also as soon as it gets 100% sync'd with the network. Is there a debug log I can send the devs?
This is the win7 crash notes for what it's worth.
Are you syncing with a wallet loaded? I get a crash on Windows 7 pretty much as soon as I try to start the program, with the testing version.
0.90-beta runs fine for me on Windows 7.
Rebuild your DB. We use a different leveldb block size in this version and that can mess up existing DBs. I totally forgot about that! Yes, we modified some DB parameters to improve performance of building and scanning, and it's necessarily incompatible with the old databases. You will have to use "Help"->"Rebuild & Rescan Databases" |
|
|
|
Use "File"->"Export Log File" and send the output as an attachment to support@bitcoinarmory.com, along with a description of the problem. Even something simple like "Armory does not start unless I delete the databases first" is enough for us to know what to look for. |
|
|
|
The offline bundles require the exact version Ubuntu to match the bundle. I would've expected Kubuntu and Xubuntu to work, but I've had reports of both of them failing. If you really want to make the dependencies work for your debian-based distro, you can use the package manager on the offline computer: try to install the package through Synaptic, it will mark all the appropriate depedencies for download, then you can you go to File->Generate Offline Download Script. Take the script to your offline computer and double-click it: it will download all the deb files you need which you can take back to the offline computer and either install from the command line, or using a related option in the Synaptic file menu. If not, I recommend you just download the correct version of vanilla ubuntu. I haven't heard of any problems with that, except with the 12.04-64bit bundle, which throws a bunch of cryptic errors, but does work (just click through the errors and run Armory, it will work). I personally recommend the 12.04-32bit bundle, just because you have no need for 64-bit on the offline computer. I think we'll have a 13.10 offline bundle for the next release, too -- in addition to a Raspberry Pi build  |
|
|
|
Picobit, just curious, what happens when you do a plain paper backup? I admit that I didn't do a lot of test prints at home. (Time to invest in a cheap laser printer, I guess.) That said, my printouts worked fine, but it's certainly possible I missed something or users are subject to conditions that don't apply to me. Oh, and which version of OS X are you running? I did all my test prints on 10.9.1.
Hi, I am running OS X version 10.9.1. It looks like a stability thing - now I cannot reproduce the lock-up, but in stead I can reach the OS X print dialog sometimes, sometimes I get a crash along the way. When I reach the Print dialog it is hit or miss whether it is responsive or not. I get random crashes without anything appearing in the log file (I monitor it with 'tail -f'). We have previously had some test builds with this instability, I think it is related to a bug in Qt, probably building on OS X 10.8 is a workaround. There seems to be something horribly wrong with Qt on OS X 10.9. :-( Yeah, Qt4 is a bit of a mess, especially on Mavericks. (You should've seen the builds before my workarounds were implemented. Yuck!) We're looking into solutions and workarounds. Oh, and just curious, did you run Alan's build or roll your own? If the latter, try Alan's. I believe it was built under 10.8. If you're still seeing stability issues, let me know. Mine was built on 10.9. I meant to do it on the 10.8 VM, since it supposedly more reliable. But I was in a hurry before I left town, and totally forgot to boot the VM. When I get back I'll try a 10.8 build |
|
|
|
alright no more need to worry, it's now started to work after preparing databases...
I've restarted to see if it continues to work, if not i'll let you know. Thanks for the fast support so far.
Great. Hope it's a smoother experience. Still would be good to know what version of OSX you are using. Also, could you test the paper backup printing? That was something that was causing the most crashes for users in 0.90 |
|
|
|
Still doesn't work for me...just opens and crashes on "Preparing Databases" even when I restart.
What version of OSX are you on? And can you please send the two log files to support@bitcoinarmory.com |
|
|
|
Even if an attacker has access to my life I want to make it as difficult for them as possible. You have a lot of nifty solutions for paranoid users and I thought this would be a good complement.
In the meantime I suggest that users who want a little bit of extra security when it comes to the SecurePrint feature, to only write the code down on as many fragments as it is necessary, i.e. N - M + 1 fragments. For example in a 5-of-6 fragmented backup configuration you only need to put down the SecurePrint code on 2 (=6-5+1) fragments and then put these fragments in the locations you deem most secure.
The SecurePrint code is just another piece of data that is needed to unlock your fragmented backups. You can do what you're saying, or you can just recalibrate your decision of M and N (in M-of-N) to meet your security-vs-redundancy needs. For instance, use 4-of-7 instead of 3-of-5 and then you haven't destroyed your ability to recover it if particular fragments are not recovered. Or don't use SecurePrint at all and write all data down by hand from the computer screen. There's nothing wrong with that. |
|
|
|
I just uploaded a new Windows standalone bundle. Apparently I missed a couple things needed for XP support. Previous posts about this: Feature list for new 0.90.99-testing versionBundles for WinXP, OSX, RPiI have added the hashes of these downloads to the first post as well. It's signed with my non-offline key (the key I use for email; 0xFB596985). You can grab it from any keyserver and it is signed by my offline key, along with the GPG keys of all employees -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
05a8e5f21b8db9d693dee0ce7a007edccef25258b5de53560360b0e0bda8add2 armory_0.90.99-testing.osx.app.tar.gz
d8213f97cf4e1db7cd9b3afb2c41b63e9312cdb61203c502f337bb99ebe28a1e armory_0.90.99-testing_rpibuild.tar.gz
ea80c38c0dbce23a9d5e2bbbf4de29a0794d6d5f52168330b72ab6b4cda4e545 Armory_Standlone_0.90-99.0-testing.zip
05a66b6d69544573b5bc3678168ad95e599fa23108174ceac219a904c0d18b14 raspberrypi_armory_0.90.99-testing.tar.gz
2151fdb75b00429dbab73d4e93d86c70bc65c76d37eeb147e01c3256eb85c2d5 rpi_dependencies_maybe.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJTB7cKAAoJEBHe6b77WWmFhW8QAI62qtKIncCzTZgof6xbGiN6
0+AMksSS3kFaFqcXdzMKAt3YVdD8UOIqxEG77XSDunPAEQ/Z9VDobUqi0YmPcdGs
wxQdbgAC1P9/f1XLx+7SrUUt8dI1AJaqIXnSH3clvNLFAgYCAuf8CWLXdhGxfpwO
/OUhKOLrIxMhi/722TffdsHQkUmtDI8/X4FefbxltXDDiVZlXAe9jfG+xsTOeFHz
kmVT1DzV2HcWPnb+0+r8N8GoG/NQthMRJlYuUMHaMVCgBTlN4XsvifEYwkhhSeIS
ttzW0X2z2061pNXzL6FEZEGg+qRIQ/Zfk0xKTueOJLAO/2B/38ouVKc7Nvm9MNFE
wK1ocdFZHPFE2EIYpYpQSm3T5Psnc2aRD7IoSwH2qdTB4YsJMikTagxVTEOfXHx/
JAjQVy7UBJ5iDi5+AbDQ0VWqe3HI7ipeIhnus6AIaSOIVfdQJ6dilD/Qf7oEvds2
y+p9XrhpgzwmgMUIg3vg5KxmFzId7lthBILeB/VbuDEWkXfNtCtzscrJk1YzWrT0
s2yekItbhBgR/COuVfxoTA15B+d8yygHdjcDMynilTtkyqYha2JoPVKiH2wCx8Gr
gegNwG+VzZlvXHAcXNKYcImsa+zdVVnb4/U19vos1W0aBsNdTPenjlVT7jfCfNWA
BstQHerKi3SlOtK87yhl
=LJDD
-----END PGP SIGNATURE----- |
|
|
|
Windows! I couldn't get the installer working correctly (it needs some tweaking), but that's fine because you don't want to install this anyway. This is just a standalone bundle which you can unzip anywhere and double-click the ArmoryQt.exe inside it Theoretically it should work with XP, and with unicode/non-English pathnames. But I am in a rush to get this out before I leave, and I will have to do all the appropriate tweaks when I get back next week (if it doesn't work). Please post any complaints and goatpig will have it all sorted out for me when I get back Windows 0.90.99-testing: https://s3.amazonaws.com/bitcoinarmory-releases/Armory_Standlone_0.90-99.0-testing.zipAlso, just so you can get everything from one post: OSX 0.90.99-testing (built please try on multiple OSX versions and let me know): https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.90.99-testing.osx.app.tar.gzRPi Binaries 0.90.99-testing (not the offline bundle): https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.90.99-testing_rpibuild.tar.gzI think I figured out the dependencies issues for RPi: please try on a fresh RPi running Raspbian offline. Install the following dependencies, then attempt to run the build above: https://s3.amazonaws.com/bitcoinarmory-releases/rpi_dependencies_maybe.tar.gz
Seriously: sorry for being rushed and not being able to test this stuff more before pushing it out. But I desperately need to get eyes on this release before I go on vacation so I've got a nice queue of things (and complaints) to address when I get back. Thanks for being patient, and I hope there's some positive comments about these testing versions to along with the complaints NOTE: A list of things in this new testing version is posted about 10 posts up -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
05a8e5f21b8db9d693dee0ce7a007edccef25258b5de53560360b0e0bda8add2 armory_0.90.99-testing.osx.app.tar.gz
d8213f97cf4e1db7cd9b3afb2c41b63e9312cdb61203c502f337bb99ebe28a1e armory_0.90.99-testing_rpibuild.tar.gz
ea80c38c0dbce23a9d5e2bbbf4de29a0794d6d5f52168330b72ab6b4cda4e545 Armory_Standlone_0.90-99.0-testing.zip
05a66b6d69544573b5bc3678168ad95e599fa23108174ceac219a904c0d18b14 raspberrypi_armory_0.90.99-testing.tar.gz
2151fdb75b00429dbab73d4e93d86c70bc65c76d37eeb147e01c3256eb85c2d5 rpi_dependencies_maybe.tar.gz
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQIcBAEBCAAGBQJTB7cKAAoJEBHe6b77WWmFhW8QAI62qtKIncCzTZgof6xbGiN6
0+AMksSS3kFaFqcXdzMKAt3YVdD8UOIqxEG77XSDunPAEQ/Z9VDobUqi0YmPcdGs
wxQdbgAC1P9/f1XLx+7SrUUt8dI1AJaqIXnSH3clvNLFAgYCAuf8CWLXdhGxfpwO
/OUhKOLrIxMhi/722TffdsHQkUmtDI8/X4FefbxltXDDiVZlXAe9jfG+xsTOeFHz
kmVT1DzV2HcWPnb+0+r8N8GoG/NQthMRJlYuUMHaMVCgBTlN4XsvifEYwkhhSeIS
ttzW0X2z2061pNXzL6FEZEGg+qRIQ/Zfk0xKTueOJLAO/2B/38ouVKc7Nvm9MNFE
wK1ocdFZHPFE2EIYpYpQSm3T5Psnc2aRD7IoSwH2qdTB4YsJMikTagxVTEOfXHx/
JAjQVy7UBJ5iDi5+AbDQ0VWqe3HI7ipeIhnus6AIaSOIVfdQJ6dilD/Qf7oEvds2
y+p9XrhpgzwmgMUIg3vg5KxmFzId7lthBILeB/VbuDEWkXfNtCtzscrJk1YzWrT0
s2yekItbhBgR/COuVfxoTA15B+d8yygHdjcDMynilTtkyqYha2JoPVKiH2wCx8Gr
gegNwG+VzZlvXHAcXNKYcImsa+zdVVnb4/U19vos1W0aBsNdTPenjlVT7jfCfNWA
BstQHerKi3SlOtK87yhl
=LJDD
-----END PGP SIGNATURE----- |
|
|
|
Hmm, good point. However, in the general case, a display cycling some 1-8 QR codes must surely be sufficient? I just aimed my phone camera at this QR code on Wikipedia, with some 1800 bytes, and it nailed it without blinking. I can't tell how many percent of transactions would be smaller than 6-7 kilobytes, but I imagine it would be the overwhelming majority. So while there may be cases where this mode of communication is not available, is that a reason to exclude it from the 95%-98% of typical cases? The problem is, when the time that you fall outside that 95%, you have to resort to another solution (such as USBs), which compromises the whole thing. We really need 100% in order to be useful. Is that really the case? The communication would be one-way, there's no need for ACKs as the receiving computer can read the sending screen until all codes have been read. No need for a two-way protocol. There's an operator there, after all, who is alerted to when the data transfer is complete in some way.
It's bi-directional. We need to transfer transaction data to the online computer, sign, then transfer the signatures off (though right now Armory expects the whole tx to be transferred off, but it wouldn't be difficult to change that). Nonetheless, if you have a lot of inputs on the signed transaction, transferring 20+ signatures will require multiple QR codes. We really need bi-directional video. And if it's two computers with two webcams, it can get confusing quickly, and lots of messy wires. Again, it's not that it's not doable, it's that it's not a clean solution. On the other hand, having two laptops facing each other might actually work, since the cameras are built-in. However, we have more resources on our team now... we may be able to prioritize it. Right now we have an audio cable solution in the works, which also utilizes an analog channel which should be pretty darned secure. But it's not ready yet. An audio channel is a clear improvement over a USB key, but still hijackable as a side channel in the dire case malware has found its way onto the computers: all operating systems I know of allow for multiplexing several simultaneous applications to/from audio. However, in the same vein, webcam access and screen real estate is exclusive to one application, giving an advantage to the operator knowing that Armory has exclusive control of the communications channel? I would argue that audio is not really hijackable -- there is basically zilch remote-code execution potential, assuming the offline computer is not compromised. We have to make that assumption because all bets are off, otherwise. There's a countless number of ways to get the keys off the offline computer if you assume arbitrary code execution there. On the other hand, assuming that only the online computer is compromised, there is nothing you can send over an audio channel that would induce code execution -- except for what Armory implements (or if you have some kind of voice recognition software running...?!). Armory can make that band very narrow, and it will require direct audio cable connection, not just being in the same room. We think it's an awesome solution, and will work well with mobile phones as well... But it might be a while before we get that implemented. We'll see how our priorities look after 0.91-beta is released. |
|
|
|
Personally, I think QR code video is a great solution. But that's significantly more challenging than simple QR codes. And so far, Armory doesn't have a utility for scanning even regular QR codes. It will have to be a robust solution, because there might be megabytes of data to transfer (could be fixed if we had something like SIGHASH_WITHINPUTVALUE). Also, I was hesitant to implement something that requires the user to have multiple webcams, and have their webcam drivers setup, and then try to figure out what to point where and when, and have wires everywhere. It's doable, but it's also not necessarily user-friendly. That doesn't mean we shouldnt' do it, it's just that it's not a perfect solution for a general purpose tool. I'd rather people use USB, than get fed up with something complicated they can't get working and forego offline wallets entirely. However, we have more resources on our team now... we may be able to prioritize it. Right now we have an audio cable solution in the works, which also utilizes an analog channel which should be pretty darned secure. But it's not ready yet. |
|
|
|
Don't forget, Windows needs it's icon back
And I thought, I am the only one who is missing that... Funny story about that: we tried 2 or 3 different things to get the icons to work. Py2exe, resource hacker, and I think one other. All of them had problems creating the icons and we spent a stupid amount of time trying to get it to work. We had finally decided we were just going to pay for a utility to do it -- so we got the trial version to make sure it works -- then we forgot to pay for it and the 30-day trial period ran out! Whoops -- this is why they didn't have icons, because we were getting an error on icon registration and didn't notice. Again, goatpig (our resident Windows expert) found a solution (without paying for anything), and it should be fixed in the next version |
|
|
|
Does the new version have a new database? If so, how to upgrade? Safe to just delete?
Can you publish change logs on the site? Also wallet file change log. And whether and how to upgrade. Also db upgrades.
In this case, nothing has changed. No need to rebuild unless your DB is broken. Wallets are the same. Etc. However, I did slack on putting up the change logs for 0.90-beta, but I'll make sure they are there for 0.91. For now, sine this is a testing version, you can just note the notes in my original post, maybe 8 above this one. |
|
|
|
Still getting an app crash when preparing databases.
(1) The "Help"->"Rebuild & Rescan Databases" option now works, even with thoroughly corrupt databases. Try that. (2) There's a bit more useful data in the log file. If rebuilding doesn't work, can you send us the log "File"->"Export Log File" or just look in armorycpplog.txt for some error messages near the end? |
|
|
|
The new OSX build script works like magic! If you are on Mac, you can try it out yourself -- I think you only need to install XCode and the command-line utilities...? Then cd into the osxbuild directory and execute "python build-app.py". But you don't have to... here's a test build from my 10.9 system: https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.90.99-testing.osx.app.tar.gzI meant to boot my 10.8 VM and build it there, as it's proved to be more compatible in the past, but I'm running out of time, and this will be a good test. Please try it out! |
|
|
|
|
Also, Armory's database can be reduced, but 0.90-beta was a pretty huge overhaul of the block data engine, and it was easiest to just duplicate it. Hopefully by 0.92-beta we'll be able to scale it down in size by an order of magnitude, and rely on bitcoin-qt to provide any data we might occasionally need that's not in the Armory DB.
Until then: yes, you need two copies.
If you have 60 GB, it's possible that you have double blockchain data because you tried dumping the blk*.dat files into an existing Bitcoin-Qt/bitcoind isntance, and it redownloaded the chain on top of it instead of bootstrapping off of it (I've seen a lot of people make that mistake, myself included). It sounds like a possible reason for your current situation, since it's almost exactly twice as big as it should be.
|
|
|
|
Here's a first shot at cross-compiling for RPi. I didn't get all the packages bundled yet, but maybe if you've already had it working before (and thus already have the dependencies), you could try this out for me. I have a few other things to do before I head out tomorrow, so I don't have time to setup my RPi. Otherwise I'll do it when I get back: https://s3.amazonaws.com/bitcoinarmory-releases/raspberrypi_armory_0.90.99-testing.tar.gzEDIT: Here's the package list: libqtcore4 libqt4-dev python-qt4 python-twisted libconfig-file-perl libqt4-designer libqt4-scripttools libqt4-help libqt4-test libqtassistantclient4 libqtwebkit4 libqt4-declarative libqt4-script libqt4-xmlpatterns libqt4-dev-bin libqt4-qt3support libqt4-sql qt4-linguist-tools qt4-qmake python-psutil python-pyasn1 python-sip python-crypto python-openssl python-twisted-conch python-twisted-lore python-twisted-mail python-twisted-news python-twisted-runner python-twisted-words python-twisted-core python-twisted-web python-twisted-names python-twisted-bin python-zope.interface python-pkg-resources EDIT 2: I just realized that the above tar.gz is the make-install'd version. I just tried to merge it into the way it would be right after you compiled it (no make install): https://s3.amazonaws.com/bitcoinarmory-releases/armory_0.90.99-testing_rpibuild.tar.gz(obviously, I need to improve this proces...) |
|
|
|
It's that time again... Testing time!Brought to you by the Armory team, this time. Yes, we have a team! A few guys came on recently and are still getting up to speed, but they're contributing, nonetheless. And even though they're not at full efficiency yet, I think we're finally moving faster than when it was just me by myself Version 0.91-beta (currently 0.90.99.0-testing, the testing branch) will not contain any groundbreaking features. However, it has dramatic stability improvements for all OS, and a whole ton of small-but-important things that improve the user experience. Here's the list, in arbitrary order (well, kind of reverse-chronological order): - Use --nospendzeroconfchange to not allow spending of any unconfirmed TxOuts (Armory already deprioritizes ZC change, but it's off-limits with this flag)
- Full P2SH support in send-BTC dialog, address book, tx info, etc
- WinXP support
- Proper unicode path handling (wallets will support unicode in 0.92-beta)
- No more choking on bad blocks written by Bitcoin-Qt/bitcoind
- Major improvements to OSX compatibility! (hopefully)
- Fixed fonts in OSX
- Bug reporting window
- Progress bars for long-running operations
- Better version notification system (will be implemented before release)
- Factory reset window -- including "Delete Bitcoin-Qt databases and re-download"
- Raspberry Pi offline bundle (process ironed out, will create test bundles soon!)
- Minimize-on-open (in settings)
- Wallets->"Recover Damaged Wallet"
- Wallet creation wizard
- Faster rescanning and rebuilding
- Better logic to prevent unnecessary rescans
- Better zero-conf tx handling
- Fee calculation fixes
- armoryd.py fixes and upgrades
- Multithreading improvements
- Code refactoring
A few points to emphasize:- Slowness and UI freezes should be mostly gone. It turns out that large wallets were choking on the number of zero-confirmation transactions on the network, combined with an inefficiency in Armory's handling of them. It should be dramatically improved.
- We now handle broken blk*.dat files more intelligently (produced by Bitcoin-Qt/bitcoind): It will pop up a warning if you are affected (instead of seg faulting). We believe that most of the problems people have experienced while syncing and scanning are due to this condition. . You can now do a "Factory Reset" which will delete the blk*.dat files and force Bitcoin-Qt to redownload it.
- Arbitrary rescans should be mostly gone. Unclean shutdowns or not. It will only rebuild or rescan if it detects problems with the database, or new addresses show up that have not been scanned
- Wallet consistency checks are now performed in the background on every load. You will see the progress bar at the bottom-left. If a problem is detected with your wallets, some information should pop up and you can use "Wallets"->"Recover Damaged Wallet" to try to fix it.
- armoryd.py has been upgraded (but still needs a bit more testing). We have a Python Scripting page to help people get into it, and devchanges.txt describes how developers can update their code to work with the changes between 0.90 and 0.91.
- OSX updates: No promises that this totally works yet, but we do finally have a [paid!] developer working exclusively in OSX, which means that it will no longer be neglected! He already found some issues with the prior build process, and thinks the next release will be dramatically improved. At the very least, the font issues on paper backups should be fixed
I am going to try to do a little more testing, probably followed by some tweaks. Then I'm going to attempt to do some testing builds for Windows, OSX, and Raspberry Pi! The RPi builds can easily be integrated into the release process, because goatpig helped figure out how to cross-compile it on my non-ARM build systems. Sweet!
I will start a new thread for this round of testing, as soon as I flesh out the last few details and get some of the non-Linux testing builds together. Unfortunatley, I'm leaving for a trip tomorrow -- I hope to get some of it out there before I leave, otherwise it will have to wait until late next week. If you are adventurous, you can help speed up the process by checking out the "testing" branch and banging on it a bit.
|
|
|
|
Personally, I feel a single confirmation should overrule it all, shouldn't it? My understanding is if it's got a single confirmation, and, that block isn't invalidated/orphaned, then, that transaction can't be taken back, or, am I misunderstanding?
You're probably correct, but I haven't spent much time thinking about it. Honestly, this isn't a common transaction type, and I just wanted to make sure it wasn't totally neglected, without opening up any holes. If this becomes more common, I'll simply implement the logic correctly, the same way Bitcoin-Qt does. |
|
|
|
|
If your terminal is in the same directory as the .deb file, then you will not get that error.
Are you downloading the correct file? Does it have .deb extension? You can verify if the file is in the directory by typing "ls" (that is L, S), and you should see it in the list that is printed. cd your way into the directory where it is located and run the dpkg-sig command again. You could try typing the full file name instead of "*.deb" but that really shouldn't make a difference.
|
|
|
|
|
Show Posts
