[edited] Merchant Return Unwanted Incoming TX from Green Addresses

[guruvan]

There are currently 10BTC offered by BC-Casino for a working solution for this. I will add at least one more to prevent others from suffering the same fate as I had.

EDIT: We are looking for client side software solutions. Network changes are unnecessary.
Also, possible suggestions are
 - don't send from green addresses (don't ever use them!)
 - don't return to sending addresses

While those are no brainers, It seems that this will be an ongoing problem, and relying on users to not do stupid things is rarely an effective plan in my experience. Thus, we're looking at possible client side solutions.

Min Bounty: 11BTC

I'm no bitcoin code wizard, but I see this need, and have outlined as best a suggestion as I can from my current understanding of the code.

Background here (and bounty authorization):
https://bitcointalk.org/index.php?topic=64155.msg829101#msg829101


A client should have a way to return sent money with a message to indicate the reason for return.

Scenario 1: The specific use case:

1) Casino accepts BTC for customer deposit to customer's unique address.
2) Customer isn't warned about not depositing from online ewallet / exchange provider
3) Customer sends money from big bitcoin exchange service to Casino
4) Casino only sends withdrawals to depositing address.
5) All withdrawals from Casino initially received from the exchange provider's green address are       unrecoverable by the Customer

If I'm not mistaken, other users, like bitlotto could really use something to deal with this situation.

============== Rough problem/solution ========

1) Customer creates send transaction at ewallet/exchange/bank/etc
2) Customer or ewallet incorrectly choose Green Address, not unique to customer acct.
3) Transaction is sent from Green address
4) Transaction comes into Merchant bitcoin client
5) Merchant Bitcoin client matches sending address to blacklist
6) If matched,
  a)  Redeem
  b) create new transaction
       -OP_CHECKMULTISIG OP_CHECKMULTISIGVERIFY(?)
       -OP_DROP "550 INVALID_SENDER TX_REFUSED"
7) send from Merchant Green address to original sending Green address
Profit!



- is there any need to additionally verify the initial transaction?
- what does the initial sender need to help trace funds/TX back to the customer?
  - here it seems ideal to make recommendations to all Green address users to include OP_DROP msgs
     when transferring funds on behalf of customers (i.e. customer withdrawal_id_no - anonymous but
     internally trackable.

- are there additional opportunities for fraud that need to be closed if this is done?

Am I headed down the right path on this? Is this already an option and I missed it? Will 11BTC get this done? If so, for further points, maybe we might think about some recommended OP_DROP messages for easier processing - if that's happening, I missed it, feel free to redirect me.


Live and learn. There is no way to implement the desired feature without implementing the specifically undesired features. I misunderstood the clients actions, and after rereading, understand the issue at hand. Armory has all the features required to clean up most of the problem, but fundamentally this is not a very solvable problem.

[1714179613]

1714179613

[1714179613]

1714179613

[1714179613]

1714179613

[1714179613]

1714179613

[kjj]

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.

[guruvan]

They should stop that.  It is silly. 

Hmm. Saying "don't have the problem" isn't quite what I'm looking for here. I will edit the OP in case you think I am suggesting making any changes to the network. I am not.

Whatever convoluted workaround we come up with is going to be far worse than simply doing the right thing.

I'm not sure that this is the case at all. Please elaborate if you think this is the case.

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.

Anonymous services may not wish to do this. Avoiding suspicion of money laundering is one possible reason this method might be impossible. (This is the stated reason for the casino - it only gos back to where it came from = no money laundered here)

Also, regardless of the seemingly silly issue being directly discussed, can you not think of any reason ever that one person might wish to refuse an incoming transaction from another? I can think of several.

[bitlotto]

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.

Perhaps in most cases yes. I do agree that having address pairs is the way to go. BUT, for my own unique situation it allows a completely transparent and cheat-proof method that shows that the purchaser of the ticket did in fact receive the winnings. There is no way I can do anything sneaky. It allows all purchases to go to the same address without worrying who paid. It's clean and simple. But, I'm probably going to be a minority who needs to do this.

I don't know if there is a solution that would work nice. I have a suspicion that it might not be worth it. If that's the case I'm content INFORMING my users the proper way to play BitLotto.

[Haplo]

Anonymous services may not wish to do this. Avoiding suspicion of money laundering is one possible reason this method might be impossible. (This is the stated reason for the casino - it only gos back to where it came from = no money laundered here)

Also, regardless of the seemingly silly issue being directly discussed, can you not think of any reason ever that one person might wish to refuse an incoming transaction from another? I can think of several.

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.

Perhaps in most cases yes. I do agree that having address pairs is the way to go. BUT, for my own unique situation it allows a completely transparent and cheat-proof method that shows that the purchaser of the ticket did in fact receive the winnings. There is no way I can do anything sneaky. It allows all purchases to go to the same address without worrying who paid. It's clean and simple. But, I'm probably going to be a minority who needs to do this.

I don't know if there is a solution that would work nice. I have a suspicion that it might not be worth it. If that's the case I'm content INFORMING my users the proper way to play BitLotto.

I thought of a way to do "secure SSL" messaging on the blockchain to avoid direct connections between payment and public addresses. I'm not sure if that would solve your problem or not, but canceling or refusing a tx would require sending your cancelation to all miners, and that they accept your cancelation rather than mining the original tx into a block. It's probably not practical to do it that way for several reasons, and it would definitely require a protocol change.

If your goal is to prevent people from using your business as a laundry service between the exchange and the network at large, I'm really not sure if there's anything you can do besides keeping records to cover yourself, which I assume you're trying to avoid.

[Gavin Andresen]

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.

[kjj]

They should stop that.  It is silly.  

Hmm. Saying "don't have the problem" isn't quite what I'm looking for here. I will edit the OP in case you think I am suggesting making any changes to the network. I am not.

Sometimes, saying "Stop it!" is the best a guy can do.  No one wants to hear it, but sometimes they need to.

Whatever convoluted workaround we come up with is going to be far worse than simply doing the right thing.

I'm not sure that this is the case at all. Please elaborate if you think this is the case.

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.

Anonymous services may not wish to do this. Avoiding suspicion of money laundering is one possible reason this method might be impossible. (This is the stated reason for the casino - it only gos back to where it came from = no money laundered here)

Also, regardless of the seemingly silly issue being directly discussed, can you not think of any reason ever that one person might wish to refuse an incoming transaction from another? I can think of several.

Bitcoins don't come from addresses.  Bitcoins come from transactions.  And the notion that sending BTC back to the previous address that it had been sent to was the same as sending it back to the person or entity that sent it to you went out the window the first time two people ever shared a wallet, and with the invention of services with accounts (like all of the exchanges and banks) it was as dead as a doornail.

And no, I can't think of any good reason to ever reject an incoming transaction.

[Red Emerald]

They should stop that.  It is silly. 

Agreed.  What is wrong with asking for a withdrawal address when the user makes the account.

[ByteCoin]

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.

I think this is the wrong approach and will give you problems down the line even if you're dogmatic about sticking to your recommended "solution".

You're essentially asking the unwilling recipient of the funds to participate in laundering them.
Imagine this scenario:
1 ) We have a casino using the kjj/Gavinandresen scheme.
2 ) Hacker says he wishes to deposit bitcoins and supplies them with a return address A.
3 ) Casino generates funding address B and gives it to hacker.
4 ) Hacker steals large amount of bitcoins and sends them to B.
5 ) Casino gets a bit suspicious and to avoid liability as per kjj/Gavin's scheme sends them to agreed return address "A"
6 ) Police investigate theft and want to get their hands on the money (to return it). They catch the hacker but don't get the private key for A. Perhaps the hacker was supplied with A by the person paying him. Anyway, they find out somehow that the bitcoins were sent to the casino.
7 ) Police go to the casino and ask for the stolen bitcoins.
8 ) Casino says "Yes we did have them but we sent them to A".
9 ) Police accuse the casino of helping the hacker launder the coins.

You would also have to address the situation in which step 5 is "Before theft is discovered, Hacker rings up casino and asks for deposited funds to be returned due to 'urgent unforseen expenses'" - a perfectly legitimate sounding reason many legitimate clients would use when asking for funds back from their casino account.

If, instead of sending them to A, the casino hangs on to the funds until the police investigate then the casino can send the bitcoins to the police but then the public might accuse the hacker and the police of working together to steal the coins. Ok the police might eventually generate a transaction which can be seen to return the coins to the rightful owner but that may be years down the line after the case has gone through the courts. Until then, the casino is under suspicion. Also, while the casino has the coins (which might be a lot more than their company is worth) they'd better be sure their internal security is good enough to stop an employee getting their private keys!

The only way the casino can instantly avoid liability or suspicion from an unwanted payment is by returning the coins whence they came. Everyone can see that the situation has been returned to the status quo ante.

If you wish to firefight these cases, I have plenty more awkward situations to discuss. This should be a good thread.

ByteCoin

[guruvan]

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"?

[guruvan]

I thought of a way to do "secure SSL" messaging on the blockchain to avoid direct connections between payment and public addresses. I'm not sure if that would solve your problem or not, but canceling or refusing a tx would require sending your cancelation to all miners, and that they accept your cancelation rather than mining the original tx into a block. It's probably not practical to do it that way for several reasons, and it would definitely require a protocol change.

"Canceling the transaction" sounds like "reversing" a transaction.

This is not the intent. This would be the destruction of bitcoin, IMO.

The intent is that the Application Layer will check incoming TX, and either
A) just leave it unredeemed for the Customer's future recovery attempts via Sending entity

OR

B) redeem it, and return it with a message in the OP_DROP field.

I do not see why a protocol change would be necessary or desirable

[kjj]

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"?

Bitcoin just does not work that way.  When you spend coins, you are signing a transaction that irreversibly passes control of them to the recipient.  The recipient is not a participant in this.  There is nothing he can do to prevent you from doing it, except by preventing you from ever getting an address that corresponds to a key he owns.

We could add another layer that negotiates transactions before they happen, but as long as an address can be found, there is no possible way to prevent someone from sending to it.

In the case where you send coins to person A when you meant to send them to person B, the solution is to call up person A and explain the situation.

If you get an unsolicited transaction and decide to send them back to the last address that was known to have had control of them, you must do so with the understanding that you can not prevent people from using shared wallets and thus you might not be sending it back to the entity that sent it to you.

Also, the situation where the criminal sends money to you and then shows up in person to collect is pretty silly.  If he shows up with a gun, you should give him his coins back.  Duh.  You should probably give him all of your coins too, and whatever cash you have on you.  Oddly, this is exactly the same thing that you should do if a FedEx package full of cash shows up at your house.  If he sends the 50k coins from his MtGox account, and you return them, he is not going to be happy that you sent his money to a random MtGox user.

[guruvan]

Bitcoin just does not work that way.  When you spend coins, you are signing a transaction that irreversibly passes control of them to the recipient.  The recipient is not a participant in this.  There is nothing he can do to prevent you from doing it, except by preventing you from ever getting an address that corresponds to a key he owns.

I'm not sure where you got the idea that this is what I'm suggesting. I am not.

We could add another layer that negotiates transactions before they happen, but as long as an address can be found, there is no possible way to prevent someone from sending to it.

Yes, this is what we're looking for - now, how to prevent the local wallet from accepting the incoming TX, so it will remain unredeemed

In the case where you send coins to person A when you meant to send them to person B, the solution is to call up person A and explain the situation.

In some situations, the anonymous nature of the network prevented Person A from knowing who Person B is, and thus how to contact them.

If you get an unsolicited transaction and decide to send them back to the last address that was known to have had control of them, you must do so with the understanding that you can not prevent people from using shared wallets and thus you might not be sending it back to the entity that sent it to you.

Yes. This is very clearly the case, but we're looking for a way to assist in the recovery from the error. None of my suggestions prevent the initial problem, or completely corrects the situation. (IMO, using the OP_DROP message could very much help. I also thought that a OP_CHECKMULTISIG would be useful to reduce potential fraud.

It seems that the businesses who do things in this way understand the risks of sending to shared wallets, but those are outweighed by other risks. This would mitigate the risk, but not entirely.

Also, the situation where the criminal sends money to you and then shows up in person to collect is pretty silly.  If he shows up with a gun, you should give him his coins back.  Duh.  You should probably give him all of your coins too, and whatever cash you have on you.  Oddly, this is exactly the same thing that you should do if a FedEx package full of cash shows up at your house.  If he sends the 50k coins from his MtGox account, and you return them, he is not going to be happy that you sent his money to a random MtGox user.

It wasn't a great example, but I wanted to suggest there might be any number of reasons a user would want his client to simply refuse to acknowledge certain transactions. I also wanted to avoid having the bigbadman come at all by not having his money. Maybe a better example would be a government sting operation?

[etotheipi]

This sounds like the exact problem I was hoping to solve with Armory's signature blocks (and message signing just implemented in Satoshi 0.6.0).  The only requirement is that the user's first ever deposit is with an address they exclusively own.  All future deposits to their account can be through any means whatsoever.

Require the user to use one of their own addresses, X, for the very first deposit even if it's just 0.001 BTC.  After that, any interaction they have with the casino must be through signature blocks, signed by X.  ("I would like to cashout 12 BTC to the following address ... ")_signed_by_X.  This is a guarantee that the same person who originally funded the account is the person who is sending you the message -- and that the message can't be altered on the way.  After that first deposit, they can "refill" their account however they want (green addresses, friends, other addresses).  Only the first one matters.

You can make all interaction between customer and casino as anonymous as Bitcoin itself -- they would not even need a login/password/email/anything.  They only communicate through signature blocks on your webpage or email, and your software can easily check that the signature on the message matches X.  Right now it would require manually creating the sig blocks, but it could eventually be a capability somehow integrated with a client or browser, just for this purpose.  You could initiate SSL connections between casino and customer using public key X.  

Of course, if you don't want pure anonymity, you can require more information to open an account, but there's a ton of flexibility with this method.

[ByteCoin]

This sounds like the exact problem I was hoping to solve with Armory's  signature blocks (and message signing just implemented in Satoshi 0.6.0).  The only requirement is that the user's first ever deposit is with an address they exclusively own.  All future deposits to their account can be through any means whatsoever.

Ok. Deal with this scenario:
1) Innocent user funds casino account with tiny number of bitcoins and provides convincing ID.
2) Innocent user's laptop is stolen or otherwise hacked by Hacker - the point being that Hacker gains access to innocent user's private key and Innocent user loses access to the private key.
3) Hacker steals lots of bitcoins and sends them to Innocent user's casino funding address.
4) Hacker withdraws the coins from Innocent user's casino account.
5) Police find out that the stolen coins went to the casino.
6) Police ask the casino to tell them who the account belongs to.
7) Police have good reason to accuse Innocent user of theft. Innocent user can't prove he doesn't control the stolen coins and a jury has good reason to believe he can.

ByteCoin

[etotheipi]

This sounds like the exact problem I was hoping to solve with Armory's  signature blocks (and message signing just implemented in Satoshi 0.6.0).  The only requirement is that the user's first ever deposit is with an address they exclusively own.  All future deposits to their account can be through any means whatsoever.

Ok. Deal with this scenario:
1) Innocent user funds casino account with tiny number of bitcoins and provides convincing ID.
2) Innocent user's laptop is stolen or otherwise hacked by Hacker - the point being that Hacker gains access to innocent user's private key and Innocent user loses access to the private key.
3) Hacker steals lots of bitcoins and sends them to Innocent user's casino funding address.
4) Hacker withdraws the coins from Innocent user's casino account.
5) Police find out that the stolen coins went to the casino.
6) Police ask the casino to tell them who the account belongs to.
7) Police have good reason to accuse Innocent user of theft. Innocent user can't prove he doesn't control the stolen coins and a jury has good reason to believe he can.

ByteCoin

If someone steals your identity and everything you use to identify yourself, then how is it possible to avoid this?   That's *kind of* what passwords are for, except that they're still pretty much pointless, since the attacker can always request the forgotten password to your email that he just stole and then access your account. 

Either way, you can tie in additional security measures if you want:  the webpage for sending them signed messages could require a login.  Then the attacker needs your password and private key to do it.

[kjj]

This sounds like the exact problem I was hoping to solve with Armory's  signature blocks (and message signing just implemented in Satoshi 0.6.0).  The only requirement is that the user's first ever deposit is with an address they exclusively own.  All future deposits to their account can be through any means whatsoever.

Ok. Deal with this scenario:
1) Innocent user funds casino account with tiny number of bitcoins and provides convincing ID.
2) Innocent user's laptop is stolen or otherwise hacked by Hacker - the point being that Hacker gains access to innocent user's private key and Innocent user loses access to the private key.
3) Hacker steals lots of bitcoins and sends them to Innocent user's casino funding address.
4) Hacker withdraws the coins from Innocent user's casino account.
5) Police find out that the stolen coins went to the casino.
6) Police ask the casino to tell them who the account belongs to.
7) Police have good reason to accuse Innocent user of theft. Innocent user can't prove he doesn't control the stolen coins and a jury has good reason to believe he can.

ByteCoin

If the casino has a policy of only sending coins back to the address that it got them from, then the attacker can just send the coins to the stolen key, deposit them from there, withdraw them back to that key, and send them away.  Steps 5-7 go the same way as in your example.  Same thing would happen if a return address was embedded in the deposit using OP_DROP or whatever.

[guruvan]

This sounds like the exact problem I was hoping to solve with Armory's signature blocks (and message signing just implemented in Satoshi 0.6.0).  The only requirement is that the user's first ever deposit is with an address they exclusively own.  All future deposits to their account can be through any means whatsoever.

Require the user to use one of their own addresses, X, for the very first deposit even if it's just 0.001 BTC.  After that, any interaction they have with the casino must be through signature blocks, signed by X.  ("I would like to cashout 12 BTC to the following address ... ")_signed_by_X.  This is a guarantee that the same person who originally funded the account is the person who is sending you the message -- and that the message can't be altered on the way.  After that first deposit, they can "refill" their account however they want (green addresses, friends, other addresses).  Only the first one matters.

You can make all interaction between customer and casino as anonymous as Bitcoin itself -- they would not even need a login/password/email/anything.  They only communicate through signature blocks on your webpage or email, and your software can easily check that the signature on the message matches X.  Right now it would require manually creating the sig blocks, but it could eventually be a capability somehow integrated with a client or browser, just for this purpose.  You could initiate SSL connections between casino and customer using public key X.  

Of course, if you don't want pure anonymity, you can require more information to open an account, but there's a ton of flexibility with this method.

This has exceptional potential! (I somehow knew you'd have a significant chunk of solution for this!)

I'd still like to solve the first contact issue, and then solve the don't accept totally unsolicited funds issue, but this has a lot what I was looking for. (I hate to admit it's been a week or 10 days since I looked at Armory, and I've not had much time to dig all through it, it is the Awsum - I'll test the newest one tonight!)

[etotheipi]

This sounds like the exact problem I was hoping to solve with Armory's signature blocks (and message signing just implemented in Satoshi 0.6.0).  The only requirement is that the user's first ever deposit is with an address they exclusively own.  All future deposits to their account can be through any means whatsoever.

Require the user to use one of their own addresses, X, for the very first deposit even if it's just 0.001 BTC.  After that, any interaction they have with the casino must be through signature blocks, signed by X.  ("I would like to cashout 12 BTC to the following address ... ")_signed_by_X.  This is a guarantee that the same person who originally funded the account is the person who is sending you the message -- and that the message can't be altered on the way.  After that first deposit, they can "refill" their account however they want (green addresses, friends, other addresses).  Only the first one matters.

You can make all interaction between customer and casino as anonymous as Bitcoin itself -- they would not even need a login/password/email/anything.  They only communicate through signature blocks on your webpage or email, and your software can easily check that the signature on the message matches X.  Right now it would require manually creating the sig blocks, but it could eventually be a capability somehow integrated with a client or browser, just for this purpose.  You could initiate SSL connections between casino and customer using public key X.  

Of course, if you don't want pure anonymity, you can require more information to open an account, but there's a ton of flexibility with this method.

This has exceptional potential! (I somehow knew you'd have a significant chunk of solution for this!)

I'd still like to solve the first contact issue, and then solve the don't accept totally unsolicited funds issue, but this has a lot what I was looking for. (I hate to admit it's been a week or 10 days since I looked at Armory, and I've not had much time to dig all through it, it is the Awsum - I'll test the newest one tonight!)

Unfortunately, Armory's signatures are not compatible with Satoshi client's sign-message functionality.  But, I plan to get it matching as soon as I'm done with RAM-reduction and compressed public-key support.

Also, the Satoshi client also doesn't use any kind of signature blocks:  only "here's a chunk of seemingly-random data representing your signature, do whatever you want with it."  It doesn't even have a GUI for verifying them.  So I'm trying to convince the devs they should use some kind of signature block scheme which is user-friendly (relatively speaking) and easy to cut-and-paste into email or webpage.  In return I'll switch Armory to use their signing protocol

[Haplo]

We could add another layer that negotiates transactions before they happen, but as long as an address can be found, there is no possible way to prevent someone from sending to it.

Yes, this is what we're looking for - now, how to prevent the local wallet from accepting the incoming TX, so it will remain unredeemed

...

It wasn't a great example, but I wanted to suggest there might be any number of reasons a user would want his client to simply refuse to acknowledge certain transactions. I also wanted to avoid having the bigbadman come at all by not having his money. Maybe a better example would be a government sting operation?

Basically what you're asking is impossible. The only way to protect yourself from arbitrary government confiscation is either
A: Keep records and cough up like a good little peon if/when they come breaking down your door.
B: Keep your servers behind Tor and don't advertise any payment addresses publicly, nor make any public connection between you and your service.
C: Keep a blacklist of traceable money that came from an exchange so that you only accept pre-laundered money. Seems kind of stupid imo.

You could possibly use a reverse escrow, but you're still talking about single handedly policing the entire BTC economy for money that you will accept and money that you won't. The whole point of BTC is that your money is your personal responsibility, and if it's stolen, too bad. The correct solution economically is to maintain some form of insurance (like a bank does to cover defaults) and to minimize the side channels by which your accounts can be compromised.

If running a gambling operation happens to be illegal where you live, your local government may throw you in jail anyway whether or not you're declared guilty of laundering.

Personally I agree with Eto's solution, which was basically the inspiration for my idea (along with a suggestion by David Schwartz). My idea is basically to have a separate key type for encrypting messages, which can be sent as part of a tx. The message format would be standardized, with the only unencrypted parts being the first and last digits of the receipt address. To find out if a message is for you, you simply decrypt any messages with a first/last digit matching those you own and see if any of them come out with the correct formatting. Any return addresses or text replies are encrypted and only available to the recipient, whose own address is only slightly revealed.

That way all funding details can be worked out privately before an account is funded without exposing you to side channels where your information could be stolen or used for illicit purposes without your prior consent. Since they can provide you with a signature pubkey for withdrawing funds, it doesn't matter whether they provide the return account immediately or later or if they change it since you can verify that it's the same person who opened the account.

That way, if you're paranoid, you don't have to publish a public funding address anywhere, even for donations. You can require people to pm you to get an address to donate to first, and/or keep a separate address for accepting anonymous donations (which would also be possible with my system). I've never heard of a BTC police sting occurring (yet), but it's not impossible. It's possible to minimize your risk of that happening to you, but that's really not a subject that belongs in the development forum IMO.