This release is total fucking bug-filled trash. The devs have shifted their focus from the common bitcoiner to the corporate "enterprise" cocksuckers. They know where the money is.
I can't even get this piece of shit to synchronize. bitcoind.exe crashing, BDM errors, what a pile of shit.
The "devs" in the forum tell you to create tickets on their site but the tickets just go ignored, and I'm assuming your email address gets collected and sold.
RIP in Peace Armory, it's time to move on to other Bitcoin clients.
1) Stop posting in 3 different threads. Pick one, or make one and stick to it. Stop spreading yourself so thin, I can't track posts all over the place and I'm not motivated to keep trying for very long. 2) We don't care for your email one second. Make a throw away account for this very purpose if you are afraid we would sell your address. This is how little we care for it. 3) Get me log files. I don't care how you do it. I always suggest using the dedicated support channel because there is some information in the logs that a few people don't feel comfortable sharing on a public forum. I don't care about your particular circumstances more than the next user. Edit the private info if you want, or don't, post it on pastebin, or copy paste it here, or make a ticket, whatever works. If you don't get me log files, I can't help you. 4) This is your last chance. Give me the information I need or don't expect to get any support from us anymore. That's what you get for throwing a tantrum instead of actually giving me log files. P.S: bitcoind.exe failing is usually a sign of a damaged Core DB. Start BitcoinQt manually, it will probably ask you to reindex blocks. Once that is done, try a rescan and rebuild in Armory again. |
|
|
|
Got btc core 0.10 and armory 0.93. After a lot of freezing up and a failed database read, and rebuilds of armory's database that kept freezing up, I deleted everything in my btc core and armory folder, so everything blockchain-related from both btc core and armory's own database is gone, the only things I kept were ArmorySettings.txt and my Armory wallet. I was hoping that a fresh re-download of the blockchain and rebuild from scratch would fix stuff. Instead armory is now freezing up at 0% synchronizing with network. The little spinning disk animation is frozen but the UI is still responsive. There is no disk activity. I'm at a loss here. I'm attaching the logs from btc core and armory's two logs here in hopes someone can figure out what is going on. I have been using armory fine for a year now. https://www.dropbox.com/s/8l9yh5vvp358apn/searinox-inactive_armory.zip?dl=0I'm not sure if you are trying to get the torrent bootstrap going or if you already have Core sync'ed with a fresh blockchain. The log says bitcoind started but it's not reporting a blockchain folder size which would purport you have a fresh Core datadir. At this point it's getting confusing. One thing I'm noticing that you should really avoid is: "--datadir=E:\Program Files (x86)\Armory\Data_Armory" Program Files(x86) is a binary folder. In that regard, a process would need admin privileges to write files in there, and chances are you aren't (neither do you want) to run Armory as admin. This alone will trip Armory. You should use a folder for which your current user has privileges, usually somewhere in the C:\user\*username* folder, or another drive/non system partition. If this doesn't fix it, then you should bypass bitcoind automanagement. Start BitcoinQt manually and get it to sync the full chain. If you want to speed that process up you can get the bootstrap torrent on your own and move the fully downloaded bootstrap into your Core datadir folder. With that done, start Armory and report on what happens. Ideally you should do that in a support ticket. |
|
|
|
|
Are you consistently getting a rescan after each restart?
|
|
|
|
|
I need your log files, one way or another (both armorylog.txt and armorycpplog.txt)
Either go through the support channel or post them somewhere and give me the link.
|
|
|
|
I have a question based on the new DB size, when using supernode will the DB still be as large as it is now?
No supernode is huge, ~90GB currently. I got same problem of BDM error box. It asks me to rebuild and rescan. I did it twice and it loads once correctly, then after next time same error.
Anyone fix this?
That was done on previous version to try and fix the problem but I had no luck.
Im trying to download now AGAIN, full factory reset, to see if that may work now on
the newest version.
Open a support ticket, attach log files. |
|
|
|
|
redownload the blockchain
|
|
|
|
Hi,
I was testing the last version of Armory and I think this was fixed, right?
No this is still here and we don't plan on getting rid of it. |
|
|
|
Great work as always. I particularly appreciate the highly accessible source code (last night, GnuPG's source made me a very sad panda). Any thoughts on BIP0039? I'm not so worried as I've written the functionality I desire myself; I'm just curious. No, we already had someone offering to pay us to implement something equivalent as a plugin and we turned him down |
|
|
|
getting dependency error not satifiable: libstdc++6(>=4.7) in Ubuntu 12.04 32 bit on attempted install of 0.93
Note that 0.93 can't go online in x86. Also, it requires C++11 so you'll need a libstd that is recent enough. You can probably get that package from the LTS backports repo. do we have to install 0.93 on both online and offline pc's?
Only the online machine |
|
|
|
0.92.99.7 supernode, Windows 7
I had two new transactions today, one sending and then one receiving. Both showed up when they had 0-conf, and then disappeared later, making Armory show an incorrect balance. I think each disappeared when it got a confirmation. Upgraded to 0.93, ran Help > Clear All Unconfirmed, and restarted Armory several times with no change.
Something that might have had an impact on this was that I also had a wallet loaded into Armory with ~131,000 imported private keys and many transactions on those addresses.
Wallet size will not impact supernode at all. This is some sort of scanning corner case. Can you see these transaction as part of the main chain in bc.info? I won't be going directly after this since I'm currently modifying a bunch of stuff in supernode for more stability and speed (this is for 0.93.1) Since version 92.99.6, I've been getting these compile errors/warnings...
The first batch of warnings is because LMDBException inherits runtime_error so the catch is redundant, nothing too bad The second set of warnings is just SWIG, nothing to see here really. |
|
|
|
I'm intrigued by this. Are you saying that as of 0.93.1, the Armory database in a default installation will only take up 120MB of disk space?
Yes I've got one last thing that keeps bothering me, yes it's the transaction details window still not showing inputs correctly, other than that I can't find anything else.
I've explained in a previous post why this will have to wait 0.93.1 |
|
|
|
By SPV do you mean a BC Core setting that doesn't save block data locally, only block headers? How will Armory parse the blockchain to find your wallets' history then?
I am talking about using the bloom filter that is on the bitcoin-core system. This would eliminate the entire armory database. Currently armory has two databases, the bitcoin core, and it's own. Right now both of those take up ~60gb on my system. It would be nice to eliminate one of those databases. I understand the risk that armory would have with just using a bloom filter to get transactions. In that case, keep an eye out of the upcoming 0.93.1 release candidate. |
|
|
|
Thanks etotheipi, but this is not the funcationality gweedo or I asked about.
Armory 0.93 and Bitcoin 0.10 support headers-first, but do not support SPV headers-only functionality. Headers-first still requires a full node that syncs with the entire chain, SPV allows for thin clients without storing any blocks.
SPV functionality is needed because many home ISP connections will not support running a full node with 20MB blocks or more. My home connection already has issues with bitcoind and I can not leave a full node running all the time (I have ~100kpbs up).
In this situation, if Armory does not support SPV then I might need to switch wallets, which I don't want to. One option is to run a full node in AWS and connect my home bitcoind only to that IP. This would enable my home node to download blocks only, which might be fine because the upload is the problem. But this costs money to run.
A better solution is for Armory to support SPV headers-only without running a full node. Yes, you are losing a little security without doing your own verification, but that is the trade off if you can't run a full node.
So, does Armory still plan to support SPV headers-only at some point?
Thanks,
By SPV do you mean a BC Core setting that doesn't save block data locally, only block headers? How will Armory parse the blockchain to find your wallets' history then? |
|
|
|
So this happened today...
Rescan. |
|
|
|
Well, now I really screwed up. I updated to 0.92.99.7-testing, old database was deleted, and now armory keeps crashing as soon as it starts building databases, I tried like 6 times  Force the dbdir to something else how do i do that? --dbdir="*mynewpath*" |
|
|
|
Well, now I really screwed up. I updated to 0.92.99.7-testing, old database was deleted, and now armory keeps crashing as soon as it starts building databases, I tried like 6 times Force the dbdir to something else |
|
|
|
Oops, I just updated to Bitcoin Core 0.10.0 and fired up Armory 0.92.3, it looks stuck on "building databases"... Did I screw up?
Use the secure downloader to grab 0.92.99.7-testing. It's a release candidate and should be officially renamed to 0.93 tomorrow (or latest Monday). You'll wipe the DBs, but the rebuild is super fast! Thank goatpig for that  OK, will do that... BTW, Armory 0.92.3 finally built the database and displayed the correct balance, so I guess is somewhat compatible with BC 0.10.0 I will crash if you receive blocks out of order while it is running. It should resume properly after a restart though. |
|
|
|
You meant no x86 releases for online Armory, correct? (otherwise I'm confused)
Yeah my bad, I derped -_-" You should probably be sure to point this out the download page (and in future download links here) so that people stuck on 32-bit machines do not inadvertently overwrite their 32-bit versions with non-working 64-bit versions... just a suggestion.
That's for Windows only, and something we should do at installer level really. We won't remove the link to 0.92.3 till we got a x86 Windows build for 0.93.1. |
|
|
|
That did fix it. Wow, is it not a bug in Bitcoin Core that the user's copy of the blockchain can be corrupted like that and not be self-corrected/act as if everything is good?
Armory depends on the blkxxxxx.dat files, which are raw bitmaps of the block data. Core flushes the raw data to disk but doesn't verify the committed data, nor does it bother to delete corrupt data and just appends valid data to it. This will trip Armory on occasions. Eventually we plan on moving to block over p2p, at which point I expect Core will realize the block data it's being asked to produce is corrupt (and maybe do something about it?). One thing I'm afraid to test: does the new Db build deterministically? Can I run Core 0.9.3 and 0.10.0 with the same 0.93 Armory database?
I expect the current one is "agnostic" (it keeps all block data in DB and resolves last known position in file by header hash). The new format in 0.93.1 won't be "agnostic", but the building will also be a lot faster, and is fully isolated from scanning. If it turns out people will want to match their DB against different blockchain folders, I may just add an option to rebuild the DB (takes about 45sec on my SSD setup) but salvage the scan data. |
|
|
|
I notice that this version is 64-bit only (I haven't checked earlier 0.92.99 releases though). Was that intentional? Historically the installs have been 32-bit executables, even on 64-bit Windows. Do you plan to drop support for pre-built Win32 binaries? Just wondering...
(also, an extremely minor nitpick: the installer installs this 64-bit executable into the x86 Program Files directory, probably because the installer itself is a 32-bit app and its directories are being virtualized by Windows)
LMDB maps the entire underlying dataset in RAM. Can't address 30GB of data in x86. And that's just fullnode, supernode requires 3x that currently. For 0.93.1, fullnode should be around 120MB so it could function in x86, but we still do not plan on releasing x64 Windows builds for online Armory. There will be a x86 Windows build to support people using Windows on their offline signer (hopefully I'll manage something for WinXP), but it won't be able to sync due to LMDB's RAM requirement. |
|
|
|
|
Show Posts
