<p>The protocol doesn't include a way to reject transactions, for a variety of reasons (the protocol doesn't know which output is real and which is change; blocks can't be changed after being mined; etc) but it is possible to do something similar.</p>

<ul>
<li><p>Accept payment, then return it</p>

<p>Pick one of the funding addresses at random, then send the coins back to that address.</p></li>
<li><p>Accept payment, then destroy it</p>

<p>Send the coins to an address that doesn't have a private key associated with it, like 1BitcoinEaterAddressDontSendf59kuE.</p></li>
</ul>

<p><strong>Implementations</strong></p>

<p>To my knowledge, no client implements an easy way to do either of these things. The best way would be use coin control to select the offending output, then make a transaction that returned/destroyed it.</p>

CC BY-SA 3.0
2015-04-17T10:28:14.940Z
Note that in general it's a very bad idea to send coins back to one of the sender addresses without contacting and agreeing with the sender first. You can't assume the sender (still) has control over that address, so the coins might go to the wrong person or be lost completely.
Jannes
CC BY-SA 3.0
2015-04-17T10:29:38.463Z
A third choice you have is to spend the coins as miner fees. That way you help secure the network a little instead of actually destroying the coins for eternity.
Jannes
CC BY-SA 3.0
2015-04-17T14:49:44.917Z
@Jannes That's technically true, but 95% of the time, people who have control over an address have control over it 24 hours later. There are exceptions (shared send) but they're exceptions, not the rule.
Nick ODell
CC BY-SA 3.0
2015-04-17T16:20:57.903Z
@NickODell Your 95% estimate seems dangerously high IMO.... if sent from an exchange or a web wallet, it's often the case that the payer does not control the private keys which sign the tx.
Christopher Gurnee
CC BY-SA 3.0
2015-04-17T20:45:35.447Z
@NickODell Apart from being an dangerous estimate, even if it's 1 in a million: it will end up destroying money. So you have to assume the worst. That means _only_ in the case where you actually _want_ to destroy money, could you use that method. But if you _want_ to actually destroy the money, the it's better to use option 2 (or 3).
Jannes
CC BY-SA 3.0
2015-04-17T22:30:08.153Z
@Jannes `if it's 1 in a million: it will end up destroying money` So? 1 in a million is a perfectly acceptable rate to lose money, especially when it's not yours. `But if you want to actually destroy the money, the it's better to use option 2 (or 3)` Sending the money to someone else is not really the same thing as destroying it. I mean, as long as we're sending the money to someone else, why not donate it to charity, instead of a random miner?
Nick ODell
CC BY-SA 3.0
2015-04-17T03:43:15.283Z
2015-04-17T03:43:15.283Z
Nick ODell
<p>Personally I would make a new wallet, then delete it. Mostly because I don't know how to spend it as a miner fee.</p>

CC BY-SA 3.0
2017-05-17T16:51:18.837Z
You seem to be getting the order of that wrong. When somebody sends you an unwanted payment, how does creating a new wallet provide any recourse?
Murch
CC BY-SA 4.0
2018-05-29T21:20:50.920Z
Would you like to learn how? https://bitcoin.stackexchange.com/questions/12451/are-bitcoin-transactions-permitted-to-have-no-outputs-i-e-all-inputs-become-tr/12452#12452 is a good deep dive. Or much simpler, just send some tiny amount to yourself and make the rest the fee. How to do this depends on what wallet client you're using.
Jacob Ford
CC BY-SA 3.0
2017-05-17T15:41:26.293Z
2017-05-17T15:41:26.293Z
Boop
<p>Say someone sends bitcoin to an address. It is later determined that those incoming funds are tainted and the recipient wants no association. What is their recourse?</p>

CC BY-SA 3.0
2015-04-17T16:24:44.043Z
You should be aware that the concept of "tainted" coins is at best very controversial and at worst damaging to the Bitcoin ecosystem. It implies that Bitcoin lacks [fungibility](https://en.wikipedia.org/wiki/Fungibility) which is a crucial component of a useful currency.
Christopher Gurnee
<transactions><taint-analysis>
Is it possible to reject a bitcoin payment?
Bradley Thomas
# Is it possible to reject a bitcoin payment?

(Asked by: username_0 on 2015-04-17)

Say someone sends bitcoin to an address. It is later determined that those incoming funds are tainted and the recipient wants no association. What is their recourse?

**Tags:** transactions, taint-analysis

> **Comments:**
> **username_1**: You should be aware that the concept of "tainted" coins is at best very controversial and at worst damaging to the Bitcoin ecosystem. It implies that Bitcoin lacks [fungibility](https://en.wikipedia.org/wiki/Fungibility) which is a crucial component of a useful currency.  

---

## 2 answers

### Answer by username_2 on 2015-04-17. Score: 7

The protocol doesn't include a way to reject transactions, for a variety of reasons (the protocol doesn't know which output is real and which is change; blocks can't be changed after being mined; etc) but it is possible to do something similar.

* Accept payment, then return it

  Pick one of the funding addresses at random, then send the coins back to that address.
* Accept payment, then destroy it

  Send the coins to an address that doesn't have a private key associated with it, like 1BitcoinEaterAddressDontSendf59kuE.

**Implementations**

To my knowledge, no client implements an easy way to do either of these things. The best way would be use coin control to select the offending output, then make a transaction that returned/destroyed it.

> **Comments:**
> **username_3**: Note that in general it's a very bad idea to send coins back to one of the sender addresses without contacting and agreeing with the sender first. You can't assume the sender (still) has control over that address, so the coins might go to the wrong person or be lost completely.  
> **username_3**: A third choice you have is to spend the coins as miner fees. That way you help secure the network a little instead of actually destroying the coins for eternity.  
> **username_2**: @username_3 That's technically true, but 95% of the time, people who have control over an address have control over it 24 hours later. There are exceptions (shared send) but they're exceptions, not the rule.  
> **username_1**: @username_2 Your 95% estimate seems dangerously high IMO.... if sent from an exchange or a web wallet, it's often the case that the payer does not control the private keys which sign the tx.  
> **username_3**: @username_2 Apart from being an dangerous estimate, even if it's 1 in a million: it will end up destroying money. So you have to assume the worst. That means _only_ in the case where you actually _want_ to destroy money, could you use that method. But if you _want_ to actually destroy the money, the it's better to use option 2 (or 3).  
> **username_2**: @username_3 `if it's 1 in a million: it will end up destroying money` So? 1 in a million is a perfectly acceptable rate to lose money, especially when it's not yours. `But if you want to actually destroy the money, the it's better to use option 2 (or 3)` Sending the money to someone else is not really the same thing as destroying it. I mean, as long as we're sending the money to someone else, why not donate it to charity, instead of a random miner?  

---

### Answer by username_4 on 2017-05-17. Score: -3

Personally I would make a new wallet, then delete it. Mostly because I don't know how to spend it as a miner fee.

> **Comments:**
> **username_5**: You seem to be getting the order of that wrong. When somebody sends you an unwanted payment, how does creating a new wallet provide any recourse?  
> **username_6**: Would you like to learn how? https://bitcoin.stackexchange.com/questions/12451/are-bitcoin-transactions-permitted-to-have-no-outputs-i-e-all-inputs-become-tr/12452#12452 is a good deep dive. Or much simpler, just send some tiny amount to yourself and make the rest the fee. How to do this depends on what wallet client you're using.  

---

