I almost forgot... Sure I'll take your watching only wallet. PM if you feel like it.

I don't know what's up with you but you do have a tendency of attracting the worst luck ever. This first testing version retains a bug from 0.90 that got fixed after etotheipi put out the download links. It's a rare form and you in your glorious maelstrom of god knows what managed to catch it along with the rest. I hope you win at some lottery at some point in your life balance all this crap, sincerely.

Anyways, the ledger entry issue and some other minor wallet related fixes come after the current test build, and this is what I suspect you are trully aiming for. Keep in mind, whoever is using 0.90.99 and any versions to come, that you cannot piggy back off of an existing Armory DB with this. Some of the DB inner settings were changed and you'll have to rebuild it from scratch with the newer versions. It is is a matter of days before the next testing build, granted we delayed again to cram in a couple extra additions. Sorry about that, it's a long process by all means.

Also, loading with no wallet on the current test version is not gonna get you anywhere. That part was fixed again after that first test build was put up.

I have no intention to sugar coat anything. The perception you have of me is irrelevant in this matter. You were given a choice and you took it. You chose to stick with our recommendation. That's the choice of security, and its cost is convenience. We're back at the same discussion.

I am not denying the existence of this issue nor your state of distress. If you can't see this issue from our end of the spectrum, however, you are only going to frustrate yourself further. I already exposed that these errors are hard to fix because we cannot reproduce them in our dev environment.

I'll make this offer to you right now: send me your watching only wallet and I'll look at it personally. How I distribute the fix if your wallet proves to be crippled by an issue we haven't fixed yet, that's something up to discussion, but it WILL involve that you step out of your comfort zone at least as much as you'd have to by delivering your watching only wallet to me. You'll have to PM me to set up a direct line to deliver the wallet.

You compare us to MtGox. You are mistaken in thinking what ticks me off is the comparison in image. Frankly I don't care if you love or hate us. Murphy's law is a developer's nightmare and some users like you will have the worst time ever using our product. That damage is done. While I can fix the bug, I can't fix the image, nor will I try to. For you to find the patience to wait on the fix or the goodness to forgive the mistakes is not a process I can be part of, nor am I foolish enough to try.

What ticks me off is displaced guilt. MtGox was responsible for its customers funds. With Armory the users have this responsibility. You have a say in the matter. You had 2 informations at your disposal: there is a fix in the dev branch and we do not recommend using the dev branch. You made your choice and I frankly think it was the better one. A third choice would have been to cut your losses. Implying that no other alternative exists but to wait for us to give you back control of your coins is wrong.

As for the support, believe it or not, this is done on personal time. And none of us are here 24/7. You also caught us at a busy time. The 2 seniors were way busy, the 2 new employees still in training, that leaves me and I'm not here all the time. Once it gets to the point where the issue is fixed, what do you want me to say to you besides hang in tight for the next release? I simply cannot provide you with a way of getting your current version of Armory to avoid this bug. What does that leave? Maybe it would be more comfortable to receive a weekly notice from the team that we are doing our best to deliver the newest release blah blah... but in the end, that won't amount to a faster resolution.

Zoella: Seeing that you were asking for a testing build I went ahead and assumed you were a Windows user. The restriction on releases only truly affects Windows users. If you are a Linux user and want up to date fixes, just pull the dev branch and try out the new code. This is open source for a reason.

On Windows, you need to install 4 different software suites, about 10 python packages, configure everything properly, then you can build. On Debian/Ubuntu, this is all you have to do to build from source:


Found here: https://bitcoinarmory.com/download/building-armory-from-source/

If you want to build the dev branch instead of the master branch, do this between step 3 and 4:


This is what I mean when I say you didn't do your research. You had alternatives, between just dumping Armory and moving on, or trying to build the dev branch and see for yourself. The counter part to security is convenience. You want the security of a release with all the fixes, you are at our mercy. You want the up to date fixes right away, pull the dev branch at your own risk. No amount of bitching or hair pulling is going to change this. Or you can move on and come back when it's working.

We certainly want you to use our software, but in terms of priority, we'd rather you get to use your bitcoins, even if it means you can't use Armory for the time being. This why the fail safes are in place. Again, this is reality, no amount of insulting me if going to change that. And it won't advance your case any further.

However, to me it looks like you are not aware of all of the options at your disposal. We've had Windows users that got frustrated enough they installed Ubuntu and built from source. You're a Linux user and are asking for a hot fix release when clearly you are not part of the demographic limited to a release format.

You act in all points like the users who can't broadcast their transactions. You insist on doing it through Armory when you can grab the hex output and broadcast elsewhere. The only outcome is frustration, on both sides. Either work around the issue or use something else until we get better at our jobs. But stop it with that mentality that we somehow owe you something. This is free, open source software. The EULA clearly states you are using it at your own risk. If you can't get it to work or it refuses to work, don't expect a quick delivery on a fix. In view of certain bugs, we had to overhaul entire parts of Armory and add new features to support it, because that was the only way to deliver a robust fix. Consider our reality too and act accordingly.

simmo77, Finnminner: Looks like the ledger issue. Obviously if Armory has failed across several installs and blockchain copies, the issue lies within the wallet, or rather the transactions holding your coins. The reason we never run into this issue is because the wallets we use don't have coins held by these transactions messing Armory up. For the record, this is how I caught the ledger entry issue: A user got frustrated enough he sent his incriminated watching only wallet. This was fixed within the day. Again this is a good example of convenience vs security: your privacy against helping us fix a bug.

Finnminner: I mentionned this as a reference to users who can get Armory online but have issues broadcasting their transactions. In your case, idoB has it right, you have to grab the private keys through the backup center and use another client/webclient to move the coins.

There are 2 possibilities here:

1) The transaction you emitted was accepted and broadcasted by your local BitoinQt. It eventually got mined and your funds are where they should be, you're just not seeing it in Armory. This implies your BitcoinQt and/or Armory is out of sync. You're not seeing new blocks anymore and Armory can't display your balance since it doesn't know of the new blocks. Check the top block displayed by both Armory and BitcoinQt, this should give you a lead.

2) Your local node turned the transaction down. This can happen is you use an older version of BitcoinQt that expects higher fees. At this point your transaction never hit the network and your coins never moved.

The first thing you should do is check the balance of your send and receive addresses on a web service. This will tell you which one of the 2 situations you are experiencing.

You can always get your BTC out by simply recovering the private keys. If you are using Bitcoin and don't comprehend this feature, or you do not suspect Armory can do this, you didn't do your research. Armory is an advanced wallet, it requires a time investment in order to be used properly. Granted, there are some bugs, and by replicating edge cases, we get to isolate and fix them. However, I have personally never ran into any of what you are experiencing, and I have built and synchronized different versions of Armory dozens of times, on quite a few OS. The only reason these bugs persist is because out of currently 5 full time developers, none of us has ever ran into such a situation. Try and imagine the difficulty of this fix now.

If you did take the time to read the cold storage tutorial on our page, you would have a tested paper backup. This guarantees you have control of your coins.

Your coins are always accessible. You can extract all of your private keys through the backup center. You can always broadcast transactions. If Armory is acting up, just grab the hex output for the transaction and broadcast it with another client/webclient. Armory doesn't lock you away from your coins in any fashion, you are always in full control of your funds. MtGox held the private keys to the funds, this is how they robbed their users. With Armory, you hold the private keys, thus you are in control of your coins at all times. If Armory is buggy, you can and should simply use the privates keys and move your funds. The fail safe mechanisms in Armory will always provide you with a way to access your coins. Again, if you do not see how, you need to do your research.

As for a testing version, it's a matter of days now. We do not put out premature testing version with quick fixes because of several factors. One of them is that 0.90 came out with a brand new DB system, and as with any new feature, some insidious bugs came along. Fixing some of these requires overhauls to entire panels of the code, and such large changes take time and need to be tested in-house thouroughly before being released.

As we move forward in versions, newer features eventually stabilize. What you are experiencing is a feature in its very first version. Actually a lot of these issues came from the assumption that all the blocks saved in your local copy of the blockchain are valid. This assumption is wrong. It turns out it simply is cheaper for BitcoinQt to leave malformed versions of blocks locally as is rather than delete them and rearrange the data. As a result, while all block headers are present, some block data is malformed and thus invalid. Armory chokes on this when it performs full scans. Fixing this issue requires to eventually replace the missing blocks data, and implementing this goes way beyond the scope of identifying and ignoring corrupt data blocks.

Sounds like a ledger issue that we fixed recently. Quite a lot of fixes will be bundled with the next release. It's coming soon so hang in there.

If all goes well, 2 weeks from now

I'm not sure if the question is rhetorical or if you are truly asking how to do such a thing. Multiple factors are desirable precisely because the potential of a local secret security model (as in single factor protection) is exhausted too quickly.

The problem with your presentation is that you have yet to analyze it from a cryptographic standpoint. Once you get through that step you'll see that the most sensible solution for multi factor signature is multi-sig. Your scenario is simple enough that it could be implemented with ECDH too.

You didn't review your "password" model enough. Multiple factors retain their security because no single factor at any point in the process is in possession of the full secret. To encrypt a private key with several layers of encryptions has 2 major flaws:

1) The signature process can only be performed from the top layer down. If the first password was set on your mobile and the second one your PC, you have to start signing with the PC.

2) The biggest flaw: The last signer will have full disclosure of the secret.

Once you realize that, you'll see the existing solutions under another light.

I understand your intent however I don't think your model brings any new mechanics to what we currently have. Whether it is with your model, multisig or ECDH, the transactions has to go through all the relevant signers before it is valid and can be broadcasted.

If all the factors are compromised, the attacker can create a valid transaction and the coins will moved, regardless of the signing method.

Also, both multisig and ECDH behave like your system: they require some sort of non blockchain synchronization channel for all the factors to complete the valid transaction. In this cases, as it is with your model, every relevant signer is made aware of the transaction and has full disclosure of the transaction. The added security of multi factor signature scheme is that every signer can fully audit the transaction, which is what you pretend you do in essence, and is no different for the other models.

As for the crypto, I assume neither of the 2 signers in your model have the full private key. Ima also assume signatures are passed from one signer to the other without any signer being able to recreate the secret of the other one. And lastly, each signer has the full public key to be able to build the wallet's balance and initiate transactions. In the case of a 2-of-2 scheme, this sounds like ECDH to me.

Again, your alternate network to share partial signatures can be used just as well to share multisig or ECDH attempts. What you are truly proposing is a decentralized synchronization network, which in itself is interesting. Add support for other "out of blockchain" message types and you have something.

You're left with the last solution of trying to sync Armory with a brand new wallet. Your current situations strongly indicates that the outputs listed in your wallet somehow get Armory to hang. I have ran across one of these wallets recently. As far as getting your BTC out of your wallet, you can start Armory in offline mode and extract your private key list to import elsewhere.

The silent majority of our users run Armory without issues. You fall in the few very difficult cases that take Murphy's law to an extreme. Your first step in helping us debug this is to try and isolate the bug as much as possible. Reproducing it at will would be best.

As for the stability of Armory, the current release (0.90) came with an entirely new database system to keep track of the blockchain, obviously there are some very hard to find bugs that only cater to a tiny minority of users. These bugs are scarce and convoluted enough that it makes tracking them very complicated.

Hopefully the next release (coming soon) will have our latest batch of bug fixes incorporated. Best case scenario, it fixes your situation, worst case scenario, we will have narrowed down the possible candidates.

Few users do this, but if you were willing to send us a watching only copy of the wallet you can't get Armory to sync with, it could go a long way identifying the issue. You can email it to support@bitcoinarmory.com, make sure to mention this thread and ask directly for me. If you'd prefer encrypting the email, we can set something up.

We're putting out a new release soon that has fixes covering possible culprits. The log files are only helpful to an extent, they have few clues about why the BDM (Armory's C++ backend) is hanging. All of the bugs presented here are a symptom of this.

You are building the DB without a wallet loaded? This part still needs debugging. Put your wallet in there and try building the DB from scratch with the testing build

What does this model achieve that ECDH doesn't already do?

Can the BTC be spent from old wallet: Most likely yes. Last time I checked, BitcoinQt maintains full wallets, meaning if you have the public key to see certain funds, you also have the private key to spend them.

As for how that happened: I'm not privy of the core client mechanics, but 2 possibilities come to mind:

1) Your assumption is wrong, or
2) You encrypted your wallet in a state where BitcoinQt could not determine which private keys were in use. Again this is speculation on my part, but if BitcoinQt can't tell whether a private key is in use or not (let's say, while it is updating the blockchain), it is safe to expect the client would refrain from deleting any private key.

Is this with the testing build?

You haven't changed anything on your Bitcoin nor Armory install and it started failing? You should delete your Armory DB and see if it tries to rebuild. If that fails, try the testing build for the new version:


https://bitcointalk.org/index.php?topic=56424.msg5285727#msg5285727

If that fails too, send me your log file at support@bitcoinarmory.com. Mention this thread so I can recognize you. Use File -> Export Log File in Armory.

Without a fully sync'ed Armory you cannot spend your coins (Armory doesn't know which transaction outputs to use).

First start Qt alone and see if its properly sync'ed. Then make sure Armory is pointed to the blockchain folder.

Have you restored your wallet from a backup?

Have you tried the test builds for the new version?

https://bitcointalk.org/index.php?topic=56424.msg5285727#msg5285727

You dont need to change anything on the offline computer. You'll need a watching only copy of your wallet on the online computer, once you're done setting it up.

Your situation boils down to Armory version mismatch with the offline signing scheme. While upgrading Armory on your offline machine will provide you with new features (like fragmented backups), you can use version of Armory as old as 0.7 on your offline signer with the current version of Armory. In general, the version of Armory you have created your wallet with will be able to sign offline transactions emitted by newer versions of Armory.