Armory - Discussion Thread

[Red Emerald]

etotheipi, can you please explain to me how is the address sweeping done?
Does it only sweep funds that are found on the address at the time of sweeping or is it possible to auto-sweep funds any time new funds arrive, a la MtGox?
If it doesn't auto-sweep, it would be a cool feature. I'm kinda tired of using the vanilla client wallet and would like to add all my addresses to an Armory wallet and have it auto-sweep the funds once they arrive.
Stop using my first wallet isn't something I can stop doing because of automatic payments I get to lots of addresses in there and having an Armory wallet that auto-swept those payments would be a peace of mind

+1 for auto-sweeping funds. I want to do the exact same.

[1713583743]

1713583743

[1713583743]

1713583743

[1713583743]

1713583743

[etotheipi]

etotheipi, can you please explain to me how is the address sweeping done?
Does it only sweep funds that are found on the address at the time of sweeping or is it possible to auto-sweep funds any time new funds arrive, a la MtGox?
If it doesn't auto-sweep, it would be a cool feature. I'm kinda tired of using the vanilla client wallet and would like to add all my addresses to an Armory wallet and have it auto-sweep the funds once they arrive.
Stop using my first wallet isn't something I can stop doing because of automatic payments I get to lots of addresses in there and having an Armory wallet that auto-swept those payments would be a peace of mind

Addresses are only swept once.  No information about the addresses is kept anywhere.  I determined that in most cases, if there's a swath of addresses you want to maintain in this way, you'll just make a new dedicated Armory wallet, and import/migrate the addresses there.  I'm sure an auto-sweep function would be useful in some circumstances, but that's very low priority compared to some of the other current issues -- like when Armory stops working due to blockchain file splitting at 2GB

Unfortunately, I won't get to implementing the new wallet format until after beta, so it could be 2+ months before I can support importing/migrating Satoshi 0.6.0+ wallets.  Only if the wallet was created pre-0.6.0 can any of the addresses be migrated or swept using Armory (it's because Armory doesn't know how to handle compressed public keys).  i.e. you won't even be able to use Armory for newer addresses anyway, so the lack of auto-sweep is not a critical deficiency.

[unclescrooge]

Hello

Today I sent some btc while in online mode. Armory was connected to the bitcoin client. Unfortunately the bitcoin client was not connected to the network, because of some firewall restriction (was at work).

Anyway, now I'm back home, the satoshi client is connected to the network, the blockchain is up to date but... the transaction doesn't get broacasted.

How can I unlock the bitcoins?

Thanks
Raphy

[unclescrooge]

Nevermind, I found the trick: delete the user folder and reimport the armory wallet

[etotheipi]

Nevermind, I found the trick: delete the user folder and reimport the armory wallet

I'm not sure why that worked.  I would think that issue is that the Satoshi client already added the tx to its own memory pool, and "broadcast it" once, and then won't broadcast it again.  And any tx conflicting with that one will be rejected.  Thus, you would need to clear the Satoshi-client memory pool in order to execute any more transactions with that wallet (at least any tx using any inputs used by the first tx).

I would expect that maybe the tx you finally sent used different inputs, or maybe you restarted the Satoshi client which might purge the memory pool of tx that aren't relevant to its own wallet (I don't know if it actually does that though...)

[unclescrooge]

I did restart the satoshi client, that must be what happened. Thanks for your time

[molecular]

I'm experiencing the "Illegal instruction" problem on my first-gen asus eeepc.

It seems to be an invalid instruction in the binary (I used the dependency bundle).

Ran an strace and it seems to be in the random number generator somewhere (I can't see an actual stacktrace, how do I dump one).

So I guess one of the dependency libs might've been compiled for a different CPU.

Ideas anyone?

[etotheipi]

I'm experiencing the "Illegal instruction" problem on my first-gen asus eeepc.

It seems to be an invalid instruction in the binary (I used the dependency bundle).

Ran an strace and it seems to be in the random number generator somewhere (I can't see an actual stacktrace, how do I dump one).

So I guess one of the dependency libs might've been compiled for a different CPU.

Ideas anyone?

Actually, I just ran into this the other day, too.  I don't know why it used to work and now it doesn't.  I have been compiling the binaries on Ubuntu VMs and it seems that the 32-bit systems are creating bad binaries.  Perhaps the CPU type of a 32-bit VM is "different"?   Anyone have any problems with the 64-bit packages?

I'll investigate this a little more thoroughly.  For now, I'll just compile it on a physical 10.04 32-bit system I have.  At least, the python2.6 package can be done there...

[molecular]

I'm experiencing the "Illegal instruction" problem on my first-gen asus eeepc.

It seems to be an invalid instruction in the binary (I used the dependency bundle).

Ran an strace and it seems to be in the random number generator somewhere (I can't see an actual stacktrace, how do I dump one).

So I guess one of the dependency libs might've been compiled for a different CPU.

Ideas anyone?

Actually, I just ran into this the other day, too.  I don't know why it used to work and now it doesn't.  I have been compiling the binaries on Ubuntu VMs and it seems that the 32-bit systems are creating bad binaries.  Perhaps the CPU type of a 32-bit VM is "different"?   Anyone have any problems with the 64-bit packages?

I'll investigate this a little more thoroughly.  For now, I'll just compile it on a physical 10.04 32-bit system I have.  At least, the python2.6 package can be done there...

what parts are you compiling? cpp4Swig?

just got a little closer: Makefile of cryptopp has "-march=native" compiler option so that gcc will generate code for you local platform. Depending on what machine you're on, you might easily generate non-i[3456]86-compatible code.

I'm about to test... with "-march=i686", but other problems pop up.

[etotheipi]

I just recompiled the 32-bit version on one of my physical machines running Ubuntu 32-bit (luckily, I have a lot of them!).  I don't have one for 12.04-32bit, but I guess I can make it happen if necessary.  Or maybe someone can help me figure out how I should be compiling crypto++ to avoid this problem.  The 'march=i?86" options sound kind of promising except I don't want to battle the crypto++ library too much... it's not my library, I don't want to mess with it...

Anyways, here's the updated armory_0.77_python2.6_i386.deb.  I tested it on my offline system and it worked.  Hopefully it will work for others, too.

[molecular]

just got a little closer: Makefile of cryptopp has "-march=native" compiler option so that gcc will generate code for you local platform. Depending on what machine you're on, you might easily generate non-i[3456]86-compatible code.

I'm about to test... with "-march=i686", but other problems pop up.

didn't work (illegal instruction)

I then tried with -march=i586 and after solving some other issues, like "forcing" to link against python2.6 (target system has python 2.6, build system 2.7).

It now works, no more "illegal instruction" when creating a wallet.

[etotheipi]

just got a little closer: Makefile of cryptopp has "-march=native" compiler option so that gcc will generate code for you local platform. Depending on what machine you're on, you might easily generate non-i[3456]86-compatible code.

I'm about to test... with "-march=i686", but other problems pop up.

didn't work (illegal instruction)

I then tried with -march=i586 and after solving some other issues, like "forcing" to link against python2.6 (target system has python 2.6, build system 2.7).

It now works, no more "illegal instruction" when creating a wallet.

What didn't work well?  The new binary installer that I posted?  Or compiling for i586/i686?  I think the new .deb file I posted should work on other 32-bit linux systems, and if it doesn't, I really don't understand what's going on.

I'm super curious why the 32-bit-binaries-compiled-on-my-VM used to work but now they don't...?  There was a very minor change made to the crypto++ library to make it work with the latest gcc, but that was just adding "this->" references to some calls.  Perhaps the behavior actually changed... I'll have to revert the crypto++ library and see if my VM can compile working code again...

[Foxpup]

Um, you guys do realise that i686 is actually a 36-bit architecture and is guaranteed not to work on a 32-bit system (or a VM that emulates one), right? 32-bit binaries should be compiled for i386 only. That's the standard architecture for IA-32 systems; the i[456]86 architectures are CPU-specific and should generally not be used without a good reason.

[etotheipi]

Um, you guys do realise that i686 is actually a 36-bit architecture and is guaranteed not to work on a 32-bit system (or a VM that emulates one), right? 32-bit binaries should be compiled for i386 only. That's the standard architecture for IA-32 systems; the i[456]86 architectures are CPU-specific and should generally not be used without a good reason.

Makefiles and compiling issues are not my strongest skillset.  Perhaps you can help me/us figure out what the problem might be...?  I'm about to revert the crypto++ updates made in 0.76 to see if that resolves the issue.  That will cause anyone using gcc 4.7+ to no longer be able to compile it, but I suppose I can maintain a gcc4.7 branch that follows the master with only the changes needed.

So, any recommendations?

[Foxpup]

Um, you guys do realise that i686 is actually a 36-bit architecture and is guaranteed not to work on a 32-bit system (or a VM that emulates one), right? 32-bit binaries should be compiled for i386 only. That's the standard architecture for IA-32 systems; the i[456]86 architectures are CPU-specific and should generally not be used without a good reason.

Makefiles and compiling issues are not my strongest skillset.  Perhaps you can help me/us figure out what the problem might be...?  I'm about to revert the crypto++ updates made in 0.76 to see if that resolves the issue.  That will cause anyone using gcc 4.7+ to no longer be able to compile it, but I suppose I can maintain a gcc4.7 branch that follows the master with only the changes needed.

So, any recommendations?

It's not my strong suit either, I just have enough experience with Linux programs whose installation instructions consist entirely of "Run make and fix compilation errors" to have some idea of what I'm doing in that area. First of all, don't use -march=native when compiling binaries for general distribution! I don't know about Ubuntu, but most "32-bit" distros these days actually use the P6 architecture instead of i386, which has the advantage of allowing you to use up to 64GB of RAM with a supposedly 32-bit CPU, but the disadvantage that code compiled for such a system will flat out not work on a true 32-bit system. You should be using -march=i386 for IA-32 and -march=k8 (er, I think...) for AMD64 (as well as -mtune=generic, though omitting it won't cause any errors, but may (or may not) have an effect on performance). That should at least fix the "Illegal instruction" issue, which is almost certainly caused by accidentally compiling for a CPU-specific architecture.

[etotheipi]

Um, you guys do realise that i686 is actually a 36-bit architecture and is guaranteed not to work on a 32-bit system (or a VM that emulates one), right? 32-bit binaries should be compiled for i386 only. That's the standard architecture for IA-32 systems; the i[456]86 architectures are CPU-specific and should generally not be used without a good reason.

Makefiles and compiling issues are not my strongest skillset.  Perhaps you can help me/us figure out what the problem might be...?  I'm about to revert the crypto++ updates made in 0.76 to see if that resolves the issue.  That will cause anyone using gcc 4.7+ to no longer be able to compile it, but I suppose I can maintain a gcc4.7 branch that follows the master with only the changes needed.

So, any recommendations?

It's not my strong suit either, I just have enough experience with Linux programs whose installation instructions consist entirely of "Run make and fix compilation errors" to have some idea of what I'm doing in that area. First of all, don't use -march=native when compiling binaries for general distribution! I don't know about Ubuntu, but most "32-bit" distros these days actually use the P6 architecture instead of i386, which has the advantage of allowing you to use up to 64GB of RAM with a supposedly 32-bit CPU, but the disadvantage that code compiled for such a system will flat out not work on a true 32-bit system. You should be using -march=i386 for IA-32 and -march=k8 (er, I think...) for AMD64 (as well as -mtune=generic, though omitting it won't cause any errors, but may (or may not) have an effect on performance). That should at least fix the "Illegal instruction" issue, which is almost certainly caused by accidentally compiling for a CPU-specific architecture.

Okay, I just started reading up on it, and I see what's going on.  Doesn't explain why it used to work then suddenly stopped working, but it sounds like was lucky that it ever worked!  Also explains why reverting the changes didn't help.

I see there is no -march=generic option, which is unfortunate because I figured there would be an instruction set that is supported by a majority of CPUs.  It looks like, just not using the -march option at all is what I want, and -mtune=generic. 

Does this also mean that I can use "-march=i386  -m32" to compile the 32-bit binaries on my 64-bit system?  It would be nice to be able to cross-compile, but I never bothered to figure out how, and have a separate VM for each .deb file...

[etotheipi]

It works!  (as far as I can tell)

I removed the -march=native option and now my VM compiles .deb packages that work on my offline computer.  I have no idea how or why it worked before, but it makes sense why it works now. 

PLEASE download and test the new version, especially if you were getting that "Illegal Instruction" error.  The links from my previous post are still valid, but copied here again for convenience.

http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77_Win64.msi
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77_Win32.msi (offline only!)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.7-1_amd64.deb  (Ubuntu 11.04+, 64-bit)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.6-1_amd64.deb  (Ubuntu 9.04-10.10, 64-bit)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.7-1_i386.deb  (Ubuntu 11.04+, 32-bit)
http://dl.dropbox.com/u/1139081/ArmoryTestingReleases/armory_0.77-python2.6-1_i386.deb  (Ubuntu 9.04-10.10, 32-bit)

[Foxpup]

I see there is no -march=generic option, which is unfortunate because I figured there would be an instruction set that is supported by a majority of CPUs.

If you think for a moment about what a CPU is and how it works, you'll realise what you're suggesting makes absolutely no sense. Every CPU has a single instruction set, and cannot use any other. IA-32 (i386) is a subset of all the various instruction sets used in x86-32 CPUs, and that's about a close as you're ever going to get to one instruction set being supported by a majority of CPUs. The instruction sets of other CPUs such as PowerPC, ARM, et al, are all totally incompatible with each other and with IA-32, so there's absolutely no way to compile code so that it works on all of them.

It looks like, just not using the -march option at all is what I want, and -mtune=generic. 

Actually, that may be what broke it in the first place. Specifying the target architecture is mandatory for the above reason. If you don't, the compiler will use the system default, which may not always be what you want. You must always specify what architecture you're compiling for if you want it to work on systems other than your own. I strongly recommend that you use -march=i386 -mtune=generic to avoid any future surprises.

-mtune doesn't actually have anything to do with what instruction set your target architecture uses - instead it just optimises your code for things like the cache size of a particular CPU and so on. Setting it to the wrong CPU (even a CPU that doesn't use the same instruction set as the one you're compiling for) won't ever break anything, but it can have a detrimental effect on your code's performance. Always set it to "generic" unless you have a specific CPU in mind.

Does this also mean that I can use "-march=i386  -m32" to compile the 32-bit binaries on my 64-bit system?  It would be nice to be able to cross-compile, but I never bothered to figure out how, and have a separate VM for each .deb file...

I've never cross-compiled either, but yes, that should work. Let me know how it goes.

[etotheipi]

I see there is no -march=generic option, which is unfortunate because I figured there would be an instruction set that is supported by a majority of CPUs.

If you think for a moment about what a CPU is and how it works, you'll realise what you're suggesting makes absolutely no sense. Every CPU has a single instruction set, and cannot use any other. IA-32 (i386) is a subset of all the various instruction sets used in x86-32 CPUs, and that's about a close as you're ever going to get to one instruction set being supported by a majority of CPUs. The instruction sets of other CPUs such as PowerPC, ARM, et al, are all totally incompatible with each other and with IA-32, so there's absolutely no way to compile code so that it works on all of them.

It looks like, just not using the -march option at all is what I want, and -mtune=generic. 

Actually, that may be what broke it in the first place. Specifying the target architecture is mandatory for the above reason. If you don't, the compiler will use the system default, which may not always be what you want. You must always specify what architecture you're compiling for if you want it to work on systems other than your own. I strongly recommend that you use -march=i386 -mtune=generic to avoid any future surprises.

-mtune doesn't actually have anything to do with what instruction set your target architecture uses - instead it just optimises your code for things like the cache size of a particular CPU and so on. Setting it to the wrong CPU (even a CPU that doesn't use the same instruction set as the one you're compiling for) won't ever break anything, but it can have a detrimental effect on your code's performance. Always set it to "generic" unless you have a specific CPU in mind.

Does this also mean that I can use "-march=i386  -m32" to compile the 32-bit binaries on my 64-bit system?  It would be nice to be able to cross-compile, but I never bothered to figure out how, and have a separate VM for each .deb file...

I've never cross-compiled either, but yes, that should work. Let me know how it goes.

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...

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.

[Foxpup]

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.