Good point, and I'm not sure how to resolve that with existing protocol / infrastructure.  From a web wallet prospective, few off-the-cuff ideas:

1.) Require users to input their BIP32 public key each time they want to generate an address, but obviously that wouldn't go over well.

2.) Encrypt public key via AES256 with the user's wallet password, which isn't stored online.  Little inconvenient, because they need to enter their wallet password each time they want to generate an address, but would work decently.  If a hacker replaces the public key with something, then it's not going to decrypt properly unless they also know the user's wallet password.

3.) Have a separate server that holds checksum values of each BIP32 public master key, and bounce validation messages off it.  Pretty weak though, as if the hacker is in the server, they can easily see and bypass this one.

4.) Upon address generation, randomly check against a few previously created addresses to ensure they match the public key being used.  Plus maybe randomly call up a few previous transactions from the blockchain, and check the redeem script on them to ensure the public key matches up.  Hardly fool-proof, but it does make it a little harder as instead of just modifying the public key, they need to modify all addresses and transactions associated with the user account as well.

I don't know, will have to think about this more.

You can't, really.  If you a hacker manages to root the server, then any / all security measures you've built in to the software no longer matter.

So obviously, the first thing to do is make sure your server is locked down properly, fully updated, etc.  Then there's various other precautions you can take.  For example, it's it's PHP put the code in ionCube, look into using dnotify which will execute a script anytime a file is modified, hash the files and have them periodically scanned via crontab to see if they've been modified, add bait & kill switches to your system with hopes the hackers triggers one of those first, etc.

Again though, if they manage to root your server, and / all security precautions no longer matter.  That doesn't mean you shouldn't add them in though, because every little bit helps.

Just an idea.  What about slightly modifying the redeem script, allowing you to define whether the public key is a mandatory or optional signature?  BIP32 HD wallets are excellent for creating a hierarchy, such as if you have a company with multiple departments.  However, the one issue I'm starting to get is there is no limitations / restrictions.

For example, say I'm the boss, and decide to send some BTC to one of my department heads for their budget on a project.  BIP32 is great in the way that I still have full access to those funds, except the department head can do whatever he likes with those funds, with no restrictions, limitations or approval required.  For example, 3 of 5 multisig address:

1st Sig = User / Dept Head
2nd Sig = Boss
3rd Sig = 1 of 3 co-workers.

Right now, the above is impossible, because 2 of the co-workers could just sign the transaction without any approval from the boss.  What about slightly changing the redeem script so you can define the user & boss keys mandatory, and the 3 co-worker keys optional.  Would that be possible?

I believe the cap is at 5 signatures.  I've done 4 without any problem before.

Ok then John....   except this is 2014, not 2010.  We now have companies like Newegg, Overstock, Expedia, Dell, and so on all accepting bitcoin.

So if all those people are idiots, ummm...   yeah....

The install that's giving you an address with a "2" at the beginning is in testnet mode.

With multisig, testnet addresses begin with "2" (0xC4) and mainnet addresses begin with "3" (0x05).

Ummm, how about we don't, and say we did?

I could be wrong as I'm not a highly skilled hackers, but as far as I'm aware, you can't go public -> private.  It's impossible.  If someone gets your Master PRIVATE Key, then yes, they can unlock all funds from all addresses.  They can't do that if they only get your public key though.

Sure, you could if you wanted.  For example, maybe you wanted a 3 of 5 multisig.  So you could create 5 separate paper wallets, and combine the 5 public keys to generate yourself one multisig address.  You then send your funds over to that new multisig address.  Now in order to send any funds, you need to have 3 of the 5 paper wallets, as just one won't work anymore.

Then hide your 5 paper wallets in different locations.  If someone manages to get ahold of one or even two of your paper wallets, no big deal, because you need three of them to send any funds.

It's an HD wallet.  Here, this helps explain it decently:

http://bitcoinmagazine.com/8396/deterministic-wallets-advantages-flaw/

Basically, the public addresses are child keys of your master key.  Think of it as a family structure.  Parents, children, grand children, etc.  The parents can spend their kids money, but the kids can't spent their parents money.

Yes, beta versions of software will do that.  Report it to the mailing list and/or Github.

Provide more details though, if possible.

Ummm, depends.  Multisig in and of itself is 100% on the blockchain, so:

1 multisig address = X standard addresses + # of signatures required.

That's it.  When money is sent to that multisig address, in order to send it out, you need the necessary # of signatures, or else the blockchain will reject it.  And the only private keys that can sign the outgoing transaction are the "X standard addresses" the multisig address was created using.

For example, if you're using a multisig service that's a 2 of 2 solution (1 = you, 1 = the site), and the site disappears, then your funds will be stuck.  You need the private key from the site to send any funds.

Well, I guess time will tell.

Once companies like Expedia, Newegg, and Overstock begin accepting NxT, let me know, and I'll take a further look into it.  Until, I'll stick to being a Bitcoin fanatic.

Let the core devel team do their job -- maintaining the core protocol and the network.  That's more than enough responsibility on their shoulders as is.

Bitcoin now has a massive developer community behind it, so let them do the job of developing new services, solutions, security, and so on,  And from what I see, people are doing it at a rapid pace.  Many of the ideas coming out won't stick, but a few will.  Again, massive thefts on a large scale are now a thing of the past, and shouldn't happen again, assuming the necessary operations upgrade their systems appropriately.  Just that is a massive leap forward for bitcoin.

You have to clarify your question, as it depends on the wallet structure, and what private key you're giving.

Think of the wallet structure as a family -- you have grandparents, parents, kids, grand-kids, etc.  If you hand someone over a private key belonging to a kid, then they can easily generate all private keys belonging to their kids.  If you give someone a privat3e key belonging to a parent, they can't get the grandparents private keys, but they can get any of the kids or grand-kids private keys.

Hope that makes sense.

Huh?  Bitcoin is changing more rapidly than probably any industry I can think of.  Just in the past 6 months we've seen massive changes.  You know all those large-scale thefts / hacks we kept hearing about?  We don't hear about those too much anymore, right?  That's because the entire architecture of systems has changed, making it much, much more difficult to pull a massive theft off.

This will lead itself to people becoming more comfortable trusting bitcoin, which will lead to additional solutions and innovations, and round and round we go until soccer moms are paying their babysitter with bitcoin via their iPhone.  There's still loads of work to be done, but don't kid yourself, Bitcoin is humming along at a nice pace.

I believe you're going to see a massive shift over the next 12 - 18 months, and Bitcoin will begin to start gaining true mainstream momentum.

a) There's tons of applications and protocols already developed, or being developed as we speak to make things easier for the end-user.
b) Volatility isn't really there any more.  Sure it bounces around a bit, but there's none of this $200 -> $1000 -> $400 anymore, or at least hasn't been for a while, which is a good thing.
c) Security has massively increased.  Those massive thefts of previous years are a thing of the past, or at least should be.
d) People are naturally scared of the unknown, but now that Bitcoin has been out in the media for so long and continues to pop up, it's probably slowly embedding itself into people's subconcious as a "normal" part of society, so them adopting it will become more second nature for them.

And other reasons...  don't worry, mainstream adoption is on the way.  Above everything, Bitcoin has proven itself brilliantly as a wealth storage and transfer medium, which is all it was originally intended to be, and it's done so beautifully.  Just think, the Bitcoin mining network now contains all computing power necessary to run its own global transaction network, versus using SWIFT, ACH, IBAN, etc.

Don't get too excited just yet.  Remember, Thailand recently had a coup and is currently under military rule, so things may change once a civilian government is back in power.

Just an off-the-cuff reply, as I haven't given this much thought.

Maybe contact the developer(s) of BitID (or another OAuth type solution), and see if you can work together, and get something integrated?  Then instead of including the full shipping address & customer details in the blockchain each time, you only need that public key / identifier.  Keeps it under the 40 byte limit in 100% of the cases, plus helps on the security side of things, as full contact info isn't being added to the blockchain.

The reason you haven't seen either implemented in a widespread fashion is because both features are extremely insecure.  You're actually seeing a move within the bitcoin industry in the complete opposite direction.  There are no private keys at all stored online anymore, making these features impossible.