We're talking about two different things here.

--I'm talking about a solution that can be employed by regular end-users, or small-scale business owners without being computer/linux-savvy.  I want to make it possible for people to access this level of security without being an expert in anything -- which includes avoiding anything with the command line, understanding hardware, or dealing with driver issues.  The audio solution is fantastic in this respect. 

--What you're talking about it a low-level interface for people who know what they're doing, to fill-in-the-blank.  In essence, implement the hooks to make it easy for other developers to dig in, and do it the way they want to do it.

What you're talking about is fantastic, and I actually plan to do that.  But I also want a fully-integrated solution that "works out of the box" on most systems -- both usable and secure.  If I integrate pieces of modem firmware into Armory and auto-detect the audio-link, a user only needs to plug in a cable and click an Armory button on each system.  Figuring out which /dev/* device and which protocol to use should not be part of that.  But it can be available for the hardcore users.

And I'm not entirely convinced that a "hosted solution" would not be willing to use something unique.  If Bitcoin becomes more widespread, and lots of business owners start trying to integrate Bitcoin into their web services, then why wouldn't there be some kind of customized solution for dealing with it?  As you said, it can be set up so they can use whatever device they want, but it wouldn't surprise me if something as crazy as this turned out to fit the bill, given that it is super-cheap, super-secure, and easy to setup without risk of doing it wrong.

After doing some more research, and receiving my 12 ft male-male audio cable, I was able to play and record data between two systems over the audio jacks with no problem.  There are probably some physical risks associated with this (as kjj suggested), but the quality of this potential solution is worth breaking some hardware to find out

Additionally, a coworker pointed out that modem firmware is designed for exactly this kind of communication:  noisy analog channel, with unknown quality and potential bit-rate.  The job of the modem software is to figure it out, and give you a nice clean interface for error-free file transfer.   And modems over phone had pretty good transfer rates, relative to the data sizes we need here.

So now I come to those who are possibly more familiar with this process:  how the heck do I hook these things up together?  GKermit seems to be ideal tool for communicating over the audio cable, but I don't know how to set it up so that it knows to send out the headphone jack and receiving through the mic jack.  I also just found an article about how to "retask" your mic port as a headphone port, which means it's theoretically possible for two-way communication over one cable... but probably not ideal to try that if I don't have to.

On the upside, gkermit is part of the Ubuntu repos, which means it should be straightforward to setup on Linux.  And it looks like binaries are available for Windows.  So who wants to help me figure out how to hook these pieces together?  Hooking up Kermit to audio ports in linux is fine for now... I expect the solution will be 90% portable to windows when it works in Linux (Kermit project brags about this).

I do recognize this doesn't work for the Raspberry Pi or Android devices which don't have a Mic jack.  Perhaps I'll have to come up with something else for that situation.  Perhaps the difference in security between USB keys and this audio solution is only "important" for those who are protecting enough money that buying a $50-$200 laptop just for offline key management is completely in the noise.

On a related note:  I could also see this solution used as a half-way for webservers.  For instance, your online webserver will maintain the audio connection with the "offline" wallet, which will actually be automatically allowed to sign some transactions.  However, it would be programmed to not sign any transactions over amount X, and not more than Y BTC per day.  Any such transactions will be queued for manual confirmation.  X and Y could be set in such a way that accommodates 95% of standard customer use-cases, but limits loss due to server compromise to less than 2% of the offline wallet, or something along those lines.

Just to pre-empt you, since you're asking about this now but the concepts have been discussed for 2 years now, start with what's already been discussed.  First, read through the examples on the Bitcoin Contracts page.  There's lot of examples mixing multi-sig with locktime, etc.  Also, for the specific buyer-seller escrow case, read through the thread that I started with Gavin to discuss exactly that -- create ways for two-party escrow without risk of coins being lost forever.

The buyer-seller problem is complicated because the situation is not symmetric, and dealing with the asymmetries requires some care to not give either party an advantage to being a dick.  I'd appreciate if you read and responded in those threads with your ideas, so that progress can continue ironing them out (but of course, read them first ).

It's possible to do this with a 2-of-2 transaction between buyer and seller.  Then both parties have to find an agreeable resolution before anyone gets the money.  Thus, neither party has any incentive to try scamming the other.  However, there's a risk that the coins are locked forever if there is no resolution, so I had started a thread to discuss how it might be done without a third-party.  It's complicated, but it works if you include "risk deposits."  I think most of the complexity can be hidden under-the-hood, though. 

In most cases, you should just use a third-party.  It's very cheap for third-parties to operate because they never really "handle" the money themselves.  But one of the beauties of Bitcoin is that you can have the bitcoin network itself act as your "trusted third-party" in cases where privacy is critical, or the two parties can't agree on a trustworthy third-party.

There's lots of different things that are possible, including time-locked transactions which are similar to what you asked about.  But the exact mechanics of how these things work in the bitcoin world can be kind of complicated, so I'll simply refer you googling (there's lots of information out there).


The most straightforward way is that the transactions will be encumbered with an [(A and B) or C] multisig requirement.  A is your primary computer, B is your smartphone, C is in a safety-deposit box that is very inconvenient, but accessible if you need it. 

Actually, the way Armory will do it will just be (A and B), and you will print off paper backups of both and keep those in your safety-deposit box.  You never want to have any coins floating without a secondary backup like that.

Simply put:  regular bitcoins only need to be signed by one address (private key) in order to be spent.  If coins are encumbered in a multi-signature transaction, it requires multiple signatures -- perhaps multiple, different, geographically separated computers.  Or multiple people.  Perhaps 2 out of 3 owners of a company will need to supply signatures to send the coins.

There's a very rich set of functionality that can be enabled through multi-sig.  Escrows, contracts, I can't even fathom all of them myself.  But the key is that there is no longer a single point of vulnerability for multi-signature-required coins.  An attacker will have to compromise multiple computers/people/nodes/servers in order to steal those coins.

EDIT: there's other features of multi-sig that might actually make it easier to spend [allow any one of multiple people to access them], or produce escrow such that defending against an attacker is not exactly the intent.  But I expect that the most common use-case will be for regular users to split their private keys between two devices (such as primary computer and smartphone), such that both devices need to be compromised for the attacker to get the coins (and the user will have to access both devices to use it).

Unfortunately, all this comes with a lot of extra complexity.  But it's up to application developers (like me), to try to make it useful for non-Bitcoin-experts.  And I look forward to digging into it after Armory becomes beta.

I've really only tested the internet/blockchain/satoshi detection and notifications.  Nothing else has been tested at all... it's possible that everything is broken!  I even made myself a checklist to make sure that I go through every dialog box, and every feature I can, because everything needs to be checked.  I don't recommend anyone use it at all until I've done that.

On that note, after spending hours chasing this seg-fault, I have identified what it is:  SWIG Bug 3403085.  It has to do with list & vector iteration when using the "-threads" option with SWIG (required by the upgrade).  Unfortunately, I use that kind of iteration all over the code base!  Since the bug isn't fixed (to my knowledge), I might just have to work around it, which may include going through all the python code and replacing all such list/vector iteration loops with a workaround. 

Alternatively, if someone is skillful enough to examine the CppBlockUtils_wrap.cxx produced by SWIG and figure out why the seg fault happens, that would be much better than working around it.  Extra credit if you can submit a patch to the SWIG project to fix it!  (I've tried digging into it, but it's all auto-generated code with lots of macros, so I can't even begin to figure out what's going on...)



What changes are those?  I thought I had already put them in and you had verified that it works...?  Or was it put in a different branch and never merged into master?

There's also alternative Bitcoin clients which have nice, pleasant user interfaces for doing this.  There's a list of popular ones on the main bitcoin.org website:

http://bitcoin.org/clients.html

Bitcoin-Qt is really not good for advanced functionality like this unless you want to use bitcoind on the command line.  That program is focused on stability and network security.  Other clients have really pioneered making other functionality, like importing private keys, easier for the average user.

All I can say is that what you have identified as potential vulnerabilities make sense, and I'm interested to dive further into mitigating this.  However, you could've simply emailed, PM'd or posted in my thread about this months ago, and I would've been happy to act on it.  Instead, you lurk in the shadows, popping your head out occasionally to insult people's intelligence for not knowing what you know, and the people who could be best aided by your experience will essentially ignore you, even if you have something important to say.

Please continue this conversation in the Armory thread, so we can stop derailing this thread.

Ack!  Threading branch is not ready!  Don't use it!

And of course after I posted yesterday, I ran into a seg fault with the address book.  Strange...  but I've been struggling to get that fixed (I'm not as close to a testing release as I thought...)

I meant for the previous post to be a teaser, not a notification.  I still have quite a bit of functionality left to sort out -- it's nothing compared to the multi-threading infrastructure, but still not enough to be usable yet.

P.S. -- But thanks, RE, for being so proactive about helping me test!  I really do need the help testing, it's just not quite ready yet

TEASER:

For those that don't actually care about the under-the-hood details, you can jump right to the screenshots.  The important part of the upcoming update is this:  
Armory opens immediately, runs everything in the background, and detects the various partial-functionality states and give information about what functionality is currently available and what will be available.  

Very close to done with this last upgrade to Armory before Beta.  I had to tear Armory apart, and rebuild much of the functionality in order to implement multi-threaded Blockchain management.  In case you're not familiar with what that means:  Armory used to be single-threaded -- every line of code I write will execute completely, and return whatever it's supposed to, then goes onto the next line.  The code is very simple, but the GUI will freeze if any heavy processing is performed.  This is why the splash screen seems so buggy, and why you can't touch Armory while it is sweeping a private key.

Multi-threaded means that the blockchain management happens in another thread (usually another CPU-core), and the GUI will keep operating smoothly.  This sounds great, but the complexity of code shoots way up.  No longer does each line of code execute immediately -- in many cases the line of code tells the blockchain manager to do something and then moves onto the next line before it's done (this is called "asynchronous programming").  This means that infrastructure had to be added to have a sane GUI that restricts access to various elements if the blockchain manager is busy, and I can't ever count on data being returned immediately when I ask for it.  I might have to remember that I asked for data, and check back with the blockchain manager later to see if it's available.  This why the upgrade took so long!












This is going to require a ton of testing before I can actually turn it into Beta.  I'm sure I broke a lot of things.  But my initial testing has been extremely positive so far.  Hopefully I'll have a testing release out by tomorrow!

P.S. -- I do not have any animated progress bars or anything like that, yet.  I wanted to get the functionality ironed out before focusing on aesthetics.  I will put that in while I wait for people to help test it!

You have clearly demonstrated that you are an asshole.  But that doesn't mean I won't accept advice from you.  Everyone has their own deficiencies, and clearly yours is a social deficiency, having no tact (or desire to try being tactful) in your expressions that everyone is dead wrong unless they are exactly right.  But I have thick skin, and can look past this.  Especially because you tend to have valuable input somewhere in your asshole ramblings.  After all, extreme technical competence usually comes with quirkier personalities.  I'll assume that's what your problem is...

(a): The Makefile is there because I put it there. I wanted to distribute everything with the executable, because it's all part of the same project.  Perhaps the organization of the files could be improved, but the only people looking for it will know what to do with it when they find it.  I'm not sure what your point was about this.

(b),(c): You have a good point that static linking is a security benefit, in addition to being easier to distribute.  I will look to see how much more stuff I can static-compile.

(d):  I do not agree about duck-typed languages being such a problem.  Sure, they leave room for poor/inexperienced programmers to make messier, more error-prone code.  But the quality of the final product is on the programmer, not the language they used.  Type-checking and error handling is superfluous throughout Armory code, and I am constantly testing everything I can.  I know you're probably going to be an asshole and point me to 10 different lines of code out of the 25,000 lines throughout Armory, where I didn't check variable types, or demonstrated some poor coding practice.  Well, go ahead.  I might even fix those lines.  But I won't apologize for having bugs in my, or doing something sub-optimal.  We can't all be good at everything.  

If you want to continue to discuss this, please do so on the Armory thread, or PM.  As I said, I'm happy to take reasonable advice from you.  However, your attitude is very likely to turn off others who otherwise would listen to your advice, but brush you off because you are so abrasive.

---

SgtSpike,

I'm actually talking to my buddy about the Android app.  He has much of it implemented, already.  As I said, we were waiting for multi-sig, but I had never considered the possibility of using an Android phone as an offline signing device.  I think this would be worth experimenting with, even with the default Android OS (there are no 100% solutions, yet, but I think this is about as close as you're going to get).   Looks like there's plenty of options for independent battery chargers, so you can keep your battery charged at home.  You'd also get the benefit of not having the battery stored with the device, so it would be a tad harder for an employee to boot your phone and pull the keys off.  They'd have to either steal the phone outright, or order a battery (which might end up being traceable).  In most cases, they'd probably just see a crappy Android phone and think it's unimportant. (Edit: this is another example of "attacks of opportunity" vs targeted attacks:  if an employee is digging through safe-deposit boxes looking for stuff to steal, they're going to go after all the jewelry that they can hide in their underwear until they leave work, not your crappy, battery-less Android phone -- the employee would have to know you and the value of that phone and actually target you, before it is stolen)

It's more to do with all the things the OS does when you insert a new device.  The weakest point of Armory offline security is USB auto-run viruses, which unfortunately exist for all OS.  It is, of course, orders of magnitude safer than keeping your wallet online, but there's still attack vectors that could be exploited in highly-targeted environments (like what you are talking about).  

I've been investigating ways to reduce mitigate this concern, but modern OS'es really hurt here, because they have so much code under-the-hood to auto-process new media for the convenience of the user.  It dramatically increases the attack surface.  For instance, someone figured out a vulnerability in the thumbnailer application used by the Ubuntu file browser -- they put a file on the USB key with a special icon ... and it was triggered automatically because a file browser pops up the moment you insert the key and it reads the icon file so it can display it.   I don't think it was a root-access kind of vulnerability, but it's still concerning.

I see two major benefits of offline wallets:
(1) Dramatically more difficult to compromise.
(2) Removes attacks of opportunity.  

On point (2): If some script kiddie from Russia stumbles onto your system for some reason, he can dig around and steal information.  If he finds a wallet file, he'll probably take it.  If you're using a watching-only wallet, he won't have anything to take, and will probably move onto other systems with lower-hanging fruit.  That would be an attack of opportunity: the script kiddie wasn't trying to break you, he was just looking for stuff to steal on any computer he can get access to.  A better example is a virus that uploads wallets it finds.  If you have no wallet, it does nothing.  So, if you're going to be compromised with an offline wallet, it's probably because you were targeted.

Unfortunately, this thread is about the fact that you expect to be a target.  In such a case, there is probably ways to compromise your online system and inject a malicious file that will auto-run when you insert the key into the offline system (or Android device).  Don't get me wrong:  this is a dramatically more-complicated attack to pull off.  But it's not impossible.  

However, most of the attack surface is due to auto-execute functionality.  Luckily, linux-based operating systems refuse to auto-execute any code on key insertion (without permission), but as referenced above, there is still an awful lot of code that runs when you insert a new device, and it's not unheard of that someone would figure out how to exploit that.

In many ways, though, there is extraordinary security through obscurity.  If the attacker does not know what kind of system is holding the full wallet, they have no way to know what vulnerabilities exist to exploit.  If you are using a custom-modified Android app with some drivers disabled, etc, then the attacker won't even know where to start.  They don't know whether they are trying to compromise a Windows machine, and Android 4.0 device, Raspberry Pi, etc.

From my perspective, this is really frustrating.  I only need to move a few kB of text back and forth between devices, but there seems to be no media for transferring data that doesn't have dozen of drivers/modules loaded to automatically handle data transfer. 

P.S. - I wouldn't freak out about offline wallets being totally insecure.  I'm just pointing out that this is not a 100% solution as-is, and it actually becomes a non-negligible concern when you expect to be targeted.

Actually, my buddy was helping me develop an Android app for two-factor authentication using Armory&Android phone, but I got side-tracked with other priorities.  This was on hold until I got multi-sig implemented in Armory.  But the app could theoretically be used to make your Android phone the entirety of the solution: it is the offline device instead of a laptop. 

I would much prefer a custom OS that has a bunch of stuff disabled, but my guess is it's no worse (as-is) than using a laptop + USB key.

I bet it's possible to make an Android app that can hold a wallet and sign Armory offline transactions.  That phone can stay in the safety-deposit box, and you can get an external battery that you can keep charged at home and take it with you when you go to the bank.  Throughout the day, you accumulate all the transactions you need to be signed on a micro SD card (which most Android phones use for supplemental storage).  You go to the bank, plug in the external battery, put in the SD card, boot the phone, verify&sign everything, the put it away and leave.  It can probably be done in less than 5 minutes.  

Also, isn't there some kind of insurance in the event the bank is robbed?  Are you responsible to cover your own losses when there's a bank robbery?  (the question of whether Bitcoin private keys would be covered by insurance is another story).

EDIT: of course there's still attack surface for anyone who knows you will be plugging the SD card into your phone and can figure out an Android exploit.  However, I bet it would be possible to use something like cyanogenmod to install a super-basic "OS" onto the phone such that it's only job is mount the card, show you all the transactions, and sign them.

On a related note: there may be something of value in the what car-rental places use:  the device will scan a QR code, and has a little printer on it which will print out "reciepts" that are actually QR codes with the signautres needed to complete the transaction.  Of course, any of these ideas will require some modification of existing devices, but such solutions should be developed anyway. (i.e. they aren't specific to your application, there's lot of use for it)

Oh, I just realized this is "project of the month".  I won't un-nominate myself, but I think it makes more sense for Armory to be nominated when it actually goes Beta... probably next month.

Can I nominate myself?  I'm disappointed to see Armory is left off the list, given that it is the only solution out there that provides cold storage in a user-friendly way.  And given the astounding number of compromises that could've been avoided by using cold storage, I think highlighting the fact that cold storage is available with an easy-to-use interface would be extremely valuable to the community.

And it's not like that's the only benefit of Armory.  One-time paper backups (because wallets are deterministic) is another dramatic improvement over Bitcoin-Qt, even though it's not unique to Armory.  And of course there is key importing and sweeping, message signing, GPU-resistant wallet encryption, URL-handling, and watching-only wallets.

While Armory is technically still "alpha", it's due to user interface and setup issues, not security or stability.  I know a few users that keep 1000+ BTC in Armory because it has demonstrated extreme reliability and so far no one has ever lost coins using it.  Not to mention, BitcoinOPX was using it for their financial trading platform (though, they are gone, now).  Armory should be "beta" within a couple weeks, even though most users already treat it as beta+.

Unfortunately, it can't be that simple.  In fact, even for the simple case you describe, it is dramatically more complex.  Why?  Allow me to explain how offline wallets work in Armory, and why data sizes will never be that small.

Satoshi decided not to include the input values of the inputs being spent in the transaction inputs or explicit declaration of the fee in the transaction data to be signed.  This sounds arbitrary, because that information is located in the blockchain, so the node only needs to go look it up the OutPoints in the blockchain to know.  Right?   Well, offline wallets can't do that.  And part of the value of Armory for offline transactions is that the offline computer doesn't need the blockchain.  You might say "okay, well just throw that information in with the tx to be signed so that the offline computer knows."  If only it were that simple...

gmaxwell expressed concern, rightly, that if your online computer is infected, the next transaction you make might have a devastatingly malicious modification:  it completes your transaction, but sends the rest of the balance of your wallet to transaction fee.  But you don't know this, because the attacker also modified the "supplementary" information in the transaction, so that the offline computer thinks it's only signing a 1.01 BTC input, with 0.5 to recip, 0.5 to change, and 0.01 to fee.  But the attacker actually put a 300 BTC input on the tx-to-be-signed, but put in the "supplemental" information that the input is only 1.01 BTC.  The result will be the offline computer showing you that you are sending 0.5 BTC to the recipient with 0.01 fee.  But when you send the transaction, it's actually 299 BTC fee.

THEREFORE:  my BIP 0010 "protocol" includes the entirety of each transaction which supplies inputs to the transaction-to-be-signed.  For each input in the tx-to-be-signed, Armory sees the OutPoint (txHash, txOutIndex), and verifies that it was passed a transaction with the same TxHash.  From that transaction, it can verify the value of the input and the final tx fee. 

• If the attacker changes the recipient or the amount sent to recipient -- the user should notice because they can see the list of recipients and values before they sign it
• If the attacker changes the value specified on the supplementary tx -- the suppl tx hash will no longer match the OutPoint on the tx-to-be-signed, verification will fail
• If the attacker changes the supplementary tx value and the OutPoint hash -- the transaction is no longer valid, because that OutPoint doesn't actually exist

In fact, that pretty much clears up every possible avenue for tricking the offline computer.  Now, every piece of important information is verifiable by the offline computer.  If there is manipulation, the either the tx won't be valid, or the user will notice when they look at the transaction details.

---

Okay, so that gets us back to the original question of "how much data do we have to transfer between online and offline computer?"  Unfortunately, the simplest case is not relevant to this discussion:  you have to design the protocol around the 99.9'th percentile case:  which is the case that someone has an offline donation address that they want to clear out.  Let's say they have received 40 donations.

So the transaction will have 40 inputs and 2 outputs. 

The bulk of the data is the supporting transactions which can be anything (transactions created by the donors).  Each one itself may have dozens of inputs, and the signatures are necessarily included!  Let's assume 30 "standard" supporting transactions, and the other ten have 10 inputs each.

• Tx-to-be-signed:  30 inputs (unsigned) of 48 bytes each, and two outputs of 40 bytes each = 1.5 kB 
• 30 standard supporting tx:  250 bytes each = 7.5 kB
• Ten larger tx:  180 bytes for each input (signed), so about 2 kB each = 20 kB

So the online computer needs to communicate 30 kB to the offline computer in this case.  And the offline computer needs to transfer back 30 signatures, which is, at best, 2 kB at a minimum.  The "maximum" a QR code can handle is 3 kB of binary, so that's 10 QR codes from online to offline.  1-2 QR codes the other way.

So the protocol should handle 30 kB without causing a lot of pain.  If the user has to wait a little bit because of a slow communication rate, that's okay because this case is abnormal and waiting 60s for the transfer isn't the end of the world.  But if they can't succeed because it's confusing and they can't figure out how many and which QR codes have been scanned, or which webcam they're supposed to be pointing at which device, and frustrated there are wires everywhere, etc.  Then there's a problem...

As you can tell, I'm very sensitive to the "convenience" of a given feature.  I think the biggest barrier to security is convenience -- users just don't use things that are inconvenient.  But I also don't want to sacrifice security, at all, no matter how much work it is for me.  Which is why there are so many recommendations here that are great, but don't quite the bill.  But I'm pretty sure a solution exists where the user can actually have both, in which case everyone wins

FYI:  someone asked about using a command-line script to sign your offline transactions, instead of using the Armory GUI/application.  This is a great idea.  So I went ahead and made a script for doing it.  I committed the script to the master branch, and showed what it looks like to run it on the main Armory thread:

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

I copied the script output at the bottom of this post, so you can view it without leaving this thread. 

Discussion:  I think if you are a bit linux-savvy, there's a bit of security improvement you can gain leveraging this script.  Instead of booting normally into your desktop manager, you can boot into runlevel 3, and then manually mount the USB key and execute this script to sign the transaction.  I bet runlevel 3, with no desktop manager would have dramatically less vulnerabilities associated with it.   I won't explain how to do this though:  if you don't know already, you will probably spend a lot of time with a semi-broken offline computer trying to figure out how to escape runlevel 3. 

---

@Jan:

I am saving anything to do with Android/smartphones until I get multi-sig implemented.  The plan was to simply implement two-factor auth using your phone, which holds one of the two wallets.  Then you create and sign the tx on your main system, and then perhaps QR codes to get the half-signed tx to your phone, then add second signature and broadcast from the phone. 

Although, admittedly, disabling the antenna on the phone may make Android very usable as an offline device.  The only problem I haven't fully evaluated yet is how to get the data to it:  I hate the idea of possibly needing to scan 25 different QR codes to get the data to the phone.  And dealing with webcam drivers on the primary system, etc.  But it's doable. 

Perhaps a "video" sequence repeating all 25 QR codes at 30 frames/sec, each frame will have something like "12 of 31" in it and the phone will keep watching and processing until it's got all the frames.  Probably a serious battery drain, but possible.

---

Here's example output of the CLI offline signing script:

OKAY!  A real script for signing offline transactions.  You could improve offline security by booting your offline system into runlevel 3, manually mounting your USB key, and then using this script to sign.  Without the desktop manager running, there's a whole lot less that could happen when you plug in that USB key...

I just committed the script to the master branch:  "extras/cli_sign_txdp.py".  Here's what the script looks like when you run it:


You can go look at the source code on github.  It's about 100 lines now, because I added the transaction verification (important!) and some more error checking.  This script would also be useful for those who want to learn more about python, and leveraging armoryengine.py for other purposes!

---

Learn python.  It's delightful.  I'm convinced it's the only reason I was able to put as much stable functionality into Armory as I have:  I can so easily handle every error and every corner case without thousands of lines of code.  Well, there are thousands of lines of code... but it's not all error-checking  But there are dozens of reasons why everything is easier in python, and you can focus on functionality instead of syntax (don't get me wrong, though, I still personally enjoy C++ and rigorous, strongly-typed languages, but I don't always want to deal with it).