Do you also buy ghost insurance?  You do know addresses are public right?  

Anyone can send 1 satoshi to any address on the network (that has received a payment in the past), whenever they want and for whatever reason.

That is the point.  Custom bitcoin clients are NOT easy.  Unless you know what you are doing you probably should NOT be making a custom bitcoin client.  

As much money as MtGox has made over the last four years they could have hired someone who knew what they were doing but install hack together a client which is non compliant with the reference implementation in at least half a dozen areas (who knows how many others as the source code isn't public so we can only observe the fail from the outside).  This is the same MtGox which has no development server and just makes changes to production live so they decided getting the implementation of a mission critical component which involves the transfer of money, "close enough" was an acceptable standard.

A compliant client should not:
a) violate spam rules
b) pay less than the min mandatory fee (well a business client where users expect timely payments shouldn't)
c) send immature (less than 120 confirmations) newly generated coins
d) double spend its own "coins" (use outputs which were already spent in a prior tx)
e) use non-canonical signatures
f) rely only on tx-id as absolute proof on if a payment has been made or not

The "Gox Special" client did all of those, and who know what else.  It would be like building a jet airline by copying a photo of a jet you once saw, and being surprised when someone dies because "well it looks kinda like a jet, the engines are pointing the right way, and it has some wings and stuff".  Who possibly could imagine that slapping together some random parts so it looks like a jet wouldn't actually be a functional, safe jet?

Like cryptography, if you "roll your own" bitcoin node, you have to get it EXACTLY RIGHT.  Not kinda right, not mostly right, not hey it does sometimes push tx the network doesn't reject but absolutely right down to every single detail.   Most entities (companies and individuals) should not attempt that.  They should build off existing proven clients.

You don't have to wait an hour.   It is that some merchants require 6 confirmations for trivial amounts. The risk of being double spent on a tx with say 3 confirmations is essentially zero, yet maybe cling to the 6 confirm rule like it was passed down to Satoshi from God on a pair of clay tablets. If they require that for Bitcoin what makes you think it would be any different with another blockchain?

This would be like a store asking to for a DNA sample, retina scan, getting the receipt notarized, and the cashier taking a photo of you while you hold the credit card, your ID, and a note saying I approve this transaction, along with the current day's newspaper just to be safe every time you buy a candybar with a credit card.  Would you then say "credit cards are too hard to use" or would you say "this store is stupid I am going to 7-11"?

I think the larger issue is that building a "wallet" isn't that hard, but building a "node" actually is.  The problem is that the existing reference client combines these distinct entities into a single unified codebase.   bitcoind is a node, wallet server, and RPC client all combined into a single unified codebase.   

This makes extending the reference client in any sustainable way nearly impossible.  For example an enterprise solution might want to use a true relational database to store, query, and update payment statuses.  There is no good way to extend the current reference client to do that.  So you have two "choices", you can use bitcoind and RPC calls but throughput is very low, or you can build a new custom node implementation with all the risks that entails.  Neither is a particularly good solution.

What would be better (I have said this before but I don't think it got any traction) would be to refactor the existing client into separate projects.

Instead of a single project it would consist of multiple projects:
Bitcoin Core - A library which handle the low level functionality of a node.
Bitcoin Node - A reference implementation of the core library which only implements the functionality of a node (think bitcoind minus the rpc client & no wallet)
Bitcoin Wallet - An implementation of a wallet which communicates via a fast, low latency protocol with bitcoin node.

This would give developers options to extend "bitcoind" to custom applications. 

The safest and easiest option would be to design a custom wallet which meets the needs of an enterprise that communicates with the reference bitcoin Node.

More ambitious projects could push lower in the project stack.  Take Bitcoin Armory for example.  Currently it requires an install of "Bitcoin QT" which it then doesn't use for anything but a node implementation.  Initially that could be replaced with Bitcoin Node and likely over time Armory could just make calls directly to bitcoin core.

When developers ask questions about extending Bitcoin they could be steared away from making changes to bitcoin core library directly.

In case this isn't clear let me give you an example.  Take OpenSSL.  It is a library.  People import that library into a variety of projects.  Consumers of that library don't modify the library directly, they extend it.  Now imagine instead if OpenSSL wasn't a library but instead an entire webserver implementing openssl.  So the only option for bitcoin to use it would be either building an installing the entire uneeded server and then passing requests between bitcoin client and the openssl webserver or hacking around in the open ssl source code hoping you don't make an implementation bug.  Both "solutions" would suck.   That is kinda where bitcoin is right now. 

Ah yeah your right. Not sure what I was thinking.  Still I think any custom implementation is best served by emulating the bitcoind behavior as closely as possible.  I would recommend checking inputs and output but your solution is far better than what MtGox did.

That could be tricked by the attacker making a payment to the change address if the amount of the change is small relative to the amount of the payment.  There is nothing wrong with using tx id for record keeping just understand tx id can be changed.  It is very rare and it requires a deliberate act (tx hashes aren't just being randomly changed by the thousands as the propagate the network).

When a new block is received:

For all unconfirmed transactions:
If the block contains a tx with a matching hash, the tx is now confirmed. 
      Update internal records and set number of confirmations to one.

If the block contains a tx with the same inputs & outputs but has a different tx hash.
      Update internal records and set the tx hash to the new hash value and set number of confirmations to one.

For all confirmed transactions: 
If the number of recorded confirmations in internal records is less than the # your business requires (i.e. <6) check that the new block extends the chain containing the block containing the tx
     Update number of confirmations to be the difference in block height.

Technically it is still correct.  You can quickly and securely trade.  It is very secure because you can never withdraw the dollars or bitcoins.

How about not over reaching and attributing the lack of success to gready "holders"?  Plenty of companies have sold plenty of goods for Bitcoins.  The same goes to charities.   Take a look at Sean's Outpost.

The fact that you have raised exactly zero speaks more to your venture.  I never donated because the proposal was light on details and I doubted your ability to pull it off.  At this point your rant against evil greedy bitcoin holders ... well my interest is exactly 0.

No.  This has nothing to do with the block interval.

Ok then the standard is that tx hashes are mutable and clients need to account for that.  Glad you agree. 

MtGox will continue to generate bad press as long as they remain incompetent and then lie with inflammatory language in order to obfuscate that fact.  Either they will become competent, the exchange will get sold to people who are, or they will go out of business.  There is nothing for the developers to change at this point.  The protocol isn't going to be hard forked due to the incompetence of one exchange.  The reference client handles this fine.

If you make a payment with the reference client and the tx ends up in the blockchain but with a mutated tx hash what do you think the reference client does?
a) continue to report the tx as unconfirmed so users will think they need to make a second payment
OR
b) detect the modified version of the tx (when it scans blocks for new txs anyways) and modify the client's records so the tx shows the proper confirmations and the new modified tx hash?

Hint the answer is B

In other words the reference client handles this issue properly.  MtGox hacked together code does not (along with at least 4 other errors in processing txs).  MtGox also tries to spend immature newly mined coins.  That is another obviously wrong thing to do, No other client does that, The protocol doesn't allow that.  Should the protocol also be changed to allow the spending of immature coins so MtGox broken client will be not as broken?   This isn't a protocol issue, it is a client issue.  The client should handle this condition.  Most clients do, the "Gox Custom v0" ended up goxxing the exchange because it doesn't.

If the HTML 5 standard has a tag <x> which requires browsers to do X and they all do X except one browser lets say Internet Explorer does Y what is the solution?
a) update the standard and force all other compliant browsers to do Y when they encounter and <x>.
OR
b) demand the broken browser update their implementation so that when it encounters an <x> tag it does X not Y.

Please learn how Bitcoin works.

All txs have change (except in the edge case that the output exactly matches the inputs).  Sending the change back to the same address, or sending it to a new address doesn't have any effect on the size of the blockchain or UXTO.

Not really.

The first thing to point out is that if you are competent very few of your txs should ever end up dropped from the network.  MtGox had thousands of them.  They had not one problem but at least 4
a) double spending previously spent coins = invalid tx so nodes dropped it.
b) spending immature coins = invalid tx so nodes dropped it (although these would eventually get through after 120 blocks).
c) paying insufficient fees for relay (not following the fee rules in the reference client so nodes running on those rules would drop the tx instead of relaying them).
d) using non canonical signing two years after the issue was reported and modified in the reference client.

This changed what normally is an incredibly rare event (tx not propagating the network) to one that was widespread and affecting innocent users.  Had this giant cluster fuck of layered incompetency not happened the actions of any scammer would be more obvious.  If you only have a handful of users reporting they didn't get paid it is a little more obvious when 20% to 30% of all your withdraws across all users are failing.

A small exchange doesn't need an automated system to deal with tx mutability.  We don't. That is because 99.9%+ of the tx will never be mutated and there are no false positives.  There is nothing wrong with using the tx id as long as you don't rely on it as your first, last, and only method of accounting.   Mutability doesn't happen by accident.  

IF a user reports they didn't get paid and IF the tx hash is not in the blockchain then you MANUALLY flag the account and look for a tx which has the same inputs and outputs.

If you don't have that laundry list of problems above going on this should be a VERY VERY RARE EVENT and one that likely warrants manual attention anyways.  Sure a super duper automated system would be great and if you have the funds to build, extensively test, and deploy it go ahead but this isn't a routine occurrence for a properly running node.  So if your backend can process 99.9% of tx in an automated fashion and flags 1 in 1000 (and honestly probably more like 1 in 100,000) for manual review well guess what?  That is called doing business.  Most automated systems have some event which are logged for manual review.

The other thing to keep in mind is that most likely, the only reason it happened is because the user who reports he "didn't get paid", modified the tx intentionally so he can try to collect a second payment.  That means putting a man in the loop is a good idea even if you do have a super duper automated handle every edge case back end processor.  

While that would work, you don't even need to do that much.

You don't need unique out addresses because even if you pay two (or 10,000) users from the same address, Bitcoin doesn't work on the concept of addresses and balances.  Each user will have unique inputs for their tx.   That is how Bitcoin works, it is how it has always worked, and it is how it always will work. 

You simply record the raw tx.  Thats it.  Nothing special.  Technically you don't even need to do that because the client/wallet already does it but for customer support it likely is easier to have that information available outside of the wallet.

Now for 99.999% of your transactions (if you are competent and not doing things like double spending your own coins, paying insufficient fees on masive spammy txs, and spending immature coins) the tx will go through fine.

For the 0.001% of transaction where user reports non-payment you:
a) check the blockchain to see if the tx exists by tx hash
b) check the blockchain to see if the tx exists by looking up the unique set of inputs and outputs which make the tx.

Why do a if b will find all txs?  Simple it is faster and tx don't accidentally mutate themselves so it gives you good information on which customers might be trying to rob you.  You don't have enough "evidence" to have them arrested, maybe not enough to even ban them, but you certainly have enough to flag their account so it warns other customer support reps to be extra vigilant.

This.  Other exchanges, merchants, and service providers have dealt with this for years.  MtGox is not only incompetent but they are also adding a fud fueled headline to cover their asses ("Bitcoin protocol is broken, we can't safely transfer coins until it is fixed").  We all know how much fact checking the media does so I expect to see the headline about Bitcoin broken and unsafe any hour now.

It is important to point out that transactions don't accidentally get mutated. and there are no false positives.   If you make a tx (tx hash A) and that tx (tx hash A) ends up in the blockchain then the user got paid.  Period.  If you are competent that should be 99.99999% of your transactions right there.  Thus the mutated tx are a edge case and one which can be handled manually if you want.

TO AVOID LOSING MONEY TO SCAMMERS (hint hint MtGox before you lose more of your user's funds):
If a user reports they did not receive the withdraw there are three possibilities.

First you first check the blockchain for the tx hash.  If you find it then you are right and user is wrong.  You have paid them.

Second if the tx hash is not in the blockchain, you check to see if the same tx (same inputs, same outputs) is in the blockchain.  If you find one, then the user is wrong.  You paid them and "someone" (likely the scammer user you are talking to right now) mutated the transaction to hide the fact from you and is trying to get double paid. So you flag or ban the user whatever your internal policy but you don't pay them again.

If the payment if not found by either method in the blockchain then you (MtGox) likely fucked up again.  Check to see if you:
a) are spending immature outputs
b) are double spending prior spent outputs
c) are paying insufficient fees (yup charging users 10x the min fee then failing to pay even the min fee for your tx)
d) are producing bloated spammy tx which violate the Bitcoin protocol spam rules

Sorry.  Talk to your local friendly regulators.

IF the ATM accepted dollars and converted them to BTC then FinCEN (in their awkward let cram this square peg into the round hole which is the "closest" fit mentality) says its operator is a money transmitter.

So if there are no full service Bitcoin ATMs in the US there will be no "savings account" Bitcoin ATMs in the US either and if you could deploy Bitcoin savings account ATMs it would make a lot more business sense to just deploy much more capable and popular full service ones.

What distinction do you think that makes (other than likely the worst marketable ATM in the history of mankind)?

FinCEN says the act of exchanging BTC for USD or the reverse is what makes one a MSB.  Your proposed restricitons would only make the ATM very unpopular.   

BTW "traditional ATMs" comply with money transmitter laws.   You can't get cash out of an ATM in the US without having given someone somewhere all your personal info (name, address, ssn, dob, photo id, etc).  The ATM operator may not have that information but they are working with your card issuer who does.  If the card issuer doesn't follow the rules the ATM network won't accept their cards.

Why do you assume 1 address = 1 person.

MtGox cold storage address likely holds the coins for tens of thousands of users but in your "math" it is all owned by one person.  The same would apply to every major exchange, eWallet, and bitcoin related business.

Likewise under similar math you would say 80% (or some asinine number) of all the dollars in the world are personally owned by four people named Chase, BofA, Wells Fargo, and Citibank.

Don't run unknown exes uploaded by anonymous people ... unless of course you are suffering from the burden of a wallet which is too heavy as that problem will be quickly rectified.