Does Armory supports RPC?

[kobik]

Does Armory supports RPC like Bitcoin Core?
Can I send RPC commands to it to query my wallet balance/transactions; create new wallet; etc... ?

[1715099972]

1715099972

[1715099972]

1715099972

[1715099972]

1715099972

[goatpig]

https://github.com/goatpig/armoryd

[droark]

Note that, in order to run armoryd, you'll need ArmoryDB from Armory. I thought I had PRed a README I've been working on but I must not have finished it since I can't find the PR. I'll get it up sooner or later.

[kobik]

https://github.com/goatpig/armoryd

Thanks. I downloaded the ArmoryStandalone for windows but the armoryd is missing. where can I obtain it?
Alos, is there a list of supported RPC commands?


BTW, why is the ArmoryDB.exe process remains running after I quit ArmoryQt.exe? Is That normal? (version 0.96.3 for Windows)

[droark]

https://github.com/goatpig/armoryd

Thanks. I downloaded the ArmoryStandalone for windows but the armoryd is missing. where can I obtain it?

From the link goatpig provided. It's basically a Python file.

Alos, is there a list of supported RPC commands?

armoryd auto-generates a list of commands. I believe it's python armoryd.py --help but I haven't run it in awhile.

BTW, why is the ArmoryDB.exe process remains running after I quit ArmoryQt.exe? Is That normal? (version 0.96.3 for Windows)

It's not normal. The FCGI code doesn't always shut down properly. (We'll fix it...eventually.) Close it down if Armory isn't running.

[kobik]

From the link goatpig provided. It's basically a Python file.

Is there a standalone armoryd  EXE file?

[goatpig]

No, you have to freeze the script yourself into an executable.

[kobik]

I run  python armoryd.py --help

but I get an error:

 File "armoryd.py", line 316
    raise InvalidTransaction, "file does not contain a valid tx"
                            ^
SyntaxError: invalid syntax

I have Python36 installed on Windows

[goatpig]

This is python 2.7

[kobik]

Can you please add a compiled armoryd.exe into the download package? That would be really great for us newbies!

BTW, can a new Armory wallet be created via RPC? if not, is there some other external way from outside ArmoryQt?

[goatpig]

Can you please add a compiled armoryd.exe into the download package? That would be really great for us newbies!

No. Using the daemon means you know what you are doing. If you cant run "python armoryd.py" from the command line, stay away from this.

BTW, can a new Armory wallet be created via RPC?

Yes.

if not, is there some other external way from outside ArmoryQt?

Create a wallet on whatever machine that can run ArmoryQT, take the wallet file to headless machine.

[kobik]

Can you please add a compiled armoryd.exe into the download package? That would be really great for us newbies!

No. Using the daemon means you know what you are doing. If you cant run "python armoryd.py" from the command line, stay away from this.

BTW, can a new Armory wallet be created via RPC?

Yes.

if not, is there some other external way from outside ArmoryQt?

Create a wallet on whatever machine that can run ArmoryQT, take the wallet file to headless machine.

Sorry to have bothered you. I'm not familiar with Python at all, but that does not mean I don't know what I'm doing. I have used boitcoind RPC quit successfully, and it is build into their package ready to use.
You don't need to patronize. I know you are an Armory (main?) developer and probably know all the inside outs. but I am not, and willing to learn!

Replying that Armory can support creating a new wallet via Armory RPC with "Yes" is not helpful, if you can't say which command to use. I have looked into the armoryd.py source and did not find any code for command for that.
As I mentioned I got an error trying to run "python armoryd.py" (with Python 3.6 installed). I will install Python 2.7 and hopefully  that works for me.
Thanks again and keep doing a good job.  

[droark]

Hi kobik. Regarding bitcoind, it's written entirely in C and C++. Compiling and linking leads to an executable on all platforms where it can be compiled. Because Armory is a mix of Python and C++, it's a different kettle of fish. When I was with ATI (the company that maintained Armory for awhile), we had been looking into using Cython to "compile" the Python code into C code. (In fact, I think it was my final task there.) Other than solutions like that, Python just functions differently. On Windows, there are tools for packaging everything into an executable for users. On Linux, it's assumed that users are smart enough to use Linux. (macOS uses a quasi-compiled thing that, under the hood, is basically the same as Linux.)

Anyway, the point is that you'll need to understand how Python works. It's not that hard. Go read some tutorials in order to understand how Python works. Once you're comfortable, you can come back. Remember, you need Python 2.7 for armoryd (and Armory, really). Work is slowly progressing on an upgrade to Python 3.

Regarding examples, armoryd does have a few built-in examples. I'm working on some documentation so that people do have some idea regarding what to do. If you look at the armoryd source code, you'll see some examples in the comments.

Best wishes.

[kobik]

Thanks @droark!

Your comments were very helpful  

I went other the armoryd.py code, and the RPC conventions are very similar to bitcoind commands, which is great.
But no were I could find a method to create a new wallet file via RPC, and later on load it into the armoryd server list?

[droark]

You're welcome.

There isn't a method for creating a wallet. (You can create lockboxes, though.) My guess regarding the reasoning would have to do with ensuring that all the points hit when creating via the GUI are copied over, not to mention the possibility of transmitting the password over an insecure network. Granted, some methods do require an unlocked wallet. I suppose the idea is that there's a difference between choosing to compromise the password on an insecure network, and fundamentally risking the wallet security when it's created.

Or, maybe nobody thought to add such functionality. Personally, I'm for it as long as the user understands the risks involved when using a remote connection. (See what I said about unlocking wallets.) I've got quite a few things on my plate, though, and won't be writing it anytime soon. If others want to take a crack at it, check with goatpig, but I certainly won't complain.

[kobik]

Or, maybe nobody thought to add such functionality.

 

Personally, I'm for it as long as the user understands the risks involved when using a remote connection. (See what I said about unlocking wallets.)

I greatly appreciate your answer and your patience. As I already said, I'm quite sure I know what I'm doing and the risks involved. My objective is to create an internal intranet service  where we could manage different accounts (wallets) for employees.
Our server is well secured and I like to be able to manage wallets via an internal service that will "talk" to Armory via RPC (which will talk to bitcoind).
I love the fact that Armory is using bitcoind as a full node, but the downside of bitcoind is the lack of dynamic wallets management. Adding a new wallet requires shutting down the bitcoind, adding a wallet entry to the bitcoin.conf manually, and starting the bitcoind manually. this is quite annoying.

I find Armory to be very well designed, but I need the GUI functionality of managing wallets to be done via RPC including adding fresh new wallet for an employee instead of  doing that manually via GUI.
So I think this feature will be great for us and others!  

[goatpig]

Or, maybe nobody thought to add such functionality.

 

Ugh my bad, it's lockboxes you can create remotely, not wallets.

As I already said, I'm quite sure I know what I'm doing and the risks involved

The issue with creating wallets dynamically is 2 fold: your servers will be carrying the private seed, and how do you back that up? It's not that it can't be done, but the opsec are poop. What you'd want instead is a wallet model where you have one master seed, and any amount of child wallets derived on the fly from that seed. That's for 0.97, which is a couple months away at the earliest.

I love the fact that Armory is using bitcoind as a full node, but the downside of bitcoind is the lack of dynamic wallets management.

What I can offer you in the short term is a method to import wallets from their seed (either public or private). You'd have to create the wallets in the GUI, deal with the backups and what not, then you can register that wallet with armoryd through the 72 character seed.

I find Armory to be very well designed, but I need the GUI functionality of managing wallets to be done via RPC including adding fresh new wallet for an employee instead of  doing that manually via GUI.
So I think this feature will be great for us and others!  Smiley

What do you want this for? I think you're confused about Armory's stack. This is how it works:

- The GUI, which deals will all things UX and wallets/crypto. The GUI connects to the DB over a socket. The DB can be remote but right now there is no encryption layer over that socket. That's for 0.97 too.

- The DB, that deals with all things blockchain. A GUI registers the addresses in its loaded wallets with the DB. The DB tracks these addresses and passes on balances and historical data back to clients. The DB requires a full node that's fully compatible with Core's P2P, RPC and on disk blockdata serialization. The DB needs disk access to the blockdata. There can be many clients per DB.

- armoryd uses the same socketing interface as the GUI, i.e. it can connect to a DB remotely. armoryd DOES NOT interface with GUIs, or other armoryd instances. It only presents a JSON-RPC interface to users. Registering a wallet through armoryd will NOT affect other GUIs nor armoryd instances. It's just another isolated client.

From your description, it feels like you are expecting things out of armoryd that it was never designed to do. You should lay out your logistics at least, so we can tell if your requirements can be met.

[kobik]

Thanks @goatpig for the useful information.  
I need to digest all of it, as I'm very new in the bitcoin world.
I never thought about the seed being tied to my server. I thought a backup command was available so I can copy/backup the wallets to a safe place.
Am I to understand that if I back up a wallet on machine A, and then restore it on machine B with Armory it could not be done? Again sorry for the dumb questions...

My model is quite simple as I already described. I want to be able to manage multiple wallets/account for our emploies on a headless server (I hope the terminology is correct).
This server will be protected and will have ports 8333 opened for the full node management i.e. bitcoind (and might also 8332 main/18332 tesntnet - for RPC internally).

The wallets files will be hold on the different server (or on the same server).

All the management will be done via a web-service (in our intranet only) talking to the bitcoind via RPC. e.g. opening new wallets; query of balance; send/receive funds; etc... I will be responsible for a web GUI talking to that web-service (talking to whatever full node via RPC).

What I was after is something like ethereum geth, which acts like a full-node, but lets me easily create and manage accounts (wallets) via RPC.

I toght Armory will let me do that bridge to the bitcoind, but the wallet managements will be done in Armory instead of bitcoind Wallets.

[goatpig]

I never thought about the seed being tied to my server. I thought a backup command was available so I can copy/backup the wallets to a safe place.

You can backup the seed of course, but you're sending it over a socket and it's sitting in your online machine as well. That's an attack surface you should be trying to reduce, not the other way around.

All the management will be done via a web-service (in our intranet only) talking to the bitcoind via RPC. e.g. opening new wallets; query of balance; send/receive funds; etc... I will be responsible for a web GUI talking to that web-service (talking to whatever full node via RPC).

You can run 1 DB and let your users have access to their wallet in GUIs each. The DB also has its own language over the socket, which goes over the FCGI protocol, ie from your end you can display balance and history with HTML/js straight from the DB if you'd like to go down that route. The RPC is fine too.

I toght Armory will let me do that bridge to the bitcoind, but the wallet managements will be done in Armory instead of bitcoind Wallets.

It does that but you need to elaborate on your requirements and opsec. How many addresses do you expect to use per employee? If it's only 1, just use lockboxes. Do you intent to give your employees signing privileges? If no, then only load watching only wallets in armoryd. It can create unsigned transactions that you can review and sign with an offline GUI/armoryd instance that has the full wallets loaded.

At any rate you are better off just letting armoryd run on watching only wallets and let people sign offline through the GUI, whether it's you or your employees. This model suggests you create the wallets offline and only import the public seed in armoryd.

So the question remains, do you actually need to create full wallets at all from the RPC? Chances are you don't, and shouldn't.