Topic: [edited] Merchant Return Unwanted Incoming TX from Green Addresses (Read 1922 times)

Yes I reread and understand this. This was my fundamental misunderstanding, and I will alter the OP and request to reflect this (or close it, and suggest that Armory has the basic requested functionality other than this not possible.)

EDIT: I'm going to kick etotheipi some coin, and hopefully BC-Casino will as well. We'll continue the implementation of the majority solution he described exists w/in Armory here: https://bitcointalksearch.org/topic/m.830472

Thanks for your help & understanding guys.

If you are concerned about tainted money, then the best thing you can do is send it right back to one of the addresses that sent it to you.  If you were helping someone launder money, returning the money to the original address is useless.  Maybe I missed something, but if you wanted to wash your hands of it, it seems like that gives you plenty of plausible deniability (and actual, justified deniability).

Btw, I can't tell if you are suggesting to somehow "refuse" the transaction.  You can't refuse Bitcoin transactions -- and this is not an option that can be built into a client.  It's just the way the network works.  If someone has your address, there's nothing you can do to stop them sending money to that address (for the same reason you don't have to be online to receive the Bitcoins).  As mentioned above, the best you can do is send it right back to one of the addresses that sent it to you.

There is no requirement that SSL use standard public CAs. There's no reason applications can't be configured to use CAs based on WoT.

Also, Haplo, you mention policing the entire bitcoin economy. *sigh* that's what this is not about. though I suppose as I wrote it up I realized people would think it's about policing tainted coins and refusing those.

I'm not sure I'm against people trying to do that. I'm pretty sure I'd be all for a major client that had a built-in coin tumbler to defeat such crap, too. (I'm a big fan of having LE have something to investigate, and I'm also a big fan of there being no way to find much, either)

kjj, you couldn't think of a reason to accept an incoming transaction ever? Someone offers you money that you know you shouldn't take on the street, what do you do? you always take money from strangers? (and by stranger, I don't mean anonymous or pseudonomous acquaintance) do think this is always safe, and always a good idea? what if someone started mailing you cash? I'm sure you'd keep the first one, but the second? third? or after a few might you wonder "wtf, why is this happening?" if it's A LOT of money, maybe you might get nervous. maybe not.

How about someone sends you the exact denomination of coin that was lost in a recent robbery, and you happen to know that number? Maybe you'd want to not receive that? Let's say that was worth 10x more in USD than it was in the recent actual robbery? 100x? Still want that hot potato?

I definitely think there are reasons to not accept a TX. I also think there are reasons to "refuse"/return a TX. I don't think anyone should ever reverse one. I think I am being clear about the difference (one happens via the network, one is a conscious action by the receiving client)

Internetwide we may refuse to accept many types of incoming network traffic, why should a client be forced to accept all incoming financial traffic?

- There may be a valid answer to the above question. If there is I will abandon this pursuit. If there is not, then a client should be free to refuse incoming connections by it's own choice of criteria.

The taint argument is strong.

LE wants stuff to investigate and seize.

Bitcoin wants to be able to be investigated but not seized.

IMO, the taint list argument is simply a point in favor of those who professionally launder money. "Dirty money" isn't new to bitcoin, and needs laundry today.

Laundering dollars means to obfuscate the identity of the transferring party or parties, and the source of the funds.

Since the parties are obfuscated in bitcoin, laundering bitcoin means to dilute the taint to the point of untraceability of the source of the funds.

I'm sure that there is some complaint that taint lists will result in the laundry services producing more blockchain bloat. Seems to me this is the original design - more or less, business as usual Cops gotta chase, crooks gotta launder, "banks" are in the middle and gotta help seize what they might get caught helping to launder. <<< Nothing new happening, and I don't see what's the deal. This is a huge reason (IMO) why bitcoin will be accepted and acceptable.

So, again, MUST a client accept all incoming transactions? Or SHOULD a client accept all incoming transactions?

Yeah that was the impression I got, too.

On the topic of SSL, public keys could simply be attached to NC addresses for .bit, but that's another topic for another time .

If you are trying to operate a completely underground, anonymous casino, you can use a self-signed certificate, and I'm sure the anonymous customer will understand.  Yes, there's MITM risks with self-signed certificates, but how much can you ask for?  If the casino is well-known, the public key of the self-signed certificate could be well known.  Alternatively, I've heard all sorts of stories about zero ID verification for getting CA-signed certificates -- send money and unverifiable identity, get a cert.  Sure it's not completely anonymous (money trail), but I bet you could find a CA that would do it.

In this case, it sounds like OP is happy to stay above ground, and getting a CA-signed SSL certificate is acceptable.  But maybe I inferred that incorrectly.  Either way, anyone operating a casino needs some kind of capability to initiate encrypted sessions....

Well, the general problem with using the usual SSL protocol is that it requires registering with a CA, ie the US Department of Internet Regulation. Using an off-the-grid SSL system through the blockchain avoids this.

However, I'm still not exactly sure what it is the OP is trying to accomplish with this. There may be a better solution for whatever specific issue you're trying to solve.

A casino could theoretically not "track" any of its customers.  It has a public webpage for getting casino-owned BTC addresses.  If a user wants to open an account, send money to that address -- done.  All future actions communicated with signed messages or SSL connection initiated with that first private key.  This is as anonymous as it gets.

In your case, you *want* more information for them to actually open an account, probably for legal and accountability reasons.  Well you can still do the above:  the user initiates the account by sending money to an address they pull off your webpage (with a large red, explicit warning about using one of their own addresses), but the account will not be activated (usable) until they send their name&address&DOB in a signature block.  If the info is not received within 10 days, you simply return the money to that same address.  In that case, it's entirely appropriate to return money to the same address (or hell, why not keep it?).

Of course some people will ignore the warnings and send it from their e-wallet anyway.  But that's their fault as long as you do your part with flashing red letters.  They can sort it out on their own with their ewallet provider (and they can prove to their ewallet provider that it was meant for them, since they can see the same coins they used to own coming right back to them)

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.

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

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!)

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.

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.

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

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.

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


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 some situations, the anonymous nature of the network prevented Person A from knowing who Person B is, and thus how to contact them.


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.


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?

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.

"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

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

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

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