How do popular clients behave if they receive bitcoins with unknown script?

[caveden]

I was discussing Bitcoin with some geek colleagues today during lunch, and one made a question to which I'd like to verify the answer.

He asked what would happen if somebody send some coins to an address A which I control, but the script to spend this output cannot be executed by me, so I can't actually spend that money (he was trying to imagine a scam in which you claim to have made a payment, the receiver verifies the payment, but then with the use of script you send the money back to yourself).

I answered that what would probably happen is that bitcoind (and I hope every other client) would not consider that the money is in your wallet. If you're not capable of spending it, it's not yours, even if your address is in the outputs of the tx.

That's correct... right?

Can I assume that every time that my client does not immediately recognizes the script that was attached to the output, it considers that the money is not mine, even if the script in question actually allows me to spend that money? (imagine it's a any-of-2 multisig, for instance)?

Thanks.

[Pieter Wuille]

Exactly right.

In essence, an address is a shorthand for a particular output script. So saying that someone sends to your address with a script that you don't know how to sign doesn't really make sense. What is possible, is constructing a script for which you know that the holder of some private key can spend it in theory, without using a standard ouput script.

So, the problem doesn't exist really: when your client constructs an address, it encodes precisely how it wants outputs sent to it.

[kjj]

If it isn't a normal transaction, then your client won't recognize it, won't update the wallet, won't show a higher balance.

What you normally think of as "sending to an address that I control" is a very specific transaction template.  You can't just mash a bunch of bytes together and stick an address into the middle of it, hoping that the client just greps for known keys or something.

[caveden]

Thank you,

So, the problem doesn't exist really: when your client constructs an address, it encodes precisely how it wants outputs sent to it.

But, if that's the case, what was the point of that pay-to-script-hash development? If the address always contained the script, since the beginning of Bitcoin times, what did that development add?

Was it because the script was not hashed in the address, so the longer it was, the longer the address would be? The whole point was to have constant-sized addresses?

[DeathAndTaxes]

Thank you,

So, the problem doesn't exist really: when your client constructs an address, it encodes precisely how it wants outputs sent to it.

But, if that's the case, what was the point of that pay-to-script-hash development? If the address always contained the script, since the beginning of Bitcoin times, what did that development add?

Was it because the script was not hashed in the address, so the longer it was, the longer the address would be? The whole point was to have constant-sized addresses?

The address IS the hash of the script.  Your client won't see funds sent to that address as "yours".  The funds are sent to the script.  You seem to think that P2SH works like take a normal address and bolt a script on to it.  No you take a script and then calculate the hash of the script and the address from that.   The reference client wouldn't see funds sent to a P2SH address as yours any more than it sees funds sent to any standard address that is lacks the private key for as "yours".

The scenario you and your friend are debating is simply impossible.  No protection is needed in the client because it can't happen.  The reference client understands addresses which are the hash of public keys that it has private keys for.   If funds are sent to an address that your client has the private key for then they are "your" coins and nobody can change that and the balance is incremented.  If coins are sent anywhere else your client doesn't even see that as funds sent to "your" address.

[caveden]

You seem to think that P2SH works like take a normal address and bolt a script on to it.  No you take a script and then calculate the hash of the script and the address from that.  

I understand that. My doubt concerned classic transactions (what existed before P2SH), in which - I thought - the script was defined by the sender.

Apparently, according to Pieter Wuille, it was always the recipient that specified the script via the receiving address. So I'm imagining the only change brought by P2SH was to hash the script portion in the address, making it constant-sized, is that the case?

EDIT: I don't see where the script enters in the steps described here though... It only comments this

Normal addresses currently always start with 1 (addresses from script hashes use 3)

So I suppose there are different algorithms for the production (and parsing) of an address, the one described on that page only concerns "classic addresses".

[kjj]

I understand that. My doubt concerned classic transactions (what existed before P2SH), in which - I thought - the script was defined by the sender.

Apparently, according to Pieter Wuille, it was always the recipient that specified the script via the receiving address. So I'm imagining the only change brought by P2SH was to hash the script portion in the address, making it constant-sized, is that the case?

EDIT: I don't see where the script enters in the steps described here though... It only comments this

Normal addresses currently always start with 1 (addresses from script hashes use 3)

So I suppose there are different algorithms for the production (and parsing) of an address, the one described on that page only concerns "classic addresses".

Well, in ordinary "pay to pubkeyhash (address)" transactions, the script is written by the sender.  But your client doesn't think that it is a payment to your wallet unless it is written in a very specific way.  If it isn't OP_DUP OP_HASH160 {your key} OP_EQUALVERIFY OP_CHECKSIG, then it isn't really "to" your address, and your node will ignore it.  Maybe you can redeem it with your key, or maybe not.  If a sender points to some gibberish transaction and claims that it is valid, the alarm bells in your head should be going off.

In P2SH, you create the script yourself, and hash the entire script, including any and all pubkeys needed to redeem it.  If you do that, when you see a transaction to the P2SH address (which is an encoding of that hash), you can spend it as usual.  If someone else gives you a P2SH address, and claims that it is for you, then again, alarm bells.

Things can get murkier in multi-sig transactions, but you aren't going to stumble into that situation by accident, you'll get there because of an existing trust relationship.  For example, you may pay to use a service that protects your wallet by storing a second set of keys, and then they can generate P2SH multi-sig addresses that can only be redeemed with both one of their keys, and one of your keys.  How much you should trust payments sent to those P2SH addresses that you were given will depend on how much you trust that service, but again, you aren't stumbling blindly into this situation.