I keep getting this error when I want to start Armory. It basically forces me to restart my computer to get rid of it. And no, Armory nor bitcoind is running. Thank you for any assistance with this. Also, I can tip for assistance with this.  Make sure you kill all instances of Python before trying to rerun Armory. |
|
|
|
too -- in addition to a Raspberry Pi build  Grand, but, will it be only for Debian or for other distros as well? I know the actual source (last I tried) got all pissy that I couldn't use .deb files. Currently we only distribute binaries compatible with Debian and its variants. Same for the R-Pi package, it's Raspbian only. |
|
|
|
This is at the end of armorycpplog.txt: Log file opened at 1393379181: C:\Users\username\AppData\Roaming\Armory\armorycpplog.txt
-INFO - 1393379211: (..\BlockUtils.cpp:1579) Set home directory:
-INFO - 1393379211: (..\BlockUtils.cpp:1601) Set blkfile dir: C:\Users\username\AppData\Roaming\Bitcoin\blocks
-INFO - 1393379211: (..\BlockUtils.cpp:1611) Set leveldb dir: C:\Users\username\AppData\Roaming\Armory\databases
-INFO - 1393379211: (..\BlockUtils.cpp:1567) SetBtcNetworkParams
-INFO - 1393379211: (..\BlockUtils.cpp:3628) Executing: doInitialSyncOnLoad_Rebuild
-INFO - 1393379211: (..\BlockUtils.cpp:3653) Number of registered addr: 485
-INFO - 1393379211: (..\leveldb_wrapper.cpp:399) Opening databases...
-WARN - 1393379211: (..\leveldb_wrapper.cpp:303) ***LevelDB Error: IO error: C:\Users\username\AppData\Roaming\Armory\databases/leveldb_headers: Bad file descriptor
-ERROR - 1393379211: (..\leveldb_wrapper.cpp:453) Failed to open database! DB: 0
Armorylog.txt doesn't have anything that looks unusual, but I can send it to you if you need more info. Delete this folder yourself: C:\Users\username\AppData\Roaming\Armory\databases Then try again. Edit: Found a bug related to this and fixed it. Pull the testing branch or wait for the next testing build to try it out. |
|
|
|
Made a paper backup and tested it when invited to do so. "Bad Backup!". I've triple-checked that I entered all the letters correctly. Guess I might as well delete this wallet and create a new one - I haven't used it yet. The "new user experience" has been less than ideal.
Bad backup means the internal error checking on the backup is erroneous. That's some deep data corruption. I have never ran into this. You should make a new wallet indeed, and make sure to test your backup before sending funds to the wallet. You pulled the master branch. You should be pulling the testing branch right now. Browse to the Armory source folder and do this: git fetch git checkout testing make clean make |
|
|
|
|
Some Python side crash halted everything. Do you have a wallet loaded and was the consistency check running before when the progress bar hit 100%? Progress bars come with a label, what did the bars say. It's surprising that you have 2 of these running. Try to create your wallet offline and see if that completes.
Btw, which branch did you build from?
|
|
|
|
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. |
|
|
|
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. Good point, conceded. It's the one weak link in the chain that you want to eliminate, and on second thought, this is sound security practice. It's bi-directional. We need to transfer transaction data to the online computer, sign, then transfer the signatures off Again, conceded. I pictured two one-way sessions, where an operator would have to change directions (pretty much like the USB key communications today), but the ability to communicate optically in the first place enables one single session which starts with the transfer of the unsigned transaction and ends with the broadcast of the signed transaction. For extra sci-fi points, there could be audible notifications in a synthetic voice as to what stage the session is in. On the other hand, having two laptops facing each other might actually work, since the cameras are built-in. Good thinking! I did a short test here, and a laptop plus a desktop computer is also feasible, as long as you have a webcam on top of the desktop computer monitor. You'll have to hold the laptop in place, but still. 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. I'm going to be a total pain in the ass and disagree with that assumption. I know from myself that I really hate it when people do this, but hear me out and evaluate the thinking here: Experience with security practices dictate the assumption that your code is the only piece that hasn't been compromised - that yours is the "last piece of code standing". If the Armory binaries have been corrupted through real-time code modification, then the game is over, but there are many cases where malware could have gotten into the offline computer without the ability to affect Armory. So if Armory is compromised, the game is over. But I would take the position that the offline computer can be compromised in userspace without Armory getting compromised, and even if malware is running all over userspace, Armory could still be very able to perform its task securely. (Of course, if malware makes it to root or kernelspace, the game is over, but that's because of its ability to subvert the Armory I/O or binaries in that case.) Also, remote code execution isn't the only vulnerability to watch out for. The offline computer can have had malware planted on it through a number of bad means - everything from USB-level exploits through an adversary physically gaining access to the machine and maybe installing a keylogger, sniffers, etc., maybe even in hardware. It's not just remote execution you want to prevent - you want to prevent any ability for the offline computer to communicate anything but signed transactions to the outside world. Having a keylogger or other sniffer is bad, but it may not mean any damage in practice, if and only if those pieces of malware are unable to report their findings to the outside world. So I'm equally concerned about the elimination of known potential back channels from possible malware on the offline machine. If an Armory user isn't familiar with sound security practices, it could even be code running in a different, deliberately installed user account that is the adversary. Again, thank you for a great piece of software, and thank you for considering the idea of optical communications. I appreciate that you're already considering sonic communications as a way to mitigate the original problem. Cheers, Rick My understanding is that we want to eventually offer both video and audio data channels. The question is priority and resources. So as it comes, audio will be first, then we'll have someone looking into animated QR codes. As for the adversary scenario: a lot of Armory's code is in Python. It would be trivial for an adversary to compromise it. And to respond to bitpop as well, warding against this kinda of vectors is not only very difficult, it's out of Armory's scope. Armory functions on the assumption your offline signer is clean. For protection against an adversary, my recommendation is to use 2-of-2 or 2-of-3 signing schemes involving a hardware wallet. This provides multiple factors, different platforms and protected data execution in case of the HW wallet. Hopefully, we plan on moving towards that direction too. |
|
|
|
|
We could add something like that easily to the new wallet recovery tool. I'll run it by Alan. As for the server part, there are some plans for this kind of functionality (syncing wallets)
With the wallet recovery tool addition in 0.91, a change has been made to wallet restoration (from paper). If the wallet you are trying to restore is already loaded, instead of refusing to process any further, Armory will now rip all meta data from the currently loaded wallet to add to the restored one.
This means you can use a digital copy of any of your plain/encrypted/watching only wallets, load it in Armory, then restore from paper on top it, and have all your comments, labels and proper chain length added to the restored wallet.
|
|
|
|
what github branch should we use if we want something that is mostly stable but contains the latest bug fixes?
EDIT: tried "master" branch seems to work fine
Master is only updated with code you'll find in release packages. We have a team of several devs now and each and every one keeps their changes in a dedicated branch until they are stable enough to be merged into the dev branch. That being said, the dev branch is not guaranteed to be stable at any given point in time. The testing branch is more stable but gets updated way less. |
|
|
|
|
The part of the log you are showing carries no information pertaining to this bug. This is a known bug with Armory and we're bundling the fixes for the upcoming release. Test builds have been posted recently so try your luck with those.
|
|
|
|
-INFO - 1392041012: (..\BlockUtils.cpp:3690) Reading all headers and building chain...
-INFO - 1392041032: (..\BlockUtils.cpp:3695) Total number of blk*.dat files: 115
-INFO - 1392041032: (..\BlockUtils.cpp:3696) Total number of blocks found: 285111
-INFO - 1392041032: (..\BlockUtils.cpp:3708) Getting latest blocks from blk*.dat files
-INFO - 1392041032: (..\BlockUtils.cpp:3709) Total blockchain bytes: 15,322,661,233
-INFO - 1392041032: (..\BlockUtils.cpp:3715) Parsing blockchain file: C:\Bitcoin\blocks/blk00114.dat
-INFO - 1392041032: (..\BlockUtils.cpp:3812) C:\Bitcoin\blocks/blk00114.dat is 33,554,432 bytes
-INFO - 1392041096: (..\BlockUtils.cpp:3729) Processed 6 raw blocks DB (64 seconds)
-INFO - 1392041099: (..\BlockUtils.cpp:3758) Starting scan from block height: 0
-ERROR - 1392042812: (..\StoredBlockObj.cpp:1063) Cannot get tx copy, because don't have full StoredTx!
Anyone know how to reload the "full StoredTx" ?
Botched block in the DB. Usually rebuilding the Armory DB is enough. Worst case scenario you'll have to delete your copy of the blockchain and redownload it |
|
|
|
Any plans to add an option so that unconfirmed change is not spent? There are pulls in github to add similar functionality to the QT client. The fact that Armory favors spent over unspent means it is less of an issue unless the wallet has no/few confirmed outputs. Do you agree users should have the option of disabling this potentially undesirable behavior?
My understanding of manual coin selection in Armory (in expert mode) is that only spendable (unspent Tx outputs with confirmations) can be selected. In general, coin selection in your average wallet prioritizes lower fees, so any confirmed UTXO will take priority over a zero conf. The only real use case where a client may output a zero conf txn chain is when the wallet only holds very few (usually 1) UTXOs. The work around to this would be to have the wallet client split change into several UTXO once in a while. A fine line can be found between blockchain bloat and usability. Under these circumstances ZC chaining can be turned off by default with little disruption. We are considering adding this to Armory, although it still needs in depth discussion and reviewing. As for services accepting ZC txn, they need to check the transaction isn't being chained off of another ZC, instead of trying to cut corners. Maleability isnt the only vector to abuse chained ZC txn. A short term solution would be to increase fees for txns with deliberately oversized unsigned components. As long as the mining pools update to that, all mutated transactions would become invalid and reduce this vector to attackers with mining power, until the core devs figure if they want to use a hard fork solution. |
|
|
|
|
The BDM issue means Armory's backend is hanging somewhere while processing blockchain related data. The BDM stops responding and the issue trickles down into Armory's operations and will make it crash eventually.
You could always try to vm ubuntu and run Armory from that, see if the issue reappears. How much RAM is Armory using before it crashes? And is it maxing a CPU core?
|
|
|
|
|
The coins have been received regardless of whether you are trying to get Armory synced or not. Coins are sent through the blockchain. Syncing Armory is essentially reading the blockchain, so it is only relevant in order to monitor your balance and to send coins from Armory.
|
|
|
|
|
Need more information than this. Describe your use case, give us some RAM usage stats and a log files (include the cpp log too)
|
|
|
|
Request: Would it be possible to set up a recurring transaction in Armory? I am not sure this functionality has been implemented yet in any wallet. (I think coinbase has it though, but its a web wallet). This would be fairly useful to me and perhaps many others.
This kind of feature is a lot more complicated than it sounds. Possibly as an add-on on top of plug-in modularization, but nothing in the near future if that's what you're looking for. |
|
|
|
anyone about the double storing of the blockchain?
0.90 introduced a new implementation for blockchain scanning that relies on a dedicated DB. It was originally developed only with the "full blockchain" approach. Lighter versions are on their way, rest assured. |
|
|
|
|
Show Posts
