Bitcoin Forum

So, I'm running a full node on my computer with bitcoin-qt, and the only reason that I'm running said full node is because Armory requires it to run properly.  Maybe I shouldn't bother because I don't have any bitcoins any more other than dust, but I might buy more in the future, and I would want to keep them in Armory.

Thus, the question: is there any possible way (development wise) to make Armory have a thin client option without sacrificing it's existing security?  If it's not possible to do this without sacrificing security, I'd say don't bother, because that's the reason I use Armory, and I suspect that's true for most people who use Armory as a client.

Our plan is to have a lite node eventually. Part of the team is working on code to prepare that front. Granted, there still are a few major features to add before we can integrate lite nodes.

One thing you can do now is run bitcoind instead of bitcoin-qt, so at least you don't have an extra GUI cluttering up your desktop.

Awesome.  I'm glad to hear that.  Most of the time, it's not an issue, but I had to reindex the whole blockchain when I upgraded to bitcoin-qt 0.9.0, which has been sorta slowing my computer all day.  Not as long a process as the original download was, but I'd love to be able to do without it entirely.

I'm really looking forward to Armory no longer needing blockchain file-level access to a Bitcoin node.

I'd rather run Armory against a btcd node, and the only thing stopping that from working is that btcd doesn't use the same file format for storing the blockchain.

A lite node would achieve that, but they you wouldn't be a full node. I'm assuming what you're thinking of is a Armory mode that takes its block from p2p instead of local file access. We may look into that in the far future, however I don't think that's the direction we're taking right now.

Exactly.

That's disappointing, because it's good to encourage people to run full nodes, and it's also good for the network if full node implementations are heterogeneous.

When clients tie themselves to a single implementation it gets in the way of that goal.

Our current approach is to use bitcoin-core as our network gateway and block verification. From our point of view, we opt for the added security and reduced implementation cost.

To give you an idea of the implementation cost to move to such model: currently Armory only uses bitcoin core to push transactions to the network. New blocks are detected by polling the blockchain folder. We could move to a model where we receive and parse new blocks from p2p directly. That would be cheap to implement but Armory would need access to a local copy of the blockchain, and it would still need bitcoin core as a gateway, so there's no improvement in the attempt the decouple from a permanent bitcoin core process.

We mentioned in some discussions between devs to consider integrating the core's connectivity codebase directly to Armory, since we now have the manpower. The current implementation is cheap and secure, no wonder Alan opted for it. The opposite isn't quite as true. We'd have to build a in house wrapper around the current bitcoin core network classes and adapt it as new releases come out. Admitedly bitcoin core isn't changed all that often so we could do that, but it would still require of one of us to maintain it for every release, the same way one of us is dedicated to testing and guaranteeing builds on his dedicated OS.

That has a certain cost that we can't justify right now, seeing that we currently have very few issues with bitcoind and that bitcoin core is striving to offer a strong gateway/p2p router solution. The added benefit to our users however is simplicity and versatility in their setup, and this is probably the only reason we have not entirely given up on this front. The true issue is the implementation cost vs returns. We have a functional setup right now.

Another approach would be to drop bitcoind and use our upcoming litenode servers to maintain grab a full copy of the chain. However Armory would still not run as a full node, since this time it would use our centralized servers for connectivity. What I am getting to is that there is no shortcut in fully decoupling Armory from bitcoin core and still functionning as a full node.

Ideally, we want to support and promote full nodes, and the safest, simplest way for us to do this is to piggy back on bitcoin core. This is why, if we ever plan on moving to another model, it will be on a very low priority, as we have other fronts we need to expand on first, and why I mentionned the far future. I hope this gives you a clearer idea what to expect on that front.

I understand all of this. What you don't appear to understand is that I like this general model, and I also want the ability to use alternatives to Bitcoin Core.

Bitcoin Core is just one of several implementations of the Bitcoin protocol so there's no reason it should be treated as occupying a privileged position.

You can use disablewallet even if armory controls bitcoin.  Just put disablewallet=1 in your bitcoin.conf file.  This will disable the wallet even if Armory is running the bitcoind as far as I know.

I'm running with Armory with disablewallet on my Ubuntu machine.  In this case Armory doesn't control the bitcoind. 
I'm also running Armory with disablewallet on a Win 7 machine.  In this case Armory does control bitcoind.
A possible advantage for you may be that I read somewhere disablewallet speeds up bitcoind.