<p>What you're describing is a contradiction of terms. If a sum of money is deposited into an address, that means that <em>only</em> that address's private key can spend the money.</p>

<p>Maybe you could craft a non-standard transaction and tell people it's giving address B's owner permission to spend it, but if people look closely enough at the transaction, they'll be able to tell that it's really address C (and not B)'s owner that can spend it. There's no way around this: the transaction output is public, as is the implementation of how it works.</p>

<p>So if the question is: can you fool software X with a non-standard transaction? Perhaps, it would depend on finding a bug (or other less-than-ideal situation) in the software in question. (for example, if you craft a transaction that can be spent by address B or C, maybe the wallet owning B will say it has the balance, and if he doesn't transfer it again before you do, then you can "steal back" the money that way) However, I'd treat any non-standard transactions as highly suspect.</p>

CC BY-SA 3.0
2014-05-15T15:21:59.733Z
Agreed (see edit). However, the question stands: how do clients react to non-standard transactions? How does f.e. the reference client go from "a transaction's output script" to "hey, you just received 42 BTC"? Could it be tricked by something like this?
Massimo
CC BY-SA 3.0
2014-05-15T15:07:01.030Z
2014-05-15T15:07:01.030Z
Tim S.
<p>No, you won't fool the standard client with this. If it does not understand the script completely (i.e. it is a nonstandard script), it does not try to <em>parse it partially</em> or whatnot. The procedure is simple: if the client can't understand the script completely, it is simply ignored. Period.</p>

CC BY-SA 3.0
2014-05-18T19:18:16.707Z
Any reference for this? What types of transactions are considered "standard"? Who decides if a transaction is a standard one? How can you even get a nonstandard transaction mined into the blockchain if the reference software simply ignores it?
Massimo
CC BY-SA 3.0
2014-05-19T10:06:32.903Z
There's a protocol and then there's the reference implementation and other implementations as well. While the protocol is stable, implementations are not and some features are adopted more quickly in some clients. The same goes with the policy of relying trx - different implementations have slightly different rules when it comes to decisions about relying trx. What is a "standard" script depends on the client, but generally it is a script that requires valid public key and a signature. More info [here](http://bitcoin.stackexchange.com/questions/18638/not-relaying-non-standard-transactions).
knaperek
CC BY-SA 3.0
2014-07-17T21:36:55.710Z
see https://github.com/bitcoin/bitcoin/blob/6513a9f7033737458735305a08606280d6d0d33c/src/script.cpp#L1203 (function solver) - even if you don't know programming, those four lines should be clear enough, and they contain the four standard transactions. The future bitcoind versions will allow for any other txs to be standard ( https://bitcoin.stackexchange.com/questions/28181/what-new-transactions-are-possible-with-15-operations ), but still - the clients/wallets look at the whole tx to compute the bitcoin address.
kolinko
CC BY-SA 3.0
2014-05-17T11:43:36.337Z
2014-05-17T11:43:36.337Z
knaperek
<p>A standard Bitcoin transaction deposits coins into an address and then, using Bitcoin's scripting language, states that whoever wants to spend this output must be in possess of the private key corresponding to that address.</p>

<p>However, it's possible to deviate from this base template to create more complex transactions, where other conditions must be met in order to spend the transaction output.</p>

<p>Is it possible to create a transaction where a sum is deposited into an address, but only the owner of <em>another</em> private key is allowed to spend it? I'm not a Bitcoin scripting expert, but this looks at least possible.</p>

<p>In this case, can such a crafted transaction be used to mount a double-spending attack, where address A sends sum X to address B, but after the transaction is completed address A retains ownership of the sum and can send it elsewhere, while address B can actually do nothing about it even if the sum is credited to its balance?</p>

<p>How would a standard wallet treat such a transaction? Would it even recognize there's something strange going on, or would it blindly display that X BTC entered address B, regardless of the transaction script?</p>

<hr>

<h2>Edit:</h2>

<p>Sorry, I was misled by how sites such as <a href="http://blockchain.info" rel="nofollow">blockchain.info</a> display transactions: a transaction doesn't actually contain any "output address", it only contains outputs which state the conditions necessary to spend them; the "output address" is computed by checking which address's signature is requested by the output script; thus it's impossible to "send money to address B" without actually placing address B in the output script.</p>

<p>However, the question somewhat remains: could a transaction be crafted to fool a wallet into telling its user "I received X BTC" while someone else can actually claim the sum using another private key?</p>

CC BY-SA 3.0
2014-05-15T12:40:13.467Z
Please note that the transaction as I described it is crafted so that *B has no right at all* to spend the sum; a more complex transaction could instead allow both B and A to spend it.
Massimo
CC BY-SA 3.0
2014-05-15T15:23:59.063Z
Ok, that wouldn't work (see edit). But maybe something else would...
Massimo
<transactions><script><doublespend><signature>
Can Bitcoin scripting be used for double spending attacks?
Massimo
# Can Bitcoin scripting be used for double spending attacks?

(Asked by: username_0 on 2014-05-15)

A standard Bitcoin transaction deposits coins into an address and then, using Bitcoin's scripting language, states that whoever wants to spend this output must be in possess of the private key corresponding to that address.

However, it's possible to deviate from this base template to create more complex transactions, where other conditions must be met in order to spend the transaction output.

Is it possible to create a transaction where a sum is deposited into an address, but only the owner of *another* private key is allowed to spend it? I'm not a Bitcoin scripting expert, but this looks at least possible.

In this case, can such a crafted transaction be used to mount a double-spending attack, where address A sends sum X to address B, but after the transaction is completed address A retains ownership of the sum and can send it elsewhere, while address B can actually do nothing about it even if the sum is credited to its balance?

How would a standard wallet treat such a transaction? Would it even recognize there's something strange going on, or would it blindly display that X BTC entered address B, regardless of the transaction script?

---

## Edit:

Sorry, I was misled by how sites such as [blockchain.info](http://blockchain.info) display transactions: a transaction doesn't actually contain any "output address", it only contains outputs which state the conditions necessary to spend them; the "output address" is computed by checking which address's signature is requested by the output script; thus it's impossible to "send money to address B" without actually placing address B in the output script.

However, the question somewhat remains: could a transaction be crafted to fool a wallet into telling its user "I received X BTC" while someone else can actually claim the sum using another private key?

**Tags:** transactions, script, doublespend, signature

> **Comments:**
> **username_0**: Please note that the transaction as I described it is crafted so that *B has no right at all* to spend the sum; a more complex transaction could instead allow both B and A to spend it.  
> **username_0**: Ok, that wouldn't work (see edit). But maybe something else would...  

---

## 2 answers

### Answer by username_1 on 2014-05-15. Score: 3

What you're describing is a contradiction of terms. If a sum of money is deposited into an address, that means that *only* that address's private key can spend the money.

Maybe you could craft a non-standard transaction and tell people it's giving address B's owner permission to spend it, but if people look closely enough at the transaction, they'll be able to tell that it's really address C (and not B)'s owner that can spend it. There's no way around this: the transaction output is public, as is the implementation of how it works.

So if the question is: can you fool software X with a non-standard transaction? Perhaps, it would depend on finding a bug (or other less-than-ideal situation) in the software in question. (for example, if you craft a transaction that can be spent by address B or C, maybe the wallet owning B will say it has the balance, and if he doesn't transfer it again before you do, then you can "steal back" the money that way) However, I'd treat any non-standard transactions as highly suspect.

> **Comments:**
> **username_0**: Agreed (see edit). However, the question stands: how do clients react to non-standard transactions? How does f.e. the reference client go from "a transaction's output script" to "hey, you just received 42 BTC"? Could it be tricked by something like this?  

---

### Answer by username_2 on 2014-05-17. Score: 2

No, you won't fool the standard client with this. If it does not understand the script completely (i.e. it is a nonstandard script), it does not try to *parse it partially* or whatnot. The procedure is simple: if the client can't understand the script completely, it is simply ignored. Period.

> **Comments:**
> **username_0**: Any reference for this? What types of transactions are considered "standard"? Who decides if a transaction is a standard one? How can you even get a nonstandard transaction mined into the blockchain if the reference software simply ignores it?  
> **username_2**: There's a protocol and then there's the reference implementation and other implementations as well. While the protocol is stable, implementations are not and some features are adopted more quickly in some clients. The same goes with the policy of relying trx - different implementations have slightly different rules when it comes to decisions about relying trx. What is a "standard" script depends on the client, but generally it is a script that requires valid public key and a signature. More info [here](http://bitcoin.stackexchange.com/questions/18638/not-relaying-non-standard-transactions).  
> **username_3**: see https://github.com/bitcoin/bitcoin/blob/6513a9f7033737458735305a08606280d6d0d33c/src/script.cpp#L1203 (function solver) - even if you don't know programming, those four lines should be clear enough, and they contain the four standard transactions. The future bitcoind versions will allow for any other txs to be standard ( https://bitcoin.stackexchange.com/questions/28181/what-new-transactions-are-possible-with-15-operations ), but still - the clients/wallets look at the whole tx to compute the bitcoin address.  

---

