[edited] Merchant Return Unwanted Incoming TX from Green Addresses

[etotheipi]

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)

[Haplo]

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.

[etotheipi]

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.

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....

[Haplo]

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....

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 .

[guruvan]

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?

[etotheipi]

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.

[guruvan]

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.

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://bitcointalk.org/index.php?topic=64155.msg830472#msg830472

Thanks for your help & understanding guys.