<p>I don't think your threat model makes sense. If you "send me Bitcoins I can't claim", you've done the equivalent of nothing at all, except you've wasted some of your own Bitcoins in the process.</p>

<p>Currently, clients will only recognize Bitcoins as being sent to them if they can confirm they can claim them. Non-standard transactions (those with scripts other than the two well-understood forms) are ignored.</p>

CC BY-SA 3.0
2011-09-04T17:37:09.263Z
Your last sentence ("Non-standard transactions are ignored") answers my question. I appreciate the situation is highly hypothetical, but I couldn't find an explanation elsewhere. (In retrospect, a more useful way of phrasing the same thing - and applying Hanlon's Razor - would be "What happens if you are sent bitcoins in a transaction with a malformed script?")
Ash Moran
CC BY-SA 3.0
2011-09-04T17:52:33.717Z
However the client evolves, it will almost certainly always ignore a transaction it doesn't fully understand (other than to make sure it doesn't create Bitcoins!). Assuming it will be able to claim a transaction in the future just because it appears it can claim it now is a security risk. Maybe that's what you were trying to get at
David Schwartz
CC BY-SA 3.0
2011-09-04T17:02:58.913Z
2011-09-04T17:02:58.913Z
David Schwartz
<p>The wiki page on the transaction <a href="https://en.bitcoin.it/wiki/Script">script</a> says:</p>

<blockquote>
  <p>The party who originally sent the Bitcoins now being spent, dictates the script operations that will occur last in order to release them for use in another transaction</p>
</blockquote>

<p>How does a recipient know they can spend the bitcoins they received? Would it be possible for a malicious user to create a script that the recipient could not use to spend the bitcoins, without them being aware of it? (Possibly due to a client UI limitation?)</p>

<p>The situation I'm describing would probably be unusual, as it would involve the sender deliberately sacrificing (and destroying in the process) bitcoins purely to spite the another party. Even still, is it possible, and what measures (could) protect against it?</p>

<transactions><script><destroy-bitcoins>
How does a recipient know they can satisfy the transaction script to spend their bitcoins?
Ash Moran
# How does a recipient know they can satisfy the transaction script to spend their bitcoins?

(Asked by: username_0 on 2011-09-04)

The wiki page on the transaction [script](https://en.bitcoin.it/wiki/Script) says:

> The party who originally sent the Bitcoins now being spent, dictates the script operations that will occur last in order to release them for use in another transaction

How does a recipient know they can spend the bitcoins they received? Would it be possible for a malicious user to create a script that the recipient could not use to spend the bitcoins, without them being aware of it? (Possibly due to a client UI limitation?)

The situation I'm describing would probably be unusual, as it would involve the sender deliberately sacrificing (and destroying in the process) bitcoins purely to spite the another party. Even still, is it possible, and what measures (could) protect against it?

**Tags:** transactions, script, destroy-bitcoins


---

## 1 answers

### Answer by username_1 on 2011-09-04. Score: 7 | Accepted answer

I don't think your threat model makes sense. If you "send me Bitcoins I can't claim", you've done the equivalent of nothing at all, except you've wasted some of your own Bitcoins in the process.

Currently, clients will only recognize Bitcoins as being sent to them if they can confirm they can claim them. Non-standard transactions (those with scripts other than the two well-understood forms) are ignored.

> **Comments:**
> **username_0**: Your last sentence ("Non-standard transactions are ignored") answers my question. I appreciate the situation is highly hypothetical, but I couldn't find an explanation elsewhere. (In retrospect, a more useful way of phrasing the same thing - and applying Hanlon's Razor - would be "What happens if you are sent bitcoins in a transaction with a malformed script?")  
> **username_1**: However the client evolves, it will almost certainly always ignore a transaction it doesn't fully understand (other than to make sure it doesn't create Bitcoins!). Assuming it will be able to claim a transaction in the future just because it appears it can claim it now is a security risk. Maybe that's what you were trying to get at  

---

