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?


Sorry, I was misled by how sites such as 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?

  • 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 May 15 '14 at 12:40
  • I thought a key is generated for each individual transaction, so if A or B doubke spend on this sum it had to be a totally different and debit from the originating account – user15793 May 15 '14 at 14:27
  • Ok, that wouldn't work (see edit). But maybe something else would... – Massimo May 15 '14 at 15:23

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.

  • 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 May 15 '14 at 15:21

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.

  • 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 May 18 '14 at 19:18
  • 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. – Jozef May 19 '14 at 10:06
  • 1
    see github.com/bitcoin/bitcoin/blob/… (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 ( bitcoin.stackexchange.com/questions/28181/… ), but still - the clients/wallets look at the whole tx to compute the bitcoin address. – kolinko Jul 17 '14 at 21:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.