The simplicity is over-stated. The concept is simple and can be represented in 5 lines of code. But the last thing I want is for a bug in my implementation to switch to the wrong conditional under some specific circumstances and send coins intended for my 1... address to an unspendable 3... address. These kinds of changes are dangerous when all the contextual code around it was written assuming one address type.
The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins. Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.
For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts.
The code in question is remarkably sensitive, and a stupid oversight in the code could lead to massive loss of coins. Maybe I'm overstating it... but I have some users with seriously a lot of money, and I'm sure they appreciate my paranoid diligence in things like this.
For reference, once I finally get this next version of Armory locked down, I'm going to work on this and make sure there's loads of tests for it in all the available contexts.
With all due respect, that your code was designed in such a way that is assumed one address type is something I would be a little embarrassed about myself - even in the early days it was easy to see how different types of addresses would simply have to be developed in the future if the scripting system was going to be of any use.
But in the meantime, I wouldn't be embarrassed to take however long it takes to do it right!
Regardless of how I wrote it, it's been in use for 2 years with only one address type. All testing and evaluation has been done with the single type that was in use. Anyone who has a piece of software as sensitive as Armory is not going to be recklessly upgrade a majorly sensitive operation because someone on the internet said it should be "an easy five lines of code."
The problem is not the complexity of the change, it's the time and attention span to make sure it was done right and thoroughly tested before people use it with real money. Anything else would be reckless, no matter how the original code was written.
Would it be easier to support sending to P2SH first? You just need to make sure the coin is sent to the right script, and don't have the responsibility to the redeemablity of the script.
I can imagine it is more risky to generate P2SH addresses. I usually double check the validity of an pay-to-keyhash address using bitaddress.org. I always put my tinfoil hat on when handling bitcoin. We need more independent implementations of P2SH to allow people doing such checking
The signing part may go wrong but not very risky. You may end up with an invalid transaction, but hardly sending the coin to limbo
