When clients tie themselves to a single implementation it gets in the way of that goal.
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.
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.
