We have an in-house tool for that purpose (as long as you remember enough of your password that is). Create a ticket and ask for that, it will be escalated to the right person.
Umm..wait...what? How is this possible on a secure wallet? We definitely need more explanation as to how this works. If YOU GUYS can do it ANYBODY can do it if they figure out how. Can you explain HOW you can do this? Say you have a wallet for which you remember about 90% of your password, like you remember the particular letters and numbers, but not which of the letters are capitalized or where you put an underscore. This tool will take your base pattern and run all possibilities. The less you remember of your password, the harder a time it will have trying to complete it. It can't guess your password out of thin air. You have to give us like 90~95% of your password to begin with. as long as you remember enough of your password that is |
|
|
|
|
I suspect this is a OSX playing nasty with Qt kind of error which eventually trickled down into triggering that error message.
|
|
|
|
We have an in-house tool for that purpose (as long as you remember enough of your password that is). Create a ticket and ask for that, it will be escalated to the right person. https://support.bitcoinarmory.com/home |
|
|
|
Is there any way to "sort" the wallet's in the main display? I know it's being trivial and anal on my part but I'd like to see the wallets presented in a certain order. For instance I'd like to see the wallets presented alphabetically by name or by type with "Watch-Only" wallets at the bottom of the wallet list. As I see it now wallets are displayed by ID so it's a toss-up as to where the wallet gets placed in the display after creation.
No such thing currently, we could consider adding a filter for wallet names on top of IDs. When creating a transaction from a lockbox, or any transaction that will be unsigned, offline, or just not broadcast at the moment, I cannot close the transaction window. I click the X but it does absolutely nothing. Please add a Close or Cancel button to these windows.
I can't reproduce that, can you elaborate on the exact steps and the dialog displaying this behavior? Also this is possibly a OSX thing only. |
|
|
|
Not a horrible problem but... I've been playing with .5 on Windows 7. If you try to restore a wallet from digital backup Armory prompts for the file name twice. Like I said not terrible. It works, but you have to answer the file name prompt twice.
Most likely related to some changes trying to improve the OSX file browser, we'll get it under control. |
|
|
|
I noticed this little # symbol in the lower left corner of the transaction window. When I hover over it, it expands and tells me where I am in the list. Is this meant to be just a debug thing that should be taken out before final release of 0.93?
I've originally developed that as a proof of concept to demonstrate the on-the-fly transaction history paging system the new backend runs on (the previous one would keep all history in RAM on both the C++ and Python side). I didn't expect it would get rolled in this early, but in the end it was better than the piss poor page browsing UI I added the first time around (that huge input box at the bottom on the transaction table in the lobby). The widget is meant to let you center the transaction table by time or block height, and it was heavily influenced by the large wallet I was developing this around (with 1VayNert and 1ExOdUs, some ~80k pages). I'm not much of UI guru and I would welcome any feedback and suggestions on this feature. One of the reason we released it as it stand is that the simplest way to improve user experience is the let the users tell us what they think. |
|
|
|
it's on a list of to-do stuff IIRC
It is. Won't make into the 0.93, but I hope to have it done for 0.93.1 |
|
|
|
Done traveling, ugh airports... I have imported wallet with small amount. But after scanning Armory shows zero balance.
With .4? I also have a couple of questions, what does each file in the databases directory contain, excluding 'blocks' and 'headers'?
And does supernode have the same HDD optimizations that fullnode has? Armory is estimating it will take me a full day to build supernode, but fullnode takes less than 1.5 hours?
The different databases holding relevant data like blocks, transactions hints (hash to DB key), headers and your wallets history. Lock files are self explanatory. I will be rolling some of the HDD optimizations into supernode soon, but eventually supernode will always horribly slow on a HDD. HDDs fail at high random access loads, and while I mitigated data fragmentation with the HDD opts, supernode tracks too much random data to manage that. At any rate, supernode node is meant for server backends and power users. You should stay away from it, unless you have tons of RAM and ~90 GB disk space to spare for the DB. Bug: Opened .4 on my windows computer, displayed spendable funds as 184.4 billion BTC. Will rebuild+rescan database and see if that helps.
Rescan should be enough. Remember what you did to get there? Also did you delete your .3 DB before trying .4? You should put a store inside armory to monetize, sell Trezor and shirts
The webshop is for armoryd (RPC Armory), it doesn't work with ArmoryQt (GUI Armory). Those are independent codebases, even though they share the same C++ lib. It's meant to demonstrate Armory's capabilities as a server backend, we don't intent to bring any of that to GUI interface. |
|
|
|
0.92.99.3 fullnode on Windows 7 here. Armory is fully synchronized, not apparently doing anything, but the CPU usage averages about 22-24% of a core (6% total), whether the Armory window is visible or not. It did not do this in earlier versions (certainly not in 0.92, and I don't think it did it in 0.92.99.2).
I had issues (i.e. a crash) with it building the db for a supernode earlier, but I know that I don't have the very latest version (waiting for a Windows build), so I won't repeat that.
I got a good idea where the idling cpu load is taking place, I'll look into cutting that down. If supernode crashes mid scan, restart Armory and it should resume where it left off. I also noticed that there is an option to rescan an individual lockbox when I right click it, can the same option be added to wallets?
I added that to support previous lockbox mechanics. I didn't know at the time if it was going to be useful (I wasn't accustomed to "py side" LB mechanics a few months ago). I don't think it is necessary anymore, but since it's here I'm leaving it as is. I won't add that to wallets. There is no significant speed difference between scanning a single wallet or several, so users are better off rescanning all their wallets together when in doubt. |
|
|
|
This happens on .3
Give it a spin when .4 comes out, should be fixed. |
|
|
|
Reporting another couple of bugs, I received bitcoins but Armory showed the TX as having 0 confirmations, even though it had 3 on blockchain. I rescanned the DB, and somehow all my wallet balances were doubled. No duplicate transactions, but the balances were doubled.
I rebuilt and rescanned the DB and everything was fixed.
This happened with the current version in the repo or with .3? That's something I specifically fixed for .4 Also what exactly do you mean by that bolded part above? The DB build/scan will be even faster?
If it was my utmost priority, I could make the build phase take 1 min and the scan take less than 5min. With my CPU at least. This is fine in its current state (~25 min to get going on a HDD), but the super short build is easy enough to roll after the round of HDD optimizations so that's what I'm going to experiment with. |
|
|
|
What specific bugfixes/features will be in .4?
Too many bugs to just list them. The grand majority of all the bugs reported in this thread here have been fixed. Actually a more accurate description of the work done would be all deal breakers (like the scanning speed issue) + anything that could be fixed without revisiting in depth mechanics. |
|
|
|
I'm not a compiling guru. Any ETA on the Windows pre-compile?
etotheipi will put out .4 either today or tomorrow I expect A tantalising glimpse into how much easier Armory will be to set up and use; 25 minutes to build and scan the Db. Then when you bring the application up again, the resync takes about the same length of time as the wallet check (and they're concurrent too). Couldn't have asked for much better than that.
I'm not done yet. The current state will go into .4, but it should get faster for .5. I have a couple bugs to go after first then I'm traveling so expect .5 for next week. |
|
|
|
|
Issue should be fixed now, feel free to pull 0.93-bugfix and give it a spin. As usual, wipe your existing DB beforehand
|
|
|
|
I didn't realize you had not tested against this yet. That sounds to me to be the mostly likely possibility.
I've finally reproduced your issue, and I am now 95% sure 0.10 out of order block data is the culprit. |
|
|
|
I didn't realize you had not tested against this yet. That sounds to me to be the mostly likely possibility.
Wasn't what I was working on at all. Catching me off guard now |
|
|
|
Still can't successfully index the blockchain.
Using this morning's version of the 0.93_bugfix branch, and Bitcoin Core 0.10.0_rc3 (this time, bootstrapped from the most current bootstrap.dat instead of purely from the network) I get to block 323413 before it throws an error.
Is it possible for the contents of a wallet to interfere with a blockchain scan?
The reason I ask is because I did get Armory to scan the blockchain successfully once, before the HDD_optimization branch was merged, with just one wallet.
I currently suspect it is some sort of blind spot in the code in regards to out of order data in blk files. This is something I have not worked with at all, I simply trusted the unit tests we have for it, and now I realize it is the one factor I have never tested my code against. I would definitely withhold all other suspicions until I have scanned a 0.10 mainnet chain. I'm making a point of downloading all blocks from the client in order to have as many out of order blocks as possible, so this is taking ages to sync. Hopefully it yields some valuable information. After the sync, I imported several more wallets and the rescan time was reported at 2 weeks. During several attempts at a complete rescan, and switching to the HDD_optimization branch and then back to the 0.93_bugfix branch, I've been unable to get a complete index of the blockchain.
Maybe one or more of my wallets is triggering a bug?
I'm not sure about the timing but HDD_opts has been merged into bugfix earlier this week, so if you pulled that branch recently you're essentially running the same code. Also a bunch of fixes to that code were worked in bugfix, and I only just merged these back into HDD_opts today. As for your wallets, how many addresses do they contain in total? More like 1k, 10k or 100k+? |
|
|
|
Can I get 99.2?
See with etotheipi, I don't have the binaries. |
|
|
|
Let's see if the latest version in 0.93-bugfix fixes any of this behavior. As usual, wipe the existing DB.
The outcome is no different to yesterdays unfortunately (the missing addresses are identical to yesterdays 0.93bugfix branch). Just finished re-checking that I was using the correct build. Edit: just tried running latest Armory 0.93 bugfix with Bitcoin Core 0.9.3, and all problems are resolved (all wallets have the balances I would expect) You mean you were trying with Core 0.10 and a dedicated chain folder? I'm confused as to why it would fail under these circumstances but I guess I have no choice but to see for myself. Thanks for your effort though, it makes my life easier at least =P |
|
|
|
|
Let's see if the latest version in 0.93-bugfix fixes any of this behavior. As usual, wipe the existing DB.
|
|
|
|
|
Show Posts
