Pages:
Author

Topic: Please Help Test Armory 0.91-beta! - page 10. (Read 21332 times)

full member
Activity: 168
Merit: 100
March 21, 2014, 06:48:20 AM
#40


I think the speed up is to be credited to njaard and etotheipi work on optimizing the DB. As for the transactions, did you pick show all wallets in the drop down combo box? Some people have it defaulted to "my wallet" and that won't show you transactions for any wallet that you didn't mark as yours.

No idea. I was so shocked I could still move around in the application after transaction scanning was complete, I didn't really spend any time troubleshooting. After about 5 seconds of clicking on things and having them react I shut down and removed the wallet, added others and restarted. It very well may have been user error.
legendary
Activity: 3794
Merit: 1375
Armory Developer
March 21, 2014, 05:38:44 AM
#39
Testing version 0.90.99.4 for Windows, Mac and Linux*
I can confirm that this makes a huge difference compared to 0.90.99.3. The wallet that made the previous version unusably slow now works with almost no slowing down. Also the startup is now crazy fast. Almost a hundredfold increase in startup speed compared to any previous version I've used.

But there's a problem with sending from the problematic wallet. I tried to make a donation to you guys but it always fails. I can't send coins to any other address from it either. Sending from my offline wallet works perfectly though.

I tried broadcasting the transaction using blockchain.info, but it says that "An outpoint is already spent".

Need your log file for to look at the send issue please.

Edit: This could be related to a spent output with the wallet. You should rescan the transactions. No need to rebuild though. I expect the balance will change after the rescan.
member
Activity: 74
Merit: 10
March 21, 2014, 03:52:26 AM
#38
Testing version 0.90.99.4 for Windows, Mac and Linux*
I can confirm that this makes a huge difference compared to 0.90.99.3. The wallet that made the previous version unusably slow now works with almost no slowing down. Also the startup is now crazy fast. Almost a hundredfold increase in startup speed compared to any previous version I've used.

But there's a problem with sending from the problematic wallet. I tried to make a donation to you guys but it always fails. I can't send coins to any other address from it either. Sending from my offline wallet works perfectly though.

I tried broadcasting the transaction using blockchain.info, but it says that "An outpoint is already spent".
sr. member
Activity: 344
Merit: 250
Flixxo - Watch, Share, Earn!
March 21, 2014, 01:23:03 AM
#37
WOW .
I had the same Problem with Crash/Freezes in <=0.90.99.4-testing and 0.9
 
under 0.90.99.4-testing it works fine :-)

Thanks
legendary
Activity: 1498
Merit: 1000
March 21, 2014, 12:08:30 AM
#36
Bug Mac OSX 10.9.2
Code:
2014-03-21 01:06 (ERROR) -- Traceback (most recent call last):
  File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ArmoryQt.py", line 37, in
    from ui.toolsDialogs import MessageSigningVerificationDialog
  File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/toolsDialogs.py", line 15, in
    from qtdialogs import MIN_PASSWD_WIDTH, DlgPasswd3, createAddrBookButton,\
  File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/qtdialogs.py", line 25, in
    from ui.UpgradeDownloader import UpgradeDownloaderDialog
  File "/Applications/Armory.app/Contents/MacOS/py/usr/lib/armory/ui/UpgradeDownloader.py", line 3, in
    from PyQt4.QtNetwork import *
ImportError: dlopen(/Applications/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/QtNetwork.so, 2): Library not loaded: /Users/joeschmoe/BitcoinArmory/osxbuild/workspace/install/qt/lib/QtNetwork.framework/Versions/4/QtNetwork
  Referenced from: /Applications/Armory.app/Contents/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/QtNetwork.so
  Reason: image not found
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
March 20, 2014, 11:45:57 PM
#35
Testing version 0.90.99.4 for Windows, Mac and Linux*

*Any linux with python2.6 is still borked.  However this package should work on any linux system with python 2.7 (we thought we'd found a way to compile universal installers, and we did...as long as it uses the same python version... we think...).


YES Mac version compiled and seems to be working!
YES The crashing at 99% done scanning seems to be fixed!
Offline-signed announce data.  No longer need --test-announce for torrent and secure downloading

Downloads and info in the top post.
LOL
member
Activity: 71
Merit: 10
March 20, 2014, 07:58:09 PM
#34
But while we're on the subject of multisig, do you mind commenting on the feasibility of a wallet recognizing strange outputs as spendable? That's a pretty broad question, but I didn't want to narrow it down so far as to only be applicable to the multisig example I provided. The reason I ask is largely due to mastercoin. Mastercoin uses 1-of-n multisig outputs as a method of storing data in the blockchain without creating unspendable outputs. The catch is that there isn't a wallet that will recognize or spend those outputs. As far as I'm concerned, they are unspendable by the average user. Anyway, do you find reason or incentive to recognize and support fringe case outputs such as the one in the example? If so, would you consider pursuing a wallet model that aims to recognize and spend all outputs that can be spent? Please note, this isn't a request - I'm just curious what a developer's thoughts are.

The answer to your question is basically:  determining spendability of an arbitrary script is an intractible problem.  I'm sure it's related to the halting problem.  Either way, the only way to do this is to simply identify a set of scripts templates and conditions that we know are spendable, and code those directly into the app.  When we have a multi-sig solution in Armory, it would be easy to automatically recognize such 1-of-N scripts as spendable.   But tying that into the interface may be complex:  do we really show those tx as spendable money the same as all the regular single-sig money?  It's in a 1-of-N for a reason, maybe it should be identified separately, in which case we need to show that in a different interface or in a different way.  Etc.

On that note, do you have a watching-only wallet that I could use to test the multi-sig thing.  I went to go fix it, and then realized I don't have a good way to get multisig address into any of my wallets.  Once i have one, I can fix the display problem pretty fast.

Thanks for humoring my question.

I'll PM you.
legendary
Activity: 3794
Merit: 1375
Armory Developer
March 20, 2014, 07:26:59 PM
#33


Nope.

And to be 100% honest, this really is performing faster than any time I have ever used it. Beyond actually working, there really is a noticeable performance improvement over initial installs with only a couple of small wallets. I now have 4 wallets restored, and it is running faster than times when I have restored a single wallet with only a couple of normal transactions for testing. Definitely make sure this fix gets into the new version!

EDIT:
I will note that when I initially loaded the watching-only wallet it worked, but no transactions were displayed (same version I sent you). I removedit and loaded the regular wallets, and all transactions were visible. Not sure what happened there. Maybe just a fluke, or maybe something worth checking out.

I think the speed up is to be credited to njaard and etotheipi work on optimizing the DB. As for the transactions, did you pick show all wallets in the drop down combo box? Some people have it defaulted to "my wallet" and that won't show you transactions for any wallet that you didn't mark as yours.
full member
Activity: 168
Merit: 100
March 20, 2014, 06:31:39 PM
#32
Actually faster than I have ever seen it.

Actually faster than with NO wallet.

https://blockchain.info/tx/c0e8be9ee6db4472454fbaee30bdf85a2245f429b18747e784c9aa33fd2e0cd4

That's a little scary but alright. Thanks for the donation. I get you had no issues sending either?

Nope.

And to be 100% honest, this really is performing faster than any time I have ever used it. Beyond actually working, there really is a noticeable performance improvement over initial installs with only a couple of small wallets. I now have 4 wallets restored, and it is running faster than times when I have restored a single wallet with only a couple of normal transactions for testing. Definitely make sure this fix gets into the new version!

EDIT:
I will note that when I initially loaded the watching-only wallet it worked, but no transactions were displayed (same version I sent you). I removedit and loaded the regular wallets, and all transactions were visible. Not sure what happened there. Maybe just a fluke, or maybe something worth checking out.
legendary
Activity: 3794
Merit: 1375
Armory Developer
March 20, 2014, 06:26:27 PM
#31
Actually faster than I have ever seen it.

Actually faster than with NO wallet.

https://blockchain.info/tx/c0e8be9ee6db4472454fbaee30bdf85a2245f429b18747e784c9aa33fd2e0cd4

That's a little scary but alright. Thanks for the donation. I get you had no issues sending either?
full member
Activity: 168
Merit: 100
March 20, 2014, 06:22:28 PM
#30
Goatpig just pushed a change that might push people through the BDM-timeout barrier if they have these wallets with huge numbers of large transactions.  Curious how the performance is after it gets past the synchronization, but at least you should get through it.

Zoella, rocks*, if you can, please checkout the latest 0.91-dev, make clean and make, then try it with your large wallets that were crashing (assuming you are on Linux... if not, we'll make a windows version after we know this solves it)


Booting VM, will get back to you soon!

Yay, it's working! Woohoo!



Wow finally... Let us know if there is an overall slowness feeled after the initial load. Oh and slam it with nastier wallets if you have any.

Actually faster than I have ever seen it.

Actually faster than with NO wallet.

https://blockchain.info/tx/c0e8be9ee6db4472454fbaee30bdf85a2245f429b18747e784c9aa33fd2e0cd4
legendary
Activity: 3794
Merit: 1375
Armory Developer
March 20, 2014, 06:13:20 PM
#29
Goatpig just pushed a change that might push people through the BDM-timeout barrier if they have these wallets with huge numbers of large transactions.  Curious how the performance is after it gets past the synchronization, but at least you should get through it.

Zoella, rocks*, if you can, please checkout the latest 0.91-dev, make clean and make, then try it with your large wallets that were crashing (assuming you are on Linux... if not, we'll make a windows version after we know this solves it)


Booting VM, will get back to you soon!

Yay, it's working! Woohoo!



Wow finally... Let us know if there is an overall slowness feeled after the initial load. Oh and slam it with nastier wallets if you have any.
full member
Activity: 168
Merit: 100
March 20, 2014, 06:12:39 PM
#28
Goatpig just pushed a change that might push people through the BDM-timeout barrier if they have these wallets with huge numbers of large transactions.  Curious how the performance is after it gets past the synchronization, but at least you should get through it.

Zoella, rocks*, if you can, please checkout the latest 0.91-dev, make clean and make, then try it with your large wallets that were crashing (assuming you are on Linux... if not, we'll make a windows version after we know this solves it)


Booting VM, will get back to you soon!

Yay, it's working! Woohoo!

full member
Activity: 168
Merit: 100
March 20, 2014, 05:41:01 PM
#27
Goatpig just pushed a change that might push people through the BDM-timeout barrier if they have these wallets with huge numbers of large transactions.  Curious how the performance is after it gets past the synchronization, but at least you should get through it.

Zoella, rocks*, if you can, please checkout the latest 0.91-dev, make clean and make, then try it with your large wallets that were crashing (assuming you are on Linux... if not, we'll make a windows version after we know this solves it)


Booting VM, will get back to you soon!
member
Activity: 70
Merit: 10
March 20, 2014, 01:44:12 PM
#26
Goatpig just pushed a change that might push people through the BDM-timeout barrier if they have these wallets with huge numbers of large transactions.  Curious how the performance is after it gets past the synchronization, but at least you should get through it.

Zoella, rocks*, if you can, please checkout the latest 0.91-dev, make clean and make, then try it with your large wallets that were crashing (assuming you are on Linux... if not, we'll make a windows version after we know this solves it)


Windows7 here.
legendary
Activity: 1428
Merit: 1093
Core Armory Developer
March 20, 2014, 12:40:53 PM
#25
Goatpig just pushed a change that might push people through the BDM-timeout barrier if they have these wallets with huge numbers of large transactions.  Curious how the performance is after it gets past the synchronization, but at least you should get through it.

Zoella, rocks*, if you can, please checkout the latest 0.91-dev, make clean and make, then try it with your large wallets that were crashing (assuming you are on Linux... if not, we'll make a windows version after we know this solves it)
legendary
Activity: 3794
Merit: 1375
Armory Developer
March 20, 2014, 12:04:01 PM
#24
At wallet corruption detection, should you choose to fix and need to unlock, Armory will not prompt again if an incorrect password is entered, simply note the error and present no option but to close the window. Would be nice if Armory presented the wallet name instead of ID tag there, too. As if I have any bloody idea what the password to 3CU1BLUti is... Tongue

Thanks for the report, I'll get on it soon.
donator
Activity: 1218
Merit: 1015
March 20, 2014, 11:42:25 AM
#23
At wallet corruption detection, should you choose to fix and need to unlock, Armory will not prompt again if an incorrect password is entered, simply note the error and present no option but to close the window. Would be nice if Armory presented the wallet name instead of ID tag there, too. As if I have any bloody idea what the password to 3CU1BLUti is... Tongue
legendary
Activity: 3794
Merit: 1375
Armory Developer
March 20, 2014, 11:37:10 AM
#22
I can't reproduce the comment issue on my end. Try this:

1) Load you wallet in Armory offline.
2) Restore it from paper. This will rip the meta data from the wallet if it's currently loaded.
3) Load the restored wallet and see if the comments show up

Issue with that is it's an offline wallet, I don't really want to restore it from paper to my online computer.

Can I just use a digital backup (Watch-only) from my offline computer? Or is there some way to do that without using the paper backup?

I added this feature to save meta data on restores only. I should also add a way to just rip a wallet's meta data in a separate file, but I don't think that'll fit in 0.91 schedule's. If you use Linux and are willing to pull a side branch, We can work something and you be my guinea pig =P. However that will have to wait a few days, still working on the ledger entry issue.

Currently you could move the WO to your offline Armory, and restore from there. This feature isn't meant to work with digital imports. Maybe it should.
legendary
Activity: 2618
Merit: 1007
March 20, 2014, 11:24:53 AM
#21
https://github.com/etotheipi/BitcoinArmory/blob/0.91-dev/default_bootstrap.torrent is the one I'm talking about and this file being a private torrent has nothing to do with which client you use. You created it with Transmission 2.51 and set this option apparently (knowingly or unknowingly: http://www.bittorrent.com/help/manual/appendixa0403#Other.Private_torrent).

Your client might not support DHT, but it likely supports PEX. This already would be enough to bridge swarms or extend them if the tracker is down, as long as they are able to find a single peer. Also it does not hurt to enter a larger list of trackers in the file, there are a few open ones still around.
Pages:
Jump to: