For the bounty: 1LGBcGGi6aEgbnWtwfpBn3m4n4Js1gRxf8
Sorry i'm just wasting time test small things while i wait to get online.
Also, just a suggestion,
Bitcoin 'stealers' have a feature that when a bitcoin address is copied to the clipboard it is replaced with the 'hackers' address.
With saying that i think you should add a warning system to alert the user when this happens with any address's linked to Armory.
Topic: [BOUNTY] Help test next major release of Armory! [0.04 BTC/bug] - page 4. (Read 12657 times)
November 15, 2013, 09:44:40 PM
November 15, 2013, 03:17:41 PM
Heh, ironic you mention that. Because not long ago I had it the way you just mentioned, and people were pissed off that it looked like the whole thing was starting over from scratch. Especially when they interrupted the initial DB build and restarted it. I changed it from what you just requested, due to popular demand 
Admittedly, maybe I can change the behavior when you're mostly synchronized already, versus in the middle of the huge DB build operation...
You clearly need two progress bars Admittedly, maybe I can change the behavior when you're mostly synchronized already, versus in the middle of the huge DB build operation...
One showing percent of total progress, the other showing percent of todays progress.
November 15, 2013, 02:02:56 PM
I freshly installed Armory, created a new wallet while it was downloading the blocks, and haven't quit it since. It's still scanning.
Just to be clear, when Armory starts up is using auto-bitcoind, it does the following:
(1) Starts bitcoind, requests its sync state
(2) Waits for bitcoind to finished downloading the 15GB blockchain
(3) Builds/updates the Armory databases from the 15GB of blk*.dat files produced by bitcoind
(4) Checks the stored address histories in the DB and compares against wallet addresses
(4a) If there are no addresses needing to be rescanned, it simply loads the histories
(4b) If the histories are incomplete, or you had an unclean shutdown (histories were never written to DB) -- rescans the full Armory databases
(5) Switches the interface to "online mode" and displays the tx history.
If your bitcoin-qt/bitcoind is already synchronized, then step #2 is minimal effort. Otherwise it can take 4-48 hours depending on your connection (but you know that part).
If you have not run Armory before, it will have to build the databases from scratch the first time in #3, which will take 30-120 minutes (on most systems). If the DB is already built, it only updates the latest blocks (like 10 sec).
Step #4 either takes 5 sec (if already sync'd), or 10-30 minutes if it needs a full rescan. This step will get much faster on the next release.
If you did not add any addresses, or you did but they were part of a new wallet, then it should only have to do step #4 once. After that, it will startup in like 30 sec. If you see alternative behavior, it's probably a bug.
*The one exception to all of the above is the occasional DB corruption where it automatically detects and rebuilds. Yes, annoying. But I don't have any other way until I reduce the DB corruption events.
November 15, 2013, 01:46:36 PM
I freshly installed Armory, created a new wallet while it was downloading the blocks, and haven't quit it since. It's still scanning.
November 15, 2013, 01:37:39 PM
I'm not sure if this counts as a bug, but when I loaded up armory, it had to download the last 3% of the blockchain, then go through building the database, but now its scanning the blockchain. The problem is, the only wallet has 0 addresses and was freshly created. So now I'm stuck waiting while it scans for nothing.
If there's zero addresses/wallets, it should skip the scan. If it's a newly created wallet, the addresses should be marked "new" and not induce a rescan.
However, it will always rescan on an unclean shutdown. It's a long story. I'd rather that inconvenience occur than have corrupted balances/history and the confusion that follows. However, it's probably robust enough to not require a rescan on unclean shutdown, I just haven't tried yet.
November 15, 2013, 01:33:11 PM
I'm not sure if this counts as a bug, but when I loaded up armory, it had to download the last 3% of the blockchain, then go through building the database, but now its scanning the blockchain. The problem is, the only wallet has 0 addresses and was freshly created. So now I'm stuck waiting while it scans for nothing.
November 15, 2013, 12:10:55 PM
Ok, so this isnt a bug, but a suggestion. The percentage complete when downLoading the blocks is really only helpful on the first download. When i boot up Armory and it says 99% 10 minutes remaining, that doesnt tell me much. Maybe the percentage could be percentage complete since the beginning of the download, or you could include how many blocks behind the client is.
Heh, ironic you mention that. Because not long ago I had it the way you just mentioned, and people were pissed off that it looked like the whole thing was starting over from scratch. Especially when they interrupted the initial DB build and restarted it. I changed it from what you just requested, due to popular demand
Admittedly, maybe I can change the behavior when you're mostly synchronized already, versus in the middle of the huge DB build operation...
November 15, 2013, 11:47:18 AM
Yes, Armory requires having the whole blockchain. Yes, it requires running Bitcoin-Qt in the background. Yes, sometimes it's difficult to point Armory to the correct bitcoind location.
I know this is a known issue, but I'd suggest having a way to enter the satoshi directory in the settings. When you click the "let armory run bitcoin", Bitcoin home directory could stay editable. Or change to blockchain directory.
November 15, 2013, 11:39:30 AM
Ok, so this isnt a bug, but a suggestion. The percentage complete when downLoading the blocks is really only helpful on the first download. When i boot up Armory and it says 99% 10 minutes remaining, that doesnt tell me much. Maybe the percentage could be percentage complete since the beginning of the download, or you could include how many blocks behind the client is.
November 15, 2013, 11:31:11 AM
I have got still problem with no ascii, national characters(like ążźć) in label of address.
Ack, I was just about to add that to the list of off-limit topics. I'm well aware of Armory's unicode issues, and fixing that is in my plans for the next release after this one. Since it wasn't on the list, I'll give you the bounty for it.
Your (?) tool tips require you to click, hold and drag the mouse off the tool tip to keep it displaying else as soon as you just click it disappears.
This behaves differently in each OS. I haven't yet figured out how to make this consistent and friendly. Still better than the mouse-over-hold-wait-display, which some users didn't figure out. Again, something else I meant to post as already-known, but I'm not going to be stingy about it. You tested the interface and found a usability issue. One bounty for you!
Here's a bug I've found since the last stable version, I've tried this on 0.89.99.10-beta and 0.89.99.14-beta and I've done a couple rescans too. It seems for me the transactions tab does not populate until it receives a new block after it has finished loading. It pretty much seems to stay like and looks like it is broken until I left it running for a while and then suddenly all the transactions in the window appears, everything else seems to work fine though. This only seemed to happen the first time it was run so, it might be that everything is catching up the first time and it is taking a really long time to reorganise itself. It does report errors in the log though so here they are.
Okay, so I haven't heard of this bug in a long time. I thought it only happened when you have a corrupt wallet in your list. If you isolate it better, I got a bounty for you! What OS? Can you try making a copy of the ARMORY_HOME_DIR (if you have the space for it), then remove the wallets, and run Armory with " --datadir=/new/directory/path". Create a single new wallet, then restart and let it sync again. I need to know if it goes away. If so, then there's an issue with one of the wallets and I'll dig further.
November 15, 2013, 11:21:53 AM
I have got still problem with no ascii, national characters(like ążźć) in label of address.
The problem is not new but it still appears so i don't want reward.
Code:
(ERROR) Traceback (most recent call last):
File "/home/piotrek/Apps/BitcoinArmory/qtdialogs.py", line 2198, in acceptNewAddr
comm = str(self.edtComm.toPlainText())
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)
Traceback (most recent call last):
File "/home/piotrek/Apps/BitcoinArmory/qtdialogs.py", line 2198, in acceptNewAddr
comm = str(self.edtComm.toPlainText())
UnicodeEncodeError: 'ascii' codec can't encode characters in position 0-2: ordinal not in range(128)
The problem is not new but it still appears so i don't want reward.
November 15, 2013, 11:19:33 AM
I'm on it, Windows 8
November 15, 2013, 07:44:23 AM
Your (?) tool tips require you to click, hold and drag the mouse off the tool tip to keep it displaying else as soon as you just click it disappears.
--
http://i.imgur.com/TVBGr9M.png
--
http://i.imgur.com/TVBGr9M.png
November 15, 2013, 07:39:31 AM
Oh, that's right... I do remember having to do some special stuff on OSX with the print dialog. But I seem to remember that it was fixed with the OSX-specific code... I guess not?
The print dialog works for me (OS X 10.9) - and at some point it started to work for me in 10.8, too. November 15, 2013, 05:10:33 AM
Here's a bug I've found since the last stable version, I've tried this on 0.89.99.10-beta and 0.89.99.14-beta and I've done a couple rescans too. It seems for me the transactions tab does not populate until it receives a new block after it has finished loading. It pretty much seems to stay like and looks like it is broken until I left it running for a while and then suddenly all the transactions in the window appears, everything else seems to work fine though. This only seemed to happen the first time it was run so, it might be that everything is catching up the first time and it is taking a really long time to reorganise itself. It does report errors in the log though so here they are.
the log as follows:
And how it looked when the error in the log appeared.
the log as follows:
Code:
2013-11-15 19:29 (INFO) -- armoryengine.py:12479 - Reading blockchain, pct complete: 0.0
2013-11-15 19:29 (INFO) -- ArmoryQt.py:4463 - Dashboard switched to fully-online mode
2013-11-15 19:29 (INFO) -- ArmoryQt.py:3837 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2013-11-15 19:29 (INFO) -- ArmoryQt.py:3779 - Switching Armory functional mode to "Online"
2013-11-15 19:29 (INFO) -- ArmoryQt.py:3837 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2013-11-15 19:29 (INFO) -- ArmoryQt.py:1907 - Syncing wallet: 2pD6iHKkB
2013-11-15 19:29 (INFO) -- ArmoryQt.py:1907 - Syncing wallet: 35Fijn44X
2013-11-15 19:29 (INFO) -- ArmoryQt.py:1907 - Syncing wallet: 2H5X6XTGs
2013-11-15 19:29 (INFO) -- ArmoryQt.py:1907 - Syncing wallet: CSFC3QFR
2013-11-15 19:29 (INFO) -- ArmoryQt.py:1907 - Syncing wallet: 2ToSafqhH
2013-11-15 19:29 (INFO) -- ArmoryQt.py:1919 - Current block number: 269713
2013-11-15 19:43 (INFO) -- armoryengine.py:10634 - Received new block. 0000000000000004f6512bbfeccd904fa068123e33d59211253bbd307c54f441
2013-11-15 19:44 (INFO) -- armoryengine.py:10634 - Received new block. 0000000000000004fe7b45f3bbc4c7edbd9ff86c963fe77282453e1b38f66503
2013-11-15 20:12 (INFO) -- ArmoryQt.py:4463 - Dashboard switched to fully-online mode
2013-11-15 20:12 (INFO) -- ArmoryQt.py:3837 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2013-11-15 20:12 (INFO) -- ArmoryQt.py:3779 - Switching Armory functional mode to "Online"
2013-11-15 20:12 (INFO) -- ArmoryQt.py:3837 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2013-11-15 20:12 (INFO) -- ArmoryQt.py:4463 - Dashboard switched to fully-online mode
2013-11-15 20:12 (INFO) -- ArmoryQt.py:3837 - Switching Armory state text to Mgmt:User, State:OnlineFull1
2013-11-15 20:12 (INFO) -- ArmoryQt.py:3779 - Switching Armory functional mode to "Online"
2013-11-15 20:12 (INFO) -- ArmoryQt.py:3837 - Switching Armory state text to Mgmt:User, State:OnlineFull2
2013-11-15 20:12 (ERROR) -- armoryengine.py:12372 - Waiting for BDM output that didn't come after 20s.
2013-11-15 20:12 (ERROR) -- armoryengine.py:12373 - BDM state is currently: BlockchainReady
2013-11-15 20:12 (ERROR) -- armoryengine.py:12374 - Called from: armoryengine.py:12563 (64639402)
2013-11-15 20:12 (ERROR) -- armoryengine.py:12375 - BDM currently doing: ReadBlkUpdate (64639402)
2013-11-15 20:12 (ERROR) -- armoryengine.py:12376 - Direct traceback
2013-11-15 20:12 (ERROR) -- armoryengine.py:12378 - Traceback:
Traceback (most recent call last):
File "/usr/lib/armory/armoryengine.py", line 12368, in waitForOutputIfNecessary
return self.outputQueue.get(True, self.mtWaitSec)
File "/usr/lib/python2.7/Queue.py", line 176, in get
raise Empty
Empty
2013-11-15 20:15 (ERROR) -- armoryengine.py:12372 - Waiting for BDM output that didn't come after 20s.
2013-11-15 20:15 (ERROR) -- armoryengine.py:12373 - BDM state is currently: BlockchainReady
2013-11-15 20:15 (ERROR) -- armoryengine.py:12374 - Called from: armoryengine.py:12563 (35311268)
2013-11-15 20:15 (ERROR) -- armoryengine.py:12375 - BDM currently doing: ReadBlkUpdate (35311268)
2013-11-15 20:15 (ERROR) -- armoryengine.py:12376 - Direct traceback
2013-11-15 20:15 (ERROR) -- armoryengine.py:12378 - Traceback:
Traceback (most recent call last):
File "/usr/lib/armory/armoryengine.py", line 12368, in waitForOutputIfNecessary
return self.outputQueue.get(True, self.mtWaitSec)
File "/usr/lib/python2.7/Queue.py", line 176, in get
raise Empty
Empty
2013-11-15 20:20 (INFO) -- ArmoryQt.py:4779 - New Block! : 269717
2013-11-15 20:20 (INFO) -- ArmoryQt.py:4803 - Current block number: 269717
And how it looked when the error in the log appeared.
November 15, 2013, 02:47:13 AM
Looking forward to the new version of the software. What is the tentative release date for the final version.
November 15, 2013, 01:10:05 AM
OSX errors: frustrating I might not be able to claim 10.9 support yet. I think I have to limit it (and bug bounties) to 10.8.
The print issue predates Mavericks, I can replicate it on 10.8 in both the latest stable and the latest beta.
I completely understand your reluctance to support 10.9, it's foreign territory especially as you're not a native developer.
Oh, that's right... I do remember having to do some special stuff on OSX with the print dialog. But I seem to remember that it was fixed with the OSX-specific code... I guess not?
Seems not. You can open up the PDF preview and print from there if you are extremely fast (race against the window freezing), but if you manage it Armory will crash and lose it's working database.
November 15, 2013, 12:06:30 AM
Will download it for windows and I'll let you know if I find anything.
November 15, 2013, 12:06:08 AM
Is it BIP32 compliant?
Negative. That's a whole different overhaul, and it would be a total mess to do that overhaul at the same time as this one.
After this release will be a bug-fix and polishing release (like fixing unicode issues, and re-optimizing the database engine). Then, I'll finish the new wallet format (which is like 75% done already), and that will come with support for BIP 32, compressed public keys, and all the hooks for adding multi-sig.
November 14, 2013, 11:45:46 PM
Is it BIP32 compliant?
Jump to: