Topic: [edited] Merchant Return Unwanted Incoming TX from Green Addresses - page 2. (Read 1901 times)

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


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.

Yes, you should insist that customers give you a refund/cash-out address BEFORE you give them the funding address.

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.

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.

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.



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


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.

In my opinion, the problem is this:


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.

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://bitcointalksearch.org/topic/m.829101


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.