Topic: Armory - Discussion Thread - page 192. (Read 521829 times)
I'd like an option to toggle update #2, but other than that, everything looks great!
I didn't mention it anywhere, but here is my absolute top 4 priorities:
(1) New blockchain mgmt tools : Armory is going to stop working soon without it! Also, it will enable WinXP-32bit support and should reduce system requirements even further!
BETA!
(2) The new blockchain tools will also make it easier to save indexing info between loads to avoid the full scan and long load times. I liked the full scan because it added a statelessness to Armory that guaranteed everything would work if you just restart, and I didn't need to do anything... but the blockchain is getting too big to keep that solution.
(3) Coin control: this actually won't be terribly hard: the Armory codebase is already set up to handle it, I just need to make a GUI for it and test it. This wasn't going to be a top priority, but I've reached a critical threshold of requests
(4) New wallet format -- will include ability to import Satoshi 0.6.0+ wallets and will use the same algorithm as the Bitcoin-Qt devs are going to implement in an upcoming release. It will not only be faster, it will support arbitrary-dimensional wallets: you can have all your wallets created from a single seed, or create subwallets, etc. This is 1/3 done but had to quit because I didn't want to hold up the beta release...
Then... I will have to make a decision about whether to tackle independent networking or multi-signature transactions. I'm tempted to do multi-sig, because, while Armory remains a tool for advanced users, advanced users can handle the Bitcoin-Qt dependency (but they don't have to be happy about it). However, one of my original goals was to pioneer multi-sig interfaces, and it is something severely lacking from the community...
I'm happy to receive feedback about this. I think multi-sig will come before networking independence, so that everyone has everything! Then, with network-independence, I can stop adding new features and focus on interface design and the standard-usermode. Possibly even a lightweight mode.
(1) New blockchain mgmt tools : Armory is going to stop working soon without it! Also, it will enable WinXP-32bit support and should reduce system requirements even further!
BETA!
(2) The new blockchain tools will also make it easier to save indexing info between loads to avoid the full scan and long load times. I liked the full scan because it added a statelessness to Armory that guaranteed everything would work if you just restart, and I didn't need to do anything... but the blockchain is getting too big to keep that solution.
(3) Coin control: this actually won't be terribly hard: the Armory codebase is already set up to handle it, I just need to make a GUI for it and test it. This wasn't going to be a top priority, but I've reached a critical threshold of requests
(4) New wallet format -- will include ability to import Satoshi 0.6.0+ wallets and will use the same algorithm as the Bitcoin-Qt devs are going to implement in an upcoming release. It will not only be faster, it will support arbitrary-dimensional wallets: you can have all your wallets created from a single seed, or create subwallets, etc. This is 1/3 done but had to quit because I didn't want to hold up the beta release...
Then... I will have to make a decision about whether to tackle independent networking or multi-signature transactions. I'm tempted to do multi-sig, because, while Armory remains a tool for advanced users, advanced users can handle the Bitcoin-Qt dependency (but they don't have to be happy about it). However, one of my original goals was to pioneer multi-sig interfaces, and it is something severely lacking from the community...
I'm happy to receive feedback about this. I think multi-sig will come before networking independence, so that everyone has everything! Then, with network-independence, I can stop adding new features and focus on interface design and the standard-usermode. Possibly even a lightweight mode.
Anyone have any comments about 0.77? Given the lack of response to it, I suspect either no one is using it, or there are no complaints. Either way, it's about time to release it, because I'm positive there are some users out there suffering (or stopped using) due to the table-sorting bug.
does this support satoshi v0.6 wallet.dat import?
No, it does not.
Anyone have any comments about 0.77? Given the lack of response to it, I suspect either no one is using it, or there are no complaints. Either way, it's about time to release it, because I'm positive there are some users out there suffering (or stopped using) due to the table-sorting bug.
does this support satoshi v0.6 wallet.dat import?
No complaint whatsoever. Runs even more smoothly than the previous one.
I love your client you know
I love your client you know
etotheipi, when will Armory have "Send from" or "Coin control" feature? The lack of that is stopping me from forgetting official client. Oh, and also running bitcoind is annoying but I can live with that.
When an input from mined coins requires 120 confirmations to spend (such as P2Pool rewards), Armory won't recognize the transaction or give any information on it, instead comes up with an error "This is a non-standard transaction, which cannot be interpreted by this program. DO NOT ASSUME that you own these Bitcoins ... only an expert can tell you how these coins can be redeemed!"
If functionality for transactions with inputs directly from mined coins was added, this would be appreciated.
Is it also possible to not have to load the whole blockchain into the RAM (on Windows)? Couldn't Armory just save the blockchain to the disk (or use the Satoshi chain) and read from that? Thanks.
If functionality for transactions with inputs directly from mined coins was added, this would be appreciated.
Is it also possible to not have to load the whole blockchain into the RAM (on Windows)? Couldn't Armory just save the blockchain to the disk (or use the Satoshi chain) and read from that? Thanks.
Anyone have any comments about 0.77? Given the lack of response to it, I suspect either no one is using it, or there are no complaints. Either way, it's about time to release it, because I'm positive there are some users out there suffering (or stopped using) due to the table-sorting bug.
Haven't had a chance to pull that branch yet. I will probably have time tomorrow.EDIT: Oh cool. I see you went ahead and released it.
i'm using the online version w/o any problems. however, i'm a light user and use it just for accepting pmts for my subscription service. i send occasionally.
Anyone have any comments about 0.77? Given the lack of response to it, I suspect either no one is using it, or there are no complaints. Either way, it's about time to release it, because I'm positive there are some users out there suffering (or stopped using) due to the table-sorting bug.
Is there any way to restore the wallet from a seed in Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
It claims to have deterministic wallets, but I couldn't find an option to restore.
Wallets -> Restore from Paper Backup
Ok I somehow missed that, is there a way to get the seed without a printer and physical paper?
Print it to pdf.
Or just look at the print preview and write it down the old fashioned way. Like I always say, you just can't trust printers these days. They keep a record of everything you print. And add invisible patterns to your pages to identify you. That's how The Man gets you. ¬.¬
Is there any way to restore the wallet from a seed in Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
It claims to have deterministic wallets, but I couldn't find an option to restore.
Wallets -> Restore from Paper Backup
Ok I somehow missed that, is there a way to get the seed without a printer and physical paper?
Print it to pdf.
Is there any way to restore the wallet from a seed in Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
It claims to have deterministic wallets, but I couldn't find an option to restore.
Wallets -> Restore from Paper Backup
Ok I somehow missed that, is there a way to get the seed without a printer and physical paper?
Is there any way to restore the wallet from a seed in Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
It claims to have deterministic wallets, but I couldn't find an option to restore.
Wallets -> Restore from Paper Backup
Is there any way to restore the wallet from a seed in Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
I'm looking for a brain-only cold-storage wallet solution.
Is there a plan to add this functionality to Armory?
It claims to have deterministic wallets, but I couldn't find an option to restore.
I'm looking for a brain-only cold-storage wallet solution.
Is there a plan to add this functionality to Armory?
Code:
if bitcoind_available():
if bitcoind_rpc('getconnectioncount'):
echo 'online mode'
else:
echo 'Satoshi found, but it has no connections. Falling back to offline mode.'
else:
echo 'offline mode'
I think this would work and should be easy enough to implement.
Interesting idea. You're right there is no use cases I'm aware of for using Satoshi client if it's not connected to any peers. However, I've never accessed bitcoind via RPC, I didn't even know there was a way to query the number of connections. I assumed that if google/MS was ping-able, then the Satoshi client is at least capable of having peers. It seems that that assumption is not the case.
I don't suppose that connectioncount is something I can query peer-to-peer? Doesn't seem like it, but I also don't want to have to open another network connection just for this purpose...
So I'm running the latest git, but it still says .76. Shouldn't it be .77? It's also always sitting at 98% CPU and being really unresponsive 
It looks like you have a check to google.com to see if the network is up. Problem is, all my connections on this test system are proxied through Tor and sometimes google blocks Tor exit nodes so I get a socket timeout from line 729 of ArmoryQt.py in setupNetworking
Side note: The blockchain loaded in 90 seconds. Outside of a VM (on the host) it loads in about 60.
It looks like you have a check to google.com to see if the network is up. Problem is, all my connections on this test system are proxied through Tor and sometimes google blocks Tor exit nodes so I get a socket timeout from line 729 of ArmoryQt.py in setupNetworking
Side note: The blockchain loaded in 90 seconds. Outside of a VM (on the host) it loads in about 60.
To run from git, you need to switch to the "tablesortingfix" branch. I will merge the code into master once I'm ready to "release" it.
And yes, I know it's slowing down. The acceleration of blockchain size has me scrambling to get some major things updated sooner rather than later. Unfortunately, I'm just not there yet. :-/
Quote
As for "google.com", I also check microsoft.com ... I don't suppose that helps? I figured that was a reliable way to determine if you have a connection to the outside world, but I guess it isn't. Recommendations?
Is there any use case for having internet but no connection to bitcoind? If not, how about this pseudo-code:Code:
if bitcoind_available():
if bitcoind_rpc('getconnectioncount'):
echo 'online mode'
else:
echo 'Satoshi found, but it has no connections. Falling back to offline mode.'
else:
echo 'offline mode'
I think this would work and should be easy enough to implement.
Interesting idea. You're right there is no use cases I'm aware of for using Satoshi client if it's not connected to any peers. However, I've never accessed bitcoind via RPC, I didn't even know there was a way to query the number of connections. I assumed that if google/MS was ping-able, then the Satoshi client is at least capable of having peers. It seems that that assumption is not the case.
I don't suppose that connectioncount is something I can query peer-to-peer? Doesn't seem like it, but I also don't want to have to open another network connection just for this purpose...
So I'm running the latest git, but it still says .76. Shouldn't it be .77? It's also always sitting at 98% CPU and being really unresponsive
It looks like you have a check to google.com to see if the network is up. Problem is, all my connections on this test system are proxied through Tor and sometimes google blocks Tor exit nodes so I get a socket timeout from line 729 of ArmoryQt.py in setupNetworking
Side note: The blockchain loaded in 90 seconds. Outside of a VM (on the host) it loads in about 60.
It looks like you have a check to google.com to see if the network is up. Problem is, all my connections on this test system are proxied through Tor and sometimes google blocks Tor exit nodes so I get a socket timeout from line 729 of ArmoryQt.py in setupNetworking
Side note: The blockchain loaded in 90 seconds. Outside of a VM (on the host) it loads in about 60.
To run from git, you need to switch to the "tablesortingfix" branch. I will merge the code into master once I'm ready to "release" it.
And yes, I know it's slowing down. The acceleration of blockchain size has me scrambling to get some major things updated sooner rather than later. Unfortunately, I'm just not there yet. :-/
Quote
As for "google.com", I also check microsoft.com ... I don't suppose that helps? I figured that was a reliable way to determine if you have a connection to the outside world, but I guess it isn't. Recommendations?
Is there any use case for having internet but no connection to bitcoind? If not, how about this pseudo-code:Code:
if bitcoind_available():
if bitcoind_rpc('getconnectioncount'):
echo 'online mode'
else:
echo 'Satoshi found, but it has no connections. Falling back to offline mode.'
else:
echo 'offline mode'
I think this would work and should be easy enough to implement.
No, I'm not sure it works on all systems. But I never had a complaint when using march=native, which should be the least-compitible compilation option.
Unless your compiler machine is in fact a i386, then "native" would be ok
It seems this issue is pretty much sorted-out, I guess the gcc sane default will be, well "sane".
Thanks!
I actually meant "weighted majority" of CPUs -- I recognize that not all CPUs can use compatible instruction sets. However, a majority of users are using CPUs that have a common instruction set. I was under the impression that multiple instruction sets are generally supported on each CPU, hence "SSE", "SSE2", "3DNOW", etc. Given that I've seen large lists like that on CPU spec pages/boxes before, I suspect it's the case...
MMX, SSE, 3DNow!, etc are not instruction sets in their own right, but rather extensions of the standard IA-32 instruction set (this is the common instruction set for x86-32 CPUs). Any code which is compiled to use these extensions will not work on any CPU with an instruction set that doesn't include these extensions. As I understand, it is possible (in assembly) to write two versions of a function (one using the extended instructions and one using the just the standard instruction set) and have the program select which version to use by querying the CPU at runtime, but that's far beyond my level of expertise. Note that this is only possible because these extended instruction sets simply add new instructions without replacing or changing the standard instructions.Either way, I removed the -march option and it seems to work. The documentation suggests that gcc will decide for me what to compile, which is not march=native. Maybe I still have no idea what I'm talking about, but I'm going with what works. So far the python2.6-i386 works after the change. Please try the others and let me know.
Are you sure it works, though? On all IA-32 systems? Unless you're absolutely positive the default is safe, -march=i386 is the only way to be sure. Compiling for any other architecture is very likely to result in a binary that is guaranteed to crash on certain systems.No, I'm not sure it works on all systems. But I never had a complaint when using march=native, which should be the least-compitible compilation option. The fact that the gcc documentation says that leaving out the -march= option will pick some default of the year is probably exactly what I want. I think it picks i386 for 32-bit systems and k8 for 64-bit? I'm not totally sure. But it's better than what I had before without having to fill an evening learning about architectures and compilers.
I will take your advice and look into what I should be using. But as I said, the documentation suggests that not specifying the option usually causes it to pick a versatile one, and likely to be appropriate for the popular CPUs of the time that the gcc version was released.
Are you recommending i386 for all systems, or just the 32-bit systems?
Jump to: