Topic: Armory - Discussion Thread - page 208. (Read 521855 times)
But if the only thing loaded on there is armory transactions and whatnot, is there really any place for that malware to hide?
Could something like this remove the risc of transfer between two computers.
LOK-IT Secure Flash Drive
http://www.pcmag.com/article2/0,2817,2381269,00.asp
Or perhaps this company should make a safe bitcoin storage?
LOK-IT Secure Flash Drive
http://www.pcmag.com/article2/0,2817,2381269,00.asp
Or perhaps this company should make a safe bitcoin storage?
the problem is that once you plug it in to your online pc and unlock it, the contents are exposed to a USB specific exploit that could load malware onto it. unlikely, but still possible.
Could something like this remove the risc of transfer between two computers.
LOK-IT Secure Flash Drive
LOK-IT Secure Flash Drive
what exactly does that device do that enhances security in this case?
Could something like this remove the risc of transfer between two computers.
LOK-IT Secure Flash Drive
http://www.pcmag.com/article2/0,2817,2381269,00.asp
Or perhaps this company should make a safe bitcoin storage?
LOK-IT Secure Flash Drive
http://www.pcmag.com/article2/0,2817,2381269,00.asp
Or perhaps this company should make a safe bitcoin storage?
Given the current stability of Armory, I may consider RAM-reduction, address books, and system-tray notifications to be a milestone for Armory Beta. Mainly because it will at least be usable by everyone (even with 1 GB of RAM), and the networking-independence is going to be a pretty substantial overhaul under-the-hood.
Sounds good
Imagine the combination of the Beta tag, and the RAM reduction will see a significant uptake in usage. That of course means more bug testing I haven't used Armory very often because of the RAM price tag.
I will definitely use it more often as soon as RAM-reduction is working.
Given the current stability of Armory, I may consider RAM-reduction, address books, and system-tray notifications to be a milestone for Armory Beta. Mainly because it will at least be usable by everyone (even with 1 GB of RAM), and the networking-independence is going to be a pretty substantial overhaul under-the-hood.
Sounds good
Imagine the combination of the Beta tag, and the RAM reduction will see a significant uptake in usage. That of course means more bug testing 
Works like a charm , thx. Time for another donation 
, thx. Time for another donation Okay, let me know if you find any more issues like this. I'll go ahead and make those two changes in the master branch
Always glad to help!-Alan
Works like a charm , thx. Time for another donation
, thx. Time for another donation I applied the fix on master. Now the date column correctly shows "Mär" but opening the transaction details still fails with:
Code:
Traceback (most recent call last):
File "ArmoryQt.py", line 1431, in dblClickLedger
txtime = str(self.ledgerView.model().index(row, LEDGERCOLS.DateStr).data().toString())
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 6: ordinal not in range(128)
Oh, also change that "str( ... )" on ArmoryQt.py:1431 to "unicode( ... )".
I applied the fix on master. Now the date column correctly shows "Mär" but opening the transaction details still fails with:
Code:
Traceback (most recent call last):
File "ArmoryQt.py", line 1431, in dblClickLedger
txtime = str(self.ledgerView.model().index(row, LEDGERCOLS.DateStr).data().toString())
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in position 6: ordinal not in range(128)
Thx for fixing. I already have another one . The ledger entries (on the main window) date column seems to be localized. I have an entry showing "Mär" which means März which is German for march. But there are some charset issues, the "ä" shows up as 2 special chars and I can't show transaction details as trying to open the details window fails with an error message.
Is there a way to force armory to use an english locale?
. The ledger entries (on the main window) date column seems to be localized. I have an entry showing "Mär" which means März which is German for march. But there are some charset issues, the "ä" shows up as 2 special chars and I can't show transaction details as trying to open the details window fails with an error message.Code:
Traceback (most recent call last):
File "ArmoryQt.py", line 1429, in dblClickLedger
txtime = str(self.ledgerView.model().index(row, LEDGERCOLS.DateStr).data().toString())
UnicodeEncodeError: 'ascii' codec can't encode characters in position 6-7: ordinal not in range(128)
Is there a way to force armory to use an english locale?
I haven't been paying much attention to different locales, though fornit is helping me with translation, so it will be happening at some point. Until then, try one fix in the code for me just to see if it works:
armoryengine.py:622, change it to:
Code:
dtstr = u'' + dtobj.strftime(formatStr).decode('utf-8')That won't change the locale to english, but it might cause your current locale to display properly.
Thx for fixing. I already have another one . The ledger entries (on the main window) date column seems to be localized. I have an entry showing "Mär" which means März which is German for march. But there are some charset issues, the "ä" shows up as 2 special chars and I can't show transaction details as trying to open the details window fails with an error message.
Is there a way to force armory to use an english locale?
. The ledger entries (on the main window) date column seems to be localized. I have an entry showing "Mär" which means März which is German for march. But there are some charset issues, the "ä" shows up as 2 special chars and I can't show transaction details as trying to open the details window fails with an error message.Code:
Traceback (most recent call last):
File "ArmoryQt.py", line 1429, in dblClickLedger
txtime = str(self.ledgerView.model().index(row, LEDGERCOLS.DateStr).data().toString())
UnicodeEncodeError: 'ascii' codec can't encode characters in position 6-7: ordinal not in range(128)
Is there a way to force armory to use an english locale?
Some significant bug fixes in...
Armory version 0.61-alpha (source-code update only; no Windows binaries)
Since this is mainly a Linux/OSX update (which must be pulled from git and compiled, anyway), I have updated the repo but not the Windows binaries. I probably will not make those for 0.61 at all. Instead, this will show up in Windows when it is merged into the RAM-reduction upgrade.
--Implemented static linking of Crypto++ to permanently resolve a number of linking issues on Linux/OSX. If you had to use LD_PRELOAD before, you no longer have to!
--Created a qresources file to hold all the images in an importable python module. This solves the problem of images not loading when using a running from a different directory in Linux/OSX (or using a shortcut). The downside is the qrc_img_resources.py file is 10 MB! But it's worth it for the robustness.
--Fixed a minor bug with the warning dialog for receiving coins with a watching-only wallet.
On the topic of RAM reduction: I spent all day yesterday re-organizing blockchain scanning code, and working a new system of "registering" wallets and addresses with the BlockDataManager (BDM). The new system will allow me to combine the initial scan with the wallet-tx search (it would be done multiple times if I had just blindly thrown in mmap). It also gives me a way to ask the BDM if the next balance-retrieval operation will take a while, and then I can notify the user instead of just locking up the interface for 15-60 sec -- this would be primarly for importing a new address, requiring a full rescan of the blockchain.
I expect to have an experimental version of RAM reduction for Linux/OSX next week. I'm going to have to modify some of the interfaces to accommodate long-action-times, and modify some stuff under-the-hood to make sure it respects balance retrieval operations. I'll probably introduce all sorts of bugs, which users can help test while I work on making it happen on Windows, too.
Given the current stability of Armory, I may consider RAM-reduction, address books, and system-tray notifications to be a milestone for Armory Beta. Mainly because it will at least be usable by everyone (even with 1 GB of RAM), and the networking-independence is going to be a pretty substantial overhaul under-the-hood.
Armory version 0.61-alpha (source-code update only; no Windows binaries)
Since this is mainly a Linux/OSX update (which must be pulled from git and compiled, anyway), I have updated the repo but not the Windows binaries. I probably will not make those for 0.61 at all. Instead, this will show up in Windows when it is merged into the RAM-reduction upgrade.
--Implemented static linking of Crypto++ to permanently resolve a number of linking issues on Linux/OSX. If you had to use LD_PRELOAD before, you no longer have to!
--Created a qresources file to hold all the images in an importable python module. This solves the problem of images not loading when using a running from a different directory in Linux/OSX (or using a shortcut). The downside is the qrc_img_resources.py file is 10 MB! But it's worth it for the robustness.
--Fixed a minor bug with the warning dialog for receiving coins with a watching-only wallet.
On the topic of RAM reduction: I spent all day yesterday re-organizing blockchain scanning code, and working a new system of "registering" wallets and addresses with the BlockDataManager (BDM). The new system will allow me to combine the initial scan with the wallet-tx search (it would be done multiple times if I had just blindly thrown in mmap). It also gives me a way to ask the BDM if the next balance-retrieval operation will take a while, and then I can notify the user instead of just locking up the interface for 15-60 sec -- this would be primarly for importing a new address, requiring a full rescan of the blockchain.
I expect to have an experimental version of RAM reduction for Linux/OSX next week. I'm going to have to modify some of the interfaces to accommodate long-action-times, and modify some stuff under-the-hood to make sure it respects balance retrieval operations. I'll probably introduce all sorts of bugs, which users can help test while I work on making it happen on Windows, too.
Given the current stability of Armory, I may consider RAM-reduction, address books, and system-tray notifications to be a milestone for Armory Beta. Mainly because it will at least be usable by everyone (even with 1 GB of RAM), and the networking-independence is going to be a pretty substantial overhaul under-the-hood.
Just found a little bug. To trigger it:
Select a watching-only wallet (might work with a normal wallet, too, did not yet test that), select 'wallet properties'. On the right side, click 'receive bitcoins'. On the warning popup about that you might not be able to spend the coins, click cancel. Then a new window shows up without GUI elements, and it creates a new receiving address (reopen wallet properties to show the new created address).
Tested with the current master branch on linux amd64.
Select a watching-only wallet (might work with a normal wallet, too, did not yet test that), select 'wallet properties'. On the right side, click 'receive bitcoins'. On the warning popup about that you might not be able to spend the coins, click cancel. Then a new window shows up without GUI elements, and it creates a new receiving address (reopen wallet properties to show the new created address).
Tested with the current master branch on linux amd64.
Thanks randomguy7. Someone actually reported that bug like a month ago, and I totally forgot to take care of it. It should take like 10 minutes.
It's nice that these tiny, mundane bugs are the worst thing people can find in the program
Just found a little bug. To trigger it:
Select a watching-only wallet (might work with a normal wallet, too, did not yet test that), select 'wallet properties'. On the right side, click 'receive bitcoins'. On the warning popup about that you might not be able to spend the coins, click cancel. Then a new window shows up without GUI elements, and it creates a new receiving address (reopen wallet properties to show the new created address).
Tested with the current master branch on linux amd64.
Select a watching-only wallet (might work with a normal wallet, too, did not yet test that), select 'wallet properties'. On the right side, click 'receive bitcoins'. On the warning popup about that you might not be able to spend the coins, click cancel. Then a new window shows up without GUI elements, and it creates a new receiving address (reopen wallet properties to show the new created address).
Tested with the current master branch on linux amd64.
I just started a new thread, just for Armory+OSX:
Building Armory on OSX.
I really want to see this discussed, but this thread is getting hammered with stuff that isn't relevant to a lot of people who subscribed. Please continue discussion of OSX-specific stuff there. I will eventually get an OSX system and use that thread to help myself get through the build process and create binaries.
Moving on: the reason RAM-reduction is not so simple, is because the code assumes that a full-rescan of the blockchain takes <1 second. Therefore, I need to reorganize code to make sure there is only one full scan (on load) and that all information on all your wallets is collected during that scan. Of course, importing an address or new wallet will require a new rescan, but I've already created the "Please wait!" window to accommodate that. And I will be adding a bulk-address-import window, so that you don't have to import one-by-one, waiting 30 seconds after each.
In the future I won't even be doing a full rescan of the blockchain on each load, but at the moment it is adding a lot of robustness and simplicity, not having to create any intermediate files at all. There's no tx data stored between loads. I haven't seen any issues with balances or spent-output corruption. But if there was, it can always be fixed by restarting (and thus rescanning from scratch).
Building Armory on OSX.
I really want to see this discussed, but this thread is getting hammered with stuff that isn't relevant to a lot of people who subscribed. Please continue discussion of OSX-specific stuff there. I will eventually get an OSX system and use that thread to help myself get through the build process and create binaries.
Moving on: the reason RAM-reduction is not so simple, is because the code assumes that a full-rescan of the blockchain takes <1 second. Therefore, I need to reorganize code to make sure there is only one full scan (on load) and that all information on all your wallets is collected during that scan. Of course, importing an address or new wallet will require a new rescan, but I've already created the "Please wait!" window to accommodate that. And I will be adding a bulk-address-import window, so that you don't have to import one-by-one, waiting 30 seconds after each.
In the future I won't even be doing a full rescan of the blockchain on each load, but at the moment it is adding a lot of robustness and simplicity, not having to create any intermediate files at all. There's no tx data stored between loads. I haven't seen any issues with balances or spent-output corruption. But if there was, it can always be fixed by restarting (and thus rescanning from scratch).
yes, consider it another donation. Powerbook G4, OS 10.3.9. other specs i don't recall offhand. let me know.
Can you build universal binaries with it? Meaning PPC and Intel.
sorry, i wouldn't know.
@Torus,
Did your problem go away? I can see a very minor bug in the code that might cause that to happen rarely and randomly. I don't see why that last commit would make a difference, and it should work if you just close and reopen it...? Either way, I made the super-simple fix and will commit it with the next batch of bug-fixes.
You are right it does not reproduce anymore. Must have been the random occurrence.
@Everyone else:
Today is my day to do RAM-reduction. I don't know if I can get it done today, but I have a solid 8 hours of uninterrupted time to dive into the blockchain utilities and get it done!
That's great news. I would not have to close Firefox anymore. :-)
yes, consider it another donation. Powerbook G4, OS 10.3.9. other specs i don't recall offhand. let me know.
Can you build universal binaries with it? Meaning PPC and Intel.
eto, did u see my post above about having an old Powerbook if u want it?
Cypherdoc,
Yeah I saw it. I'll take you up on the offer if I can't get a VM working. I have some time before I get around to that, though. Unless you're trying to get rid of it now, I'll wait.
On the other hand, if the system is free, I don't mind paying for shipping. In the long run, it is probly better for me to just take it. Can you tell me OSX version and explain how it relates to other systems likely to be used by others?
yes, consider it another donation. Powerbook G4, OS 10.3.9. other specs i don't recall offhand. let me know.
eto, did u see my post above about having an old Powerbook if u want it?
Cypherdoc,
Yeah I saw it. I'll take you up on the offer if I can't get a VM working. I have some time before I get around to that, though. Unless you're trying to get rid of it now, I'll wait.
On the other hand, if the system is free, I don't mind paying for shipping. In the long run, it is probly better for me to just take it. Can you tell me OSX version and explain how it relates to other systems likely to be used by others?
Jump to: