I must credit jimrandomh for this quote which put me on the right track.
Now suppose that instead of publishing an address that's the hash of my public key, I could instead publish an address that's the hash of an arbitrary script. Then, if I want to spend the coins along, I make a transaction containing both the script - which turns out to be a function that says I need some combination of signatures - and also the signatures that make the script return true. This seems like the right way to handle multi-key addresses.
When I first read
this proposal, it sounded to me like casascius was proposing a special scripting language for use with OP_CHECKSIGEX within the existing scripting language. This sounded inelegant; much better to have one scripting language we can use for everything. However I missed the point casascius was trying to make. Here's my version of the same idea using a new opcode OP_EVAL.
At the moment, most scriptPubKeys look like "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG".
It's easy to see that to satisfy this scriptPubKey
you need to supply a scriptSig containing a signature and a public key. When you send someone your address, it's taken by the current client as an instruction to build a scriptPubKey of the above type when making a payment to that address. This means that one just needs to distribute a shorter public key hash to receive payments rather than the longer public key.
When
blockexplorer sees a transaction with the above scriptPubKey it knows that only a public key with the specified hash can be used to satisfy it and hence it's possible to calculate the "balance" of an address.
We could introduce a new address type of the same length (but with incremented version number) and the new opcode. Use of the new address would mean that the intended scriptPubKey would look like "OP_DUP OP_HASH160 OP_EQUALVERIFY OP_EVAL".
In order to spend the transaction, the holder of that address has to construct a scriptSig which probably looks like "