Feel free to file them to our support channel. I don't think any of us have ran into this, so this being helpful. We are currently in the bug hunt phase on dev so you are welcomed to help.

I'll tell you what I told this guy:

https://bitcointalk.org/index.php?topic=844674.msg9422968#msg9422968

Make a ticket, attach your full logs

https://bitcoinarmory.com/support

3) Ok I got your original question wrong. There are 2 stages in backing up a lockbox: You have to backup the lockbox itself (a short string saved in multisigs.txt in Armory's datadir), and each participant has to backup the set of private keys he used to create the lockbox.

The lockbox string is public data. If it is revealed to the public, you lose privacy but not coins. So you can back that up in quite a lot of ways, and each one of the involved parties should have that string as well, so this part is the least likely to be destroyed over time.

As for the private keys, if you can expect the buyer to protect his private keys properly, you should also expect he can lock funds in a lockbox without throwing his private keys out the door. Sure, he may be stupid, cycle his wallets at some point, get rid of all backups to the old ones without realizing he just lost his signatory power for his lockboxes. But then the 3rd party is expected use a dedicated wallet to provide private keys for lockbox creation (instead of picking a key from his own funded wallets), so he has less of a reason to just lose these keys.

Your proposal is fine. Short term escrow is another way to look at it. It reduces the amount of time the 3rd party is exposed to the funds so assuming he started honest but may be corrupted over time, it limits his window of action. The drawback is that you give the buyer a lot of protection. He can simply refuse to pay you after a few months of work for various reasons: he doesn't need your work anymore, he commissioned several individuals with the intent to only pay one, he can pressure you to do more for the same pay after you committed T amount of your time getting that far, etc...

The idea of using a multi-party technological solution for this type of contracts is to alleviate trust in the interested parties (buyer/seller), and put it in a commonly agreed upon 3rd party, whom at the same time doesn't retain enough power to just run with the funds. The solution you propose puts a lot of trust on the buyer. If you think the customer is king and you want them to feel treated that way, then your approach is well suited. If you want to retain some protection from potentially uncivilized customers, you should consider to at least lock litigation fees upfront.

1) Why would the buyer have protection? This is the same as giving the seller full control of the funds. The scheme you are thinking of is a 2-of-3 with one key to the seller, one to the buyer and one to an arbitrating 3rd party. The buyer and the seller have to cooperate for the funds to go anywhere. If they fail to find an understanding, then the 3rd party can come in and act as a judge, and has enough power to sign the coins off to the party he declares rightful in its demands.

2) Depends on the scheme again. M-of-N lockbox with M keys to any party is the same as giving full control of the funds to that party. If you want the 2 parties to have same power over the coins without the ability to wrong the other, each party has to have an amount K of keys, where K < M and 2*K >= M, and the 3rd party needs to have an amount of S of keys, where S < M and S+K >= M

3) The nature of the transaction doesn't change. Part of the due sum is paid in advance, the rest at delivery, kept in the 2-of-3 escrow. This concept doesn't mix well with 2-of-3 escrow however. The idea of paying a part of the price in advance is to mitigate the risk to the seller while keeping the risk to the buyer lower than if he just paid upfront.

2-of-3 escrow bypasses that entirely. With a 3rd party judge, buyer and seller have to agree for the funds to go anywhere. In case they disagree, the judge comes in. So the buyer puts full payment in escrow upfront, in the 2-of-3, at which point the seller starts on his work. The buyer then signs his half of the lockbox when the product is delivered, to the expected specs.

If the seller needs some money upfront to start on development, then that's part of another agreement, usually some sort of non refundable pre-order clause.

If you want to give even more protection to the buyer, you can use a simulfund to get the seller to put some funds in escrow at the same time the buyer puts in the full price of his purchase + extra, to cover litigation fees and pay for the 3rd party's time.

If the whole thing goes smooth, the 3rd party won't be involved beyond providing his public key once, so he could be entitled to small fee for his small burden. If there is a dispute between buyer and seller, the 3rd party has to kick in and review both sides' evidence. As he comes to a conclusion, he will then release the fees to the party he deems righteous, and pocket in the fees for his work from the guilty party.

This keeps the 3rd party motivated to review the case if needs be, and gets the seller involved more in the transaction: if he walks away, neglects this job, or takes something juicer on the way and doesn't try to release the buyer's funds asap now that he failed on his obligations, then it will cost him the litigation funds.

The flaw in this basic model is if the 3rd party colludes with one of the other parties to steal the funds, so you have to find a trustworthy individual to act as escrow. However this method is a lot better than just letting the buyer deal with the seller, and better than 1-of-1 escrow where the 3rd party holds all the funds and may run with them at any point in time, and usually commands a hefty fee whether the transaction is successful or not, in the case he is trustworthy, since you have to trust him a lot more, and he has a lot more work to do, regardless of the outcome.

If you walk out of that model, you'll most likely end up giving one of the parties too much power over the other one. I'm not saying it can't be done, but you're gonna have to get creative, and I don't thing multisig is the sole technological answer to that one.

If you want a dev to look at your issue, the first step would be to use our dedicated support channel and provide log files.

https://bitcoinarmory.com/support/

wallet.dat is Bitcoin Core's wallet data. If you installed Bitcoin Core only as an intermediary for Armory, there won't be any coins in wallet.dat

Armory's wallets use the .wallet extension and reside in Armory's datadir folder, which is different from Core's datadir. If you have backed up your wallets as the Armory tutorial's strongly suggest, you can delete these files safely.

Lastly, it is common practice for a software uninstaller to only remove the files that were added by the installer and revert the settings the installer set. This is why installation files and operation data are kept in separate paths. While Microsoft has lagged behind with this concept compared to Linux, it moved to this paradigm since Windows 5.x (2k/XP). So it is expected users are familiar with the concept, even on Windows.

Ignore Armory's torrent. Grab the bootstrap torrent yourself, and feed it to BitcoinQt manually. Before going on Armory, try to get Core to work.

If you want to run a node and/or broadcast transactions without revealing your IP, you should use TOR. If your concern is not be victim of theft, stop using online wallets and enforce proper cold storage pratices. TOR doesn't add to your coins security, that's cold storage.

Armory goes through Bitcoin Core (connected as localhost) to push its transactions. It reads its block data from local blkXXXXX.dat files. The TOR switch shuts down all other communications vector Armory uses (like calling back home to get version info), so as long as your Core instance is behind TOR and you use that switch, Armory won't try to access anything through the clearnet.

1) armoryd's checkWallet: This code was originally designed for the UI, to run in its own thread at startup, so there was no intent to make it fast or resource efficient. It performs tons of ECDSA calculations to cover extreme edge cases of corruption. The rational is that we don't care for the time it takes as long as it verifies the wallets under every angle. When this code was factored in armoryd, the first iteration is blocking. The idea is armoryd shouldn't be allowed to start with broken wallets. Subsequent calls are threaded (checkWallet is called periodically with armoryd).

We have a couple solutions on this front. The first is that the new wallets will be a lot easier to check (BIP32 n all), so it will reduce the overall cost of the consistency check. Also there are plans to move this entire code to the C++ end with the new wallets to give it a speed buff (the current code mostly runs in Python).

2) Unlocking wallets: we did a change a while ago to only unlock necessary private keys when signing a transaction. This is in the UI, and I'm not sure it was leverage with armoryd (I haven't worked much with armoryd). This comes with a caveat anyways: if you are trying to sign coins for which the private was never computed, it's going to unlock the entire wallet the first time around.

This will change drastically with the new wallets too: encryption/decryption will be on an address entry basis, no more decrypting whole wallets in any case.

Generally all this stuff will be packed along the new back end, which itself is a lot faster and scalable. We're planning to distribute an alpha release of the new stuff early next month, to let adventurous users start toying with it and hunting down bugs we missed. If it all goes well, our next official release should have both the new backend and new wallets, at which point I would invite you to migrate your old wallets to the new ones and enjoy the improved performance.

In the short term I recommend you make sure all your private keys are computed in your signing wallets (changing the wallet encryption passphrase will do that). You could disable the wallet check in armoryd, but I don't recommend doing that, and you'd have to modify armoryd source for that purpose. There is currently no built in option to skip the check in there.

bitcoind is crashing. Start BitcoinQt manually and see what it has to say for itself

Sounds like a setup snafu. You should make a ticket and attach your log files

1) Windows sets a swap partition by default which is equal in size to your RAM. If you have, say, 32GB of RAM and a 20GB Windows install, you are copying 32GB worth of useless swap data. On Linux, swap has a dedicate partition so this doesn't apply. In Windows however, it's just a hidden file, on your system disk by default. You can turn off swap or move the file around through the Control Panel. The minute details are off topic, just google it, it's a fairly simple procedure. Once you have reassigned your swapping file, reboot and you're done.

7) Again, swap isnt a partition on Windows, just a file, and you can assign one per drive letter (i.e. one per mounted partition). You could do the entire process without moving the swap file, and you'd end up with a copy of your system as is, on a different physical unit. Since you intent to move to a SSD, you should get rid of swapping on that drive if you have the RAM to afford it. That or move your swap to the HDD.

1) Start under Windows and move the swap partition out of the install drive.
2) If your system partition is bigger than your SSD, use Gparted to shrink it. Very straight forward and simple to use.
3) Plug in the SSD in your machine.
4) Get Clonezilla's iso and start it from a usb key. Do a partition to partition copy with default settings.
5) If it complains about GPT/MBR mismatch, follow the instructions it gives you (using gdisk) and pick GPT (delete the MBR, Win8 is a GPT OS
6) Make sure your mobo boots from the SSD.
7) Set the swap on the HDD (preferably, swap erodes SSDs unnecessarily)

HDD I/O speed won't be the bottleneck anymore in the upcoming version.

There isn't much to read about it, really. You are asking for a server instance of Armory (aka supernode, tracks all addresses in the blockchain) and a client instance (aka litenode, has no block data, and fetches wallet history from a server instance). That's the plan for the future iterations. Supernode is well on its way, as for litenode, we gonna make a robust supernode release before thinking about that one.

That would be the equivalent to a supernode/litenode paradigm. Supernode is on its way, litenode... well we have a road map but no one working on it yet.

Not sure the current version can handle it. I'd say there is a 80% chance it can. We'll purposefully test this in the upcoming version to make sure the code can handle both ordered and out of order/header only blk files.

You can push the signed transaction through any mean you can design, the issue isn't the pushing, it's creating the raw tx to sign. How are you supposed to do that without identifying your UTXOs (which is basically what online mode does) ?