Armory - Discussion Thread

[Daily Anarchist]

Best I can tell the file doesn't exist.

[etotheipi]

Best I can tell the file doesn't exist.

Well, if python-dev/python-devel is installed it's gotta exist somewhere.  That's the point of installing that package, to make it available.  In fact, the .so probably exists even with just python installed.  Apparently it's in a non-standard location in RH.

[K1773R]

use "locate" to find it!

[Daily Anarchist]

Okay, the locate helped. I apologize for my noobness.

Here's what I've got:

$ locate libpython
/usr/lib64/libpython2.7.so.1.0
/usr/lib64/gnome-vfs-2.0/modules/libpythonmethod.so
/usr/lib64/libpeas-1.0/loaders/libpythonloader.so
/usr/share/systemtap/tapset/libpython2.7-64.stp

So, I edited my Makefile to:

25    SWIG_INC     += -I"/usr/include/python$(PYVER)"
 26    STATICPYTHON +=   "/usr/lib64/libpython2.7.so.1.0"
 27 else
 28    SWIG_INC     += -I"$(DEPSDIR)/include/python$(PYVER)"
 29    STATICPYTHON +=   "$(DEPSDIR)/lib/libpython$(PYVER).so"

and still got:

ockObj.o BlockUtils.o EncryptionUtils.o libcryptopp.a "/usr/lib/libpython`python -c 'import sys; print str(sys.version_info[0]) + "." + str(sys.version_info[1])'`.so" CppBlockUtils_wrap.o -o ../_CppBlockUtils.so
g++: error: /usr/lib/libpython2.7.so: No such file or directory
make[1]: *** [swig] Error 1
make[1]: Leaving directory `/home/seth/BitcoinArmory/cppForSwig'
make: *** [all] Error 2

[Daily Anarchist]

SUCCESS!!!!   

Okay, normally, this is the time I move on with my life, but I really think it would be a good idea to share all of the steps I had to take, so that etothepi can put these instructions on the BitcoinArmory website for the NEXT person who runs Fedora and wants to install Bitcoin Armory. There are a lot of Fedora users out there and it would be a shame for them to turn away from using Bitcoin Armory because they couldn't figure out how to get it installed, or perhaps they saw there weren't installation instructions and didn't even try. So, here's everything I did in order to get Bitcoin Armory installed. I hope you'll put this up.

In addition to all of the packages you list to install, also include:

gcc-c++
python-devel
PyQt4-devel

Then have them edit cppForSwig/Makefile and

replace line 26 with:

26    STATICPYTHON +=   "/usr/lib64/libpython2.7.so.1.0"

and line 29 with:

29    STATICPYTHON +=   "$(DEPSDIR)/lib64/libpython2.7.so.1.0"

making sure to put either 64 or 32 depending on the architecture.

Then it should work great! And you've just increased the number of users that can and will use Bitcoin Armory.

Thanks for all the help guys!

[jl2012]

I have a suggestion: in "Backup Individual Keys" and "View Address Keys", please allow the user to choose whether the keys are delimited by spaces. Keys with spaces are not C&P friendly

[marcus_of_augustus]

But it doesn't seem to like the $(VAR) inside the shell...

You have to have some knowledge of what type of shell it is dropping into ... most POSIX-like shells will only accept variables inside curly brackets, e.g. ${VAR}

[DobZombie]

I've decided to give armory a go (most of the rest of the world spells it armoury, so my spell checker is going nuts right now ) and the site's not loading

[etotheipi]

I've decided to give armory a go (most of the rest of the world spells it armoury, so my spell checker is going nuts right now ) and the site's not loading

Ahh right.  I received notification that my webhost was ... moving.  They will be down part of today.   If you don't need directions, you can download the latest directly from the googlecode hosting (this is what is linked to from the bitcoinarmory.com website, anyway):

bitcoinarmory.googlecode.com downloads page

(If you're in linux, just checkout the "testing" branch)

Speaking of that:  Here is 0.87.2 which has a couple more stability fixes in it.  It turns out that I induced some problems with reorg handling a while ago, and had not rerun the reorg-unittest since then.  Now I have, and it should be smooth sailing through reorgs in version 0.87.2:

Testing version 0.87.2-testing for Windows 64-bit
Testing version 0.87.2-testing for Windows 32- and 64-bit
Testing version 0.87.2-testing signed SHA256 hashes of installers

As with 0.87.1:  the updates are tiny bugfixes with big stability impact.  Therefore, I believe that 0.87.1 and 0.87.2 are as stable as a full release, and hence I have provided signatures with them so users can feel comfortable with them.

You have to have some knowledge of what type of shell it is dropping into ... most POSIX-like shells will only accept variables inside curly brackets, e.g. ${VAR}

Yes, I am completely retarded when it comes to bash/shell scripting.  I wish everything could be python.  I'll try what you suggested.  Or maybe you can help me by figuring out how to detect that dynamic filename there...

I have a suggestion: in "Backup Individual Keys" and "View Address Keys", please allow the user to choose whether the keys are delimited by spaces. Keys with spaces are not C&P friendly

I've wanted to add a few options to that dialog for a while, but it never seemed like a high priority.  I need to look at what other import formats other services use, and perhaps add some site-specific list-formatting choices.  For now, I have simply written things out to optimize having to manually type it in.  But of course, I know many will be copy-pasting so I should accommodate that, too.

replace line 26 with:

26    STATICPYTHON +=   "/usr/lib64/libpython2.7.so.1.0"

and line 29 with:

29    STATICPYTHON +=   "$(DEPSDIR)/lib64/libpython2.7.so.1.0"

making sure to put either 64 or 32 depending on the architecture.

Interesting... maybe there just haven't been any real users on RH before you?  I definitely have not (or do not remember) having to deviate from the format that is there for any previous complaints.  I will have to investigate further how to accommodate this (I definitely need a smarter makefile)

[pvz]

Testing the armoryd branch...and armoryd... 

Setting up a watch-only wallet and make a php jsonrpc call works!
Now testing the process of getting unsigned transactions.

I have some troubles to add a additional watch-only wallet to armoryd.
I get this error after the notification 'Another instance of armoryd.py is already runnning!':

Code:

~/BitcoinArmory$ {
    "error": {
        "errortype": "exceptions.ValueError", 
        "extrainfo": "No JSON object could be decoded", 
        "jsoncommand": "armory_abc_.watchonly.wallet", 
        "jsoncommandargs": []
    }
}

It looks like I have to put in some extra arguments to make a second armoryd work with another watch-only.
I can't find what the arguments should be. (has it something to do with: AuthServiceProxy  def __call__(self, *args) ??)
Also I suspect armoryd does not except more arguments (your code states: # The only argument that armoryd.py takes is the wallet to serve)

Please let me know where to find some clues to get a second watch-only armoryd running.
I'm also wondering how the jsonrpc call is made. Is it to a different RPC_PORT? If not, how do I make a jsonrpc call to a specific wallet? If so, how do I know the rpc_port's of all wallets running?

I'm also wondering if it is possible to make use of the authentication of the (proxy) service to identify a wallet/user from the (php) jsonrpc. (otherwise I have to make a authentication for a wallet/user before the (php) jsonrpc call's could be done)

[etotheipi]

Testing the armoryd branch...and armoryd... 

Setting up a watch-only wallet and make a php jsonrpc call works!
Now testing the process of getting unsigned transactions.

I have some troubles to add a additional watch-only wallet to armoryd.
I get this error after the notification 'Another instance of armoryd.py is already runnning!':

Code:

~/BitcoinArmory$ {
    "error": {
        "errortype": "exceptions.ValueError", 
        "extrainfo": "No JSON object could be decoded", 
        "jsoncommand": "armory_abc_.watchonly.wallet", 
        "jsoncommandargs": []
    }
}

It looks like I have to put in some extra arguments to make a second armoryd work with another watch-only.
I can't find what the arguments should be. (has it something to do with: AuthServiceProxy  def __call__(self, *args) ??)
Also I suspect armoryd does not except more arguments (your code states: # The only argument that armoryd.py takes is the wallet to serve)

Please let me know where to find some clues to get a second watch-only armoryd running.
I'm also wondering how the jsonrpc call is made. Is it to a different RPC_PORT? If not, how do I make a jsonrpc call to a specific wallet? If so, how do I know the rpc_port's of all wallets running?

I'm also wondering if it is possible to make use of the authentication of the (proxy) service to identify a wallet/user from the (php) jsonrpc. (otherwise I have to make a authentication for a wallet/user before the (php) jsonrpc call's could be done)

The JSON-RPC interface is still a work in progress.  I haven't really ironed out things like this yet.  But I can give you some workarounds, as long as you promise not be upset when it changes later

Specifically, I will be making armoryd.py multi-wallet, just like ArmoryQt is.  It will load all wallets in a given directory, and you will be able to "selectwallet", "getwalletinfo", "sendfromwallet", etc.   Until then, I guess you'll just have to run multiple copies.

So first thing to do is that armoryd.py detects itself via the --rpcport option.  I forget the default but you should be able to start more instances by changing that value.  If you run armoryd.py on the same port as another one that's already open, it switches from "start-server" mode to "pass-CLI-arguments-to-existing-server" mode.  It reads the /home/user/.armory/armoryd.conf file for authentication info, opens a connection with it through the port, then it passes the command line arguments to it as a native JSON-RPC call.  It receives the response, prints it out, and disconnects.  After all... if they could somehow listen on the same port, how would PHP know which one it was talking to? 

I think the last part is answered by my multi-wallet answer.  If you have recommendations for how to accommodate multi-wallet armoryd that more intelligently, I'm happy to entertain it!

[N.Z.]

etotheipi, could you upload latest signed archive with source tarball to your site (or amazon)?

[etotheipi]

etotheipi, could you upload latest signed archive with source tarball to your site (or amazon)?

0.87 tag in git is signed, but I never actually signed any tar balls or anything.   I will make sure to go sign 0.87.2 tonight since I forgot.  Use "git tag -v v0.87"

I know the website is down-my webhost told me it should only be another day... They just moved their entire operation.

[pvz]

But I can give you some workarounds, as long as you promise not be upset when it changes later

I will not, without change there is no progress!

Specifically, I will be making armoryd.py multi-wallet, just like ArmoryQt is.  It will load all wallets in a given directory, and you will be able to "selectwallet", "getwalletinfo", "sendfromwallet", etc.   Until then, I guess you'll just have to run multiple copies.

For a daemon it is a good thing if the functions "addwallet(filename.wallet)", "removewallet(wallet name or file name)" and "rescanwallets" are available. If you want the daemon run for 24/7 a restart (to load a new wallet or exclude one) is not preferred.
Also the memory requirements is a attention. I do not know how the memory requirement with ArmoryQT for a additional wallet works, but I expect it is not 1.5Gb for each wallet.

I think the last part is answered by my multi-wallet answer.  If you have recommendations for how to accommodate multi-wallet armoryd that more intelligently, I'm happy to entertain it!

Yes you did, I will happy to do so and thanks!

[etotheipi]

For a daemon it is a good thing if the functions "addwallet(filename.wallet)", "removewallet(wallet name or file name)" and "rescanwallets" are available. If you want the daemon run for 24/7 a restart (to load a new wallet or exclude one) is not preferred.
Also the memory requirements is a attention. I do not know how the memory requirement with ArmoryQT for a additional wallet works, but I expect it is not 1.5Gb for each wallet.

I think the last part is answered by my multi-wallet answer.  If you have recommendations for how to accommodate multi-wallet armoryd that more intelligently, I'm happy to entertain it!

Yes you did, I will happy to do so and thanks!

Yeah, I definitely want to have the add/remove/create/rescanwallet functions.  Armory is capable of doing it, though adding a wallet will usually induce a rescan which could make your make your JSON interface useless for a couple minutes.  Even though I have multithreading already, I realized it shouldn't be too difficult to do a raw rescan without TheBDM at all, meaning it could happen without putting Armory into offline mode, and then it would simply injected the registered transactions it finds when it's done (it would be a bit of work modify it like this, but it would work).

Unfortunately, 24/7 is a stretch at the minute:  I am experiencing seg faults when Bitcoin-Qt/bitcoind splits block files, even though I have a unit-test that tests exactly that event!  I'm going to have to dig into this again.

On the other hand, this all goes away when I do the full/final RAM reduction and finally have Armory maintaining its own blockdata.  Once I have this, there is no more clashing with Bitcoin-Qt, and a whole host of problems will go away.  I'm very temped to jump back to this before the new wallets, because of the usability improvement in addition to al lthese stupid problems going away.

etotheipi, could you upload latest signed archive with source tarball to your site (or amazon)?

N.Z.  I just pushed a signed tag into the git repo.  You can checkout the tag, v0.87.2-beta, and verify it using "git tag -v v0.87.2-beta". 

[N.Z.]

N.Z.  I just pushed a signed tag into the git repo.  You can checkout the tag, v0.87.2-beta, and verify it using "git tag -v v0.87.2-beta". 

Thanks

[pvz]

Yeah, I definitely want to have the add/remove/create/rescanwallet functions.  Armory is capable of doing it, though adding a wallet will usually induce a rescan which could make your make your JSON interface useless for a couple minutes.

Is it a option to do the rescan in a (parallel) external process? If this process returns the input, to the under laying database or memory, it takes a time span to obtain the data but the armoryd processes can keep running?
Or a temporary armoryd for the rescan of the specific new wallet. Gathered additional info (addresses and transactions for this wallet) put into the database/memory and the temporary armoryd exits.
I'm very n00b with this kind of processes, but I do hope this kind of solution is possible.
I still prefer a stable and 24/7 daemon. The add/rescan process is necessary, can take some time, but should not stall any daemon/JSON processes.

Even though I have multithreading already, I realized it shouldn't be too difficult to do a raw rescan without TheBDM at all, meaning it could happen without putting Armory into offline mode, and then it would simply injected the registered transactions it finds when it's done (it would be a bit of work modify it like this, but it would work).

Unfortunately, 24/7 is a stretch at the minute:  I am experiencing seg faults when Bitcoin-Qt/bitcoind splits block files, even though I have a unit-test that tests exactly that event!  I'm going to have to dig into this again.

On the other hand, this all goes away when I do the full/final RAM reduction and finally have Armory maintaining its own blockdata.  Once I have this, there is no more clashing with Bitcoin-Qt, and a whole host of problems will go away.  I'm very temped to jump back to this before the new wallets, because of the usability improvement in addition to al lthese stupid problems going away.

I cannot understand exactly what you are trying to say, but it seem to me this is a big and crucial decision for the way Armory functions within the bitcoin (software) environment.
I do remember your primary reason to stick with the original bitcoin client are the network functions. If you maintain your own blockdata, can you still use the networkfunctions?
Scanning the blockdata to be able to add a wallet (concerning historical data) is a lot different than to add data to the (own) blockdata yourself (concerning new data).

On the other hand, maybe the way the original bitcoin client adds data is not difficult at all?

[etotheipi]

Yeah, I definitely want to have the add/remove/create/rescanwallet functions.  Armory is capable of doing it, though adding a wallet will usually induce a rescan which could make your make your JSON interface useless for a couple minutes.

Is it a option to do the rescan in a (parallel) external process? If this process returns the input, to the under laying database or memory, it takes a time span to obtain the data but the armoryd processes can keep running?
Or a temporary armoryd for the rescan of the specific new wallet. Gathered additional info (addresses and transactions for this wallet) put into the database/memory and the temporary armoryd exits.
I'm very n00b with this kind of processes, but I do hope this kind of solution is possible.
I still prefer a stable and 24/7 daemon. The add/rescan process is necessary, can take some time, but should not stall any daemon/JSON processes.

Even though I have multithreading already, I realized it shouldn't be too difficult to do a raw rescan without TheBDM at all, meaning it could happen without putting Armory into offline mode, and then it would simply injected the registered transactions it finds when it's done (it would be a bit of work modify it like this, but it would work).

Unfortunately, 24/7 is a stretch at the minute:  I am experiencing seg faults when Bitcoin-Qt/bitcoind splits block files, even though I have a unit-test that tests exactly that event!  I'm going to have to dig into this again.

On the other hand, this all goes away when I do the full/final RAM reduction and finally have Armory maintaining its own blockdata.  Once I have this, there is no more clashing with Bitcoin-Qt, and a whole host of problems will go away.  I'm very temped to jump back to this before the new wallets, because of the usability improvement in addition to al lthese stupid problems going away.

I cannot understand exactly what you are trying to say, but it seem to me this is a big and crucial decision for the way Armory functions within the bitcoin (software) environment.
I do remember your primary reason to stick with the original bitcoin client are the network functions. If you maintain your own blockdata, can you still use the networkfunctions?
Scanning the blockdata to be able to add a wallet (concerning historical data) is a lot different than to add data to the (own) blockdata yourself (concerning new data).

On the other hand, maybe the way the original bitcoin client adds data is not difficult at all?

The second part that you quoted of me answered your first part -- having it scan completely in the background without stalling the BDM is what I will do.  It will require a bit of work, because right now "scanning" involves updating the BDM as it is scanning, which is why it must go offline to avoid race conditions.  But I can execute the scan in a ghost thread, then extract just the collected data and inject it into TheBDM when it's done.  The injection would take a fraction of a second, so it would hardly be noticeable. 

The downside is that I need to implement more interface options, such is "isScanning", "queuedAddresses", etc.  It's doable and necessary -- it's just not trivial.

I know how important 24/7 stability is.  And I'm almost there -- I currently, already, run Armory for 5+ days at a time, in both Windows and Linux.  The last couple issues are tough to track because of how infrequent they are, but I am fairly certain they have to do with timing issues related to clashing with Bitcoin-Qt in the blkfiles.  If I simply got everything from Bitcoin-Qt via sockets and managed my own blockchain files, those would go away, by definition, but I think I will be fixing them, as-is, right now.

Btw, I only use Bitcoin-Qt as a regular peer -- no JSON-RPC -- but it is a trusted peer (critical!).  It is essentially a filter/gateway between Armory and the rest of the network, endowing Armory users with the network security of Bitcoin-Qt/bitcoind, filtering out invalid tx and blocks, etc.  Armory still organizes the headers, calculates the longest chain, invalidates orphans, etc.  But it relies on bitcoind/-qt for the nitty-gritty verification activities, and DoS protection, etc.

[etotheipi]

Can someone please do me a favor and update How to set up a secure offline savings wallet wiki page with some reference to Armory.  There's a couple other linked pages, there too.  It's depressing to see not even a hint that other applications exist that make this so much easier.  It would be even better if there was a second half of the page that explained how to do it with Armory (and screenshots?), but that's not totally necessary...

There's a lot of pages there for which it would be wholly appropriate to at least have a reference to Armory (and probably Electrum, too), even it only mentions it as an afterthought. 

Here's some links that can be used to update the wiki:

http://bitcoinarmory.com/
http://bitcoinarmory.com/index.php/using-offline-wallets-in-armory
http://bitcoinarmory.com/index.php/armory-quick-start-guide
http://bitcoinarmory.com/index.php/get-armory

[pvz]

@etotheipi
On your site the instruction to make a offline wallet might need some addtional instructions.
In: Using an offline wallet in Armory -> 4. Double click on the wallet and click on “Create Watching-Only Copy”
It seems to me this is only possible in the Advanced and Expert mode (not in Standard).