In my opinion, the problem is this:
4) Casino only sends withdrawals to depositing address.
They should stop that. It is silly. Whatever convoluted workaround we come up with is going to be far worse than simply doing the right thing.
The right thing, by the way, is for the casino to request a return address (address A), then generate a new address (address B), and link them in a database so that earnings made with BTC deposited to address B will only be returned to address A.
Yes, you should insist that customers give you a refund/cash-out address BEFORE you give them the funding address.
Simply not reusing addresses is the correct solution. But, this isn't what users do.
I'm pretty sure this isn't possible in all cases. bitlotto's example seems it would be much more insecure with this requirement.
How about the hypothetical case in which someone sends unsolicited funds to an address - the recipient may wish to refuse to accept the incoming TX.
While it seems less likely, surely it will happen that a user decides to send money to Address A and clicks on Address B - user error. Wouldn't it be desirable for the recipient to be "honest" and return the money ( with a XXX TX_REFUSED_UNSOLICITED message or something?)
Here's another example of wanting to refuse an incoming TX (based on amount rather than originating address) Big bad gangsterman has my vanity bitcoin address & wants to stash 50K BTC in my wallet for later physical retrieval. I refuse the TX because it's too large - I'm not expecting any such payment. (paranoid, ridiculous, but I could see plenty reasons)
I'm also quite sure the correct solution in the above case is to not publish Green addresses, but that is what people do.
What about whitelisting addresses? In this case I'm only willing to accept TXes from pre-authorized known addresses. I can see why a financial institution would want to do this.
I understand the issue of introducing code (&bugs) into reference implementations. In general I'd be more inclined to implement a solution on top of the existing client rather than by modifying it directly. (or producing a merchant wallet)
If the solution MUST be "insist that customers give you a refund/cash-out address BEFORE you give them the funding address" I would have thought then that a bitcoin address MUST be a single use address to prevent such error.
If I gave the impression (wrong forum?) that I wished to change the reference client - I apologize. This was not my intent. If that's where it belongs, great, but doesn't seem necessary.
I also suspect that there may be some confusion of this type of refusal with refusal to accept TX from blacklist addresses because of suspected "taint" in their balances. This is not the reason I'd seek this. Unfortunately I'd guess it could be used for that purpose, too. Would Mt.Gox be better off if it could refuse incoming transactions that look "risky"?