Your log file suggests you are failing every condition for geting online.  Though, perhaps failing the first condition is causing the others to fail, too. 

• Run with --skip-online-check or check the box in the settings to disable online checks
• For now, change the settings to run Bitcoin Core yourself (first checkbox in the settings dialog).  Close Armory, run Core (Bitcoin-Qt or bitcoind), when it's done synchronizing, start Armory
• Make sure you have set --satoshi-datadir to the directory containing "blocks" and "wallet.dat"... default is C:\Users\<username>\AppData\Roaming\Bitcoin
• Do you use a custom bitcoin.conf file?  That can screw up things, like limiting connections, changing ports.  If not, ignore this line.

Once that is working, and if you switch back to having Armory run Bitcoin Core, make sure the settings point to the base directory where it is installed... default is C:\Program Files\Bitcoin

You don't have to go online to sign transactions created by Armory, because Armory bundles in extra information needed for the offline computer to be able to securely review and sign the transaction.  Just a raw unsigned transaction is not enough, and Bitcoin Core doesn't have any way to provide that information (without modifying it).  You should create the unsigned transaction (TxDP) with Armory online, and then it can be signed with Armory without going online. 

That's the entire purpose of this thread:  https://bitcointalk.org/index.php?topic=181734.0.  Requesting to piggyback on the next hard fork to make it possible to supply all the secure threshold of data without having to bundle potentially MB of supporting transactions.  However, even if that was fixed, you still need the previous TxOut scripts in order to execute signing, which have to be retrieved from the blockchain -- again something else that Armory's TxDP structure bundles with it, but a raw unsigned tx from Bitcoin Core does not have.

There is very little infrastructure right now requiring interoperability.  Turning this into a BIP before we've even fully spec'd out the design space would simply slow down our ability to innovate these kinds of features.  I'm not against interoperability, but I tried it with BIP 10 when I was doing offline transactions, and everyone on the mailing list was kind of like "meh, none of us are doing offline transactions, you're on your own" (I don't remember exactly what was said, but it certainly didn't go anywhere -- I tried twice).  

The one exception to this is BitPay with Cosign.  I actually talked to RXC from BitPay and he basically said the same thing -- we're happy to do our own things at the moment get all the kinks worked out with our own users, and then create a BIP and both/all commit to it later.

Great question (and worth a bounty).  We should at least add a note about that in the interface.  As long as the relevant wallets are backed up in the regular way, the coins will be recoverable -- though it will be much easier if you backup the LOCKBOX block.  When we do the new wallets, we had planned to put that information into a separate file that could be backed up regularly, such as in Dropbox or similar service.  Rather, you will have the option to store a separate file to hold multisig info and tx/addr comments, with optional encryption (and the data will be stored in both the main wallet and the separate file).

However, this is minor because all the devices must have the lockbox definition, so if you lose it on one system, you can re-export-import it.  Or if it's multiple parties, anyone can give it to you to reimport.  As long as you have the same wallets as before (probably restored from paper), everything will be back to normal.

You can't create a promissory note if you don't know your balance/UTXO-set.  The note is a list of all the inputs and a change output that you will be contributing to the simulfunding transaction.  You must pull the input list (UTXOs) from the blockchain.

I would say skip simulfunding for now.  I think that simulfunding might be moved a bit further back in the interface until we get a synchronization server to assist with it.  It definitely works, but it's an awful lot of steps for each of the parties to execute and I'm not sure many users will have the patience for it.  I still want it to be available as-is, but I'll find a way to make it less prominent since I think most users will be using lockboxes for personal savings which doesn't require simulfunding -- it might just confuse them.

I have wanted to get someone in here to not only give us some guidance on the interface stuff, but perhaps create some Qt themes for us which would standardize the buttons, headlines, fonts, styles, etc.  I feel like I'm good at making interfaces extremely functional, but I'm all over the place in terms of presented information quantity and style. 

Feel free to make specific recommendations for any of the existing dialogs, and if it's good I'll implement it give you a bounty for it.


Make sure you disable "Let Armory run Bitcoin Core in the background" from File->Settings.  If it's still offline, it usually tells you why.

I have no illusions about anyone's grandmother executing this process.  Nor doing regular offline transactions.  But there is a large class of users for whom this is the first usable solution without having to understand tx structure, UTXOs, change outputs, etc.  


There is no central authority -- it's fully decentralized.  One person/device prepares the transaction, and whichever device adds/imports the last signature can broadcast it.  It is passed around as ASCII-armored blocks of text that can be emailed, and/or copied to USB to take to offline devices.  We would like to add a central server that would help users pass the data around, further improving the usability for those who want it... but the decentralized solution would always be available.

P.S. -- This is what people pass around to collect sigs (either inline in emails, or save to file):

It is precisely the "fancy GUI" which is what makes our implementation exciting.  Both cold storage and multisig have existed in low-level tools for quite some time, but most of them require an extremely high level of sophisitication by the user in order to run terminal/interpretter commands, manually collecting input transaction hashes, etc.   Just like with cold storage, creating an interface that hides all the unnecessary details and is usable by non-Bitcoin-experts is quite challenging.  Especially when you assume that any or all devices could be offline and some may be providing multiple signatures (Armory's multi-wallet interface helps make this a smooth experience).

Admittedly, I did not realize that gocoin had these multisig features available.  And if I had known, I would've played with it and provided feedback.  And I wouldn't have boasted so loudly about the "only generic, fully-decentralized interface for multi-signature transactions."  But I do think that what we just released provides a level of multi-sig usability unmatched by any other existing tools out there.  I'll have to make a demo video...

Either way, we really need testers!  And we're paying!  So anyone reading this, I just upped the bounty to 0.03 BTC per bug.  Rig a few instances to run at the same time (or just use multiple wallets), and find some bugs.

• Collect N public keys from the wallets of N parties or devices
• The organizer creates the M-of-N lockbox.  
• Anyone and everyone can send money to it.  You can distribute the P2SH address for receiving.
• To move the money, one person creates a spending transaction, sends it to each party/device for signing
• When it has M signatures, it can be broadcast.

For instance, you could have three laptops.  One at home (hot or cold), one in safe-deposit box A (cold SDB A) and one in safe-deposit box B (cold SDB B).  Set up each SDB laptop in the privacy room at the bank.  Take the watching only copies with you.  Use all three watch-only wallets to create a 2-of-3 lockbox.  Put money in it.  Now, in order for an attacker to take your money, they need to break into your house and one safe-deposit box to fetch signatures, or they need to get to both safe-deposit boxes.   When you want to move that money, you simply create the tx at home, sign it, take it to one of the SDB's, get a second signature.  Take it home and broadcast.

For a company, this is perfect.  Each director creates a wallet, merges public keys into, say, 3-of-5 lockbox.  Company funds are held in there.  Even if each/most of the director's used hot wallets, the security model is much stronger than most of the alternatives (because you've eliminated central points of failure).  You could even keep like 5% in a 2-of-5 wallet with the same keys.  If that disappears, you know that the 3-of-5 is close to being compromised and can regenerate a new 3-of-5 with different wallets and move the funds there.

Each step is independent.  Once the lockbox is created, anyone can create a proposed spend and distribute for signing

Reserved!

Armory Multi-Signature "Lockboxes" with Simulfunding
Testing Bounty - 0.03 BTC per bug (up to 1.5 BTC)  

---

Installers for version 0.92 (pre-release 0.91.99.11-beta):
  Armory 0.91.99.11-beta for Windows XP, Vista, 7, 8+ 32- and 64-bit
  Armory 0.91.99.11-beta for MacOSX 10.7+ 64bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 32bit
  Armory 0.91.99.11-beta for Ubuntu 12.04+ 64bit
  Armory 0.91.99.11-beta for RaspberryPi (armhf)


Offline Bundles:
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 32bit
  Armory 0.91.99.11-beta Offline Bundle for Ubuntu 12.04 64bit
  Armory 0.91.99.11-beta Offline Bundle for RaspbianPi (armhf)

Signed Hashes:
  Armory 0.91.99.11-beta: Signed hashes of all installers

---

Check out our Lockbox tutorials:   https://bitcoinarmory.com/using-lockboxes/

---

---

EDIT:  Thanks to SimonBelmond for sending us a link to this intro Armory multi-sig intro video:  http://vimeo.com/96983886
EDIT²:  We actually redesigned the interface/dashboard, so his video doesn't show what the latest version looks like, though the process is the same

---

I am pleased to announce that Armory has finally completed the design and initial testing of "multi-signature lockboxes" in Armory.  This is the first truly generic, fully-decentralized multi-signature interface available for any cryptocurrency.  Armory is innovating multi-sig the same way it innovated offline wallets -- taking a concept that is inherently complex, and making it about as simple as it can be.  It is still an advanced tool, but makes available features that haven't existed before!

Not only that, but the interface works seamlessly with hot or cold wallets, alike!   To understand how powerful this is, consider that you could independently setup 7 different laptops in five vaults around the world, and a signature is required from physically visiting each one, in order to move any of the money.   Yet you can receive money to it and track its balances safely from an online computer (just like a watching-only wallet, it only has public keys).    Or you can setup a 2-of-2 with hot Armory wallets and simply improve your security for the funds held by you and your spouse.  Or somewhere in between.  Really, the flexibility is astounding, and this solution is the "manual transmission" version that requires no third-party services.  It could be executed by any number of anonymous parties using nothing but email or pastebin.  

The interface enables the following operations (and all work as expected with offline/watch-only wallets):

• Create Lockbox:
  
  • Participants:  Provide Public Keys
  • Organizer: Collect Keys, Define Lockbox, Distribute
  • Participants: Import LOCKBOX definition
• Deposit into lockbox (regular):  
  
  • Use regular send-BTC interface
• Deposit (simulfunding, for certain contract types):
  
  • Participants: Create Promissory Notes
  • Organizer:  Merge Notes to Create Simulfunding Tx
  • Participants: Review and Sign Simulfunding Tx
• Spend:  
  
  • Organizer: Create Proposed Spend
  • Participants: Review and Sign
  • Organizer: Collect Signatures & Broadcast

This process uses no centralized servers or third-party services!  Instead, it provides you with chunks of ASCII-armored text which can be circulated to participants via email (inline) and/or saved to USB key to be taken to offline computers to retrieve signatures.  In the future, Armory Technologies, Inc, will be providing servers to facilitate the data exchanges and simplify the process, though we wanted to make sure that a [usable!] truly decentralized solution was available at all times  [Plus, all automated solutions will just build off the manual solution]

---

Caveats:

• This does not use BIP32 determinstic key chains!  A lockbox is like a single multi-sig address.  If you do not spend the full amount, change is sent back to the same lockbox.  With regular addresses, this is a privacy concern.  With lockboxes, the privacy issues are mostly unavoidable:  the vast majority of transactions on the network still single-sig, thus a multi-sig change address would be obvious even if a new multisig address was created to receive the change.  By the time this matters, Armory will have the BIP-32 linked wallet stuff in place.
• All message formats changed, including those used for regular offline transactions (which are a special case of multisig: 1-of-1).  If you upgrade your online system that creates offline transactions, you would have to update your offline computer to be able to read and sign these new transaction messages.

---

Other notes:
The best way to do testing is to run a couple instances of Armory at the same time.  All Armory instances on the same computer can share a single Bitcoin-Core instance, but must have separate --datadir=  settings.  Additionally, you will have to set a random --interport to avoid Armory detecting the already-open instance and aborting.  For instance, I do testing with 3 Armory instances, I run them as follows:

[/list]The datadir paths must exist before running the above!  If you corrupt your databases by accidentally running on the same datadir with different interports, use the --rebuild option to fix it.  It only takes a few minute on testnet.

---

And now for the pretty pictures:

Collect public keys from participants to create a lockbox:


Manage multiple lockboxes:



Collect signatures from all devices/parties:


Each user selects a source wallet and destination lockbox to create a promissory note.  Then the organizer merges them into a funding transaction to be signed by all funders


Once the promissory notes are collected, the parties have to sign.  This works identically to spend-from-lockbox (it's the same dialog).  Note that it only shows you the net value difference for each wallet, even though each "funder" is providing both inputs and change.  Armory figures it out.


As you can see, the final transaction has three different input wallets, and change back to those wallets as well.  

You call self.wallet.unlock() to unlock hte wallet to make the keys available for signing.  If you don't do this immediately before signing, it could relock itself before you attempt to sign (it's like 5 or 10 sec timeout).

I'm fairly certain that this can be done without unlocking the entire wallet (which checks the validity of each key).  In fact, I was pretty sure we had done this already, but perhaps not.  Or maybe it wasn't sent to armoryd (isn't that what you're using?)

The problem might be that the wallet relocks itself after 10 sec and you are not getting to the signing before then.  So you have re-unlock it by the time you get to the signing procedure (and make sure you only unlock the specific keys you need, again.

We need people to upgrade.  The upgrade itself is not responsible for any wallet issues -- any issues happened a while ago, it's upgrading that helps you identify that it happened.  I found your support ticket and will respond shortly.   We will get this fixed for you.

Well then just do what goatpig suggested:  make sure to generate a ton of addresses as described, then open the Backup Wallet -> Export Key List window.  They should even be numbered (as long as you select to show chain index).   Let me know if that doesn't satisfy your needs (besides the convenience factor)

The offline computer automatically keeps a lookahead of 100 addresses (you just don't see it).  Everytime you sign for a transaction, it's going to re-extend the key-pool to keep 100 addresses lookahead.  So if you have used 2 addresses, the offline computer has the first 102 addresses computed.  If you sign a tx for addr 51, it will computer the next 49 addresses so it is "tracking" the first 151 addresses.  As long as there are no gaps more than 100 addresses (I might have upped it recently to 1,000), then you will have no problems.  And if you do experience any issues, you can just use the expert interface to generate the extra addresses.

This sounds like your clock is about 12 hours off.  Make sure your clock and timezone are set correctly.

Simulfunding Now Implemented!

Updated the top post in the multisig thread:  we have been able to remove most of the limitations of the lockboxes, and now even have a clunky-but-usable simulfunding interface:

https://bitcointalk.org/index.php?topic=559776.0

The whole multisig section of the "devel" branch is extremely usable right now.  It now does P2SH for everything by default (but you can optionally use bare multisig), it handles signature merging, and now allows for multi-party simultaneous funding of lockboxes (and should be easy to expand for general-purpose, manual CoinJoin).

If you are already familiar with things like buyer-seller escrow, I'm hoping that the simulfunding stuff will be somewhat straighforward (despite there being lots of steps and moving things around) -- it's a complex process, but I think I've made it about as easy as possible for a totally decentralized app.  Besides cleaning up a bunch of things, I will work on documenting how to use the interface, and the things that can be done with it.

I think I will merge all the steps/options into a single "dashboard" which sorts everything by "organizer" and "participants".  It will show something like:

• Create Lockbox:
  
  • Organizer: Collect Keys
  • Participants:  Provide Pub Key
• Deposit (regular):  Send Funds
• Deposit (simulfund):
  
  • Organizer:  Merge Notes
  • Participants:  Create Promissory Note
  • Participants: Review and Sign
• Spend:   
  
  • Organizer: Create Proposed Spend
  • Participants: Review and Sign
  
  (Not sure what's up with the table formatting, but you should get the idea...)

And one more feature before the Amsterdam conference!  Simulfunding!  This one will probably need some documentation, though.  This is actually very similar to manual CoinJoin, but right now limited to sending to a single lockbox.  The idea is that certain contracts/escrow will require multiple people to fund a lockbox at the same time, and there was no clean way to do it before I implemented this.

• Create the Lockbox:  Pick an organizer.  All parties send a public key to the organizer.  He merges them into a lockbox, and sends the LOCKBOX block out to everyone to import into their lockbox manager
• Simulfunding:  All parties that are funding the lockbox will create a "promissory note".  This is a list of inputs, a change address, along with how much you are committing to funding and fee.  The organizer collects and merges all PROMISSORY blocks into a single transaction.  Its SIGCOLLECT block is passed around for signing, just like a regular lockbox-spend
• Spend from Lockbox:  One party creates the proposed spend from the lockbox, and sends the SIGCOLLET block to everyone for signing.  

Btw, on the latest devel branch, merging of signatures works, so you don't have to exactly circulate it anymore:  just send it out to everyone and you can "Import/Merge" them into the "Review & Sign" window -- it will recognize you loaded the same tx and merge the signatures into the one already loaded (before, you had to sign it and pass it to the next person to accumulate sigs)

There's still some quirks with simulfunding, but it does work!

P.S. -- And of course everything works with offline computers  All the messages/blocks that are passed between devices assume everything is offline.  You can do simulfunding between N offline devices, and spend from a lockbox between N offline devices.  I'm sure there are some services claiming to do multisig, but they don't have that kind of flexibility!

---

The simulfunding options menu.  All users create promissory notes.  One person merges them into a tx.  Then all funders sign it.


Each user selects a source wallet and destination lockbox to create a promissory note.  Then the organizer merges them into a funding transaction to be signed by all funders (right now no labels are passed through, so you only see how many participants there are and how much they are contributing, but not who is who...)


Once the promissory notes are collected, the parties have to sign.  This works identically to spend-from-lockbox (it's the same dialog).  Note that it only shows you the net value difference for each wallet, even though each "funder" is providing both inputs and change.  Armory figures it out.


As you can see, the final transaction has three different input wallets, and change back to those wallets as well.