{"id":1299,"date":"2014-12-09T00:00:00","date_gmt":"2014-12-09T00:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1299"},"modified":"2015-02-19T20:36:47","modified_gmt":"2015-02-19T20:36:47","slug":"bitcoin-explained-vii-2","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1299","title":{"rendered":"Bitcoin Explained (VIII)"},"content":{"rendered":"

Last time<\/a> we saw how once you are the \u00e2\u20ac\u0153owner\u00e2\u20ac\u009d of some bitcoins, that gives you the magical power of being able to specify what conditions the next claimant must meet before they become the \u00e2\u20ac\u0153owner\u00e2\u20ac\u009d<\/p>\n

As flexible as it is, there is a problem with this arrangement. Every client has to be taught how to manufacture every special condition script. Let\u00e2\u20ac\u2122s say we want to do an M-of-N payout to implement an escrow transaction. I have my mobile wallet, and you have a web wallet, and we have some arbiter who is using a desktop client. We have to find some way of generating a script, then each of us providing signatures of it, and inputs to it with our coins. There is no standard protocol for doing that, and if there were, it would be a lot of work for each of the wallet developers to implement.<\/p>\n

Then what if someone comes up with a new type of condition script: a time-locked M-of-N with trusted party abort?<\/p>\n

Finally, this ever-more complicated script has to go in the spending transaction \u00e2\u20ac\u201c the person doing the spending then is faced with the miner\u00e2\u20ac\u2122s per-byte cost of the transaction, but the spender doesn\u00e2\u20ac\u2122t care what complicated measures the next owner wants to impose on their newly owned coins, why should they pay the higher fee?<\/p>\n

The solution is pay to script hash<\/em> or P2SH as it\u00e2\u20ac\u2122s often abbreviated.<\/p>\n

The idea is that instead of paying to a Bitcoin address, or rather, instead of specifying a condition in the transaction output, the spender specifies nothing other than the hash of the script that is allowed to make the claim. Now, think back to our previous standard claim script:<\/p>\n

{\n   "lock_time":0,\n   "size":341,\n   "inputs":[\n      {\n         "prev_out":{\n            "index":0,\n            "hash":"ac13d28fd26c1b7e88083c63859d0010919c5b037676f1b424807674f6f54377"\n         },\n         "script":"00483045022100c99f1a41b28693087617fb03c45e7504654f251423a4c5e2b5b9f4ee8ff04482022027b5f55c36507167ef24f109e5ff44e279447ec80641bdf21299d971035e2fa10148304502200acf7136240358e010f2b09a5818068a00169667218763ae698d4d118751a73c022100abe7a4984cc312ac28ea69c69636f4801b05bc952221342f875eeea237bca8d6014c6952210397c34bc26fd4dc5523c83b0027c18a7505c2668ff8d6ec8834b08074d80bd8f42102f8cc6389cbfac80ee9432a0e2e370b0c0f52b1359df3faddae266a966b11bb712103c072355c488cf8a064ba9d6c2255d7a4ac06b0de4d637870541a815e8f5ce7db53ae"\n      }\n   ],\n   "version":1,\n   "vin_sz":1,\n   "hash":"f84007fb6b7faba3c5de7fb30526744f9b4e8e3d8841d5d4416c5c8a3d632648",\n   "vout_sz":1,\n   "out":[\n      {\n         "script_string":"OP_DUP OP_HASH160 af5cda336bfb8c7543d40e65ae1c3acab95549bf OP_EQUALVERIFY OP_CHECKSIG",\n         "address":"1GzEV4jzdR1A715J1rvU5GomW3a5UJZqaZ",\n         "value":4672558,\n         "script":"76a914af5cda336bfb8c7543d40e65ae1c3acab95549bf88ac"\n      }\n   ]\n}<\/code><\/pre>\n
\n
Implementing this feature required a change<\/a> to the transaction format in core Bitcoin.<\/p>\n
Let\u00e2\u20ac\u2122s have a look at a P2SH address<\/a> in the wild. This is a P2SH address with one transaction paying it, and one transaction paying out from it. First the (abridged) transaction<\/a> that funds it.<\/p>\n
{\n   "lock_time":0,\n   "size":224,\n   "version":1,\n   "vin_sz":1,\n   "hash":"ac13d28fd26c1b7e88083c63859d0010919c5b037676f1b424807674f6f54377",\n   "vout_sz":2,\n   "out":[\n      {\n         "script_string":"OP_HASH160 c57a2d34802679c0916cdb447d128c1708844354 OP_EQUAL",\n         "address":"3KhBQK4BzGcYEyi6gxnumVYYDcr9EZY4Qj",\n         "value":4673558,\n         "script":"a914c57a2d34802679c0916cdb447d128c170884435487"\n      },\n   ]\n}<\/code><\/pre>\n
Then the (abridged) transaction<\/a> that spends from the P2SH address:<\/p>\n
{\n   "lock_time":0,\n   "size":341,\n   "inputs":[\n      {\n         "prev_out":{\n            "index":0,\n            "hash":"ac13d28fd26c1b7e88083c63859d0010919c5b037676f1b424807674f6f54377"\n         },\n         "script":"00483045022100c99f1a41b28693087617fb03c45e7504654f251423a4c5e2b5b9f4ee8ff04482022027b5f55c36507167ef24f109e5ff44e279447ec80641bdf21299d971035e2fa10148304502200acf7136240358e010f2b09a5818068a00169667218763ae698d4d118751a73c022100abe7a4984cc312ac28ea69c69636f4801b05bc952221342f875eeea237bca8d6014c6952210397c34bc26fd4dc5523c83b0027c18a7505c2668ff8d6ec8834b08074d80bd8f42102f8cc6389cbfac80ee9432a0e2e370b0c0f52b1359df3faddae266a966b11bb712103c072355c488cf8a064ba9d6c2255d7a4ac06b0de4d637870541a815e8f5ce7db53ae"\n      }\n   ],\n   "version":1,\n   "vin_sz":1,\n   "hash":"f84007fb6b7faba3c5de7fb30526744f9b4e8e3d8841d5d4416c5c8a3d632648",\n   "vout_sz":1,\n}<\/code><\/pre>\n
My \u00e2\u20ac\u0153abridgements\u00e2\u20ac\u009d in these cases are to remove the inputs and outputs that aren\u00e2\u20ac\u2122t under discussion \u00e2\u20ac\u201c hopefully that let\u00e2\u20ac\u2122s you see the pieces that are relevant, without having so many impenetrable long hex numbers to sift through.<\/p>\n
So you can see that the spending transaction\u00e2\u20ac\u2122s input references the funding transaction\u00e2\u20ac\u2122s output (funding_hash:index<\/code>). Next notice that the condition script is smaller than the standard one we examined previously<\/a>. The funding (output) script is:<\/p>\n
OP_HASH160\nPUSH_20 c57a2d34802679c0916cdb447d128c1708844354\nOP_EQUAL<\/code><\/pre>\n
BIP16<\/a> describes how a P2SH output may be \u00e2\u20ac\u0153spotted\u00e2\u20ac\u009d and it is this form of address that does it OP_HASH160<\/code>, PUSH_20<\/code>, OP_EQUAL<\/code>). It\u00e2\u20ac\u2122s not just a script, it\u00e2\u20ac\u2122s a marker to tell the Bitcoin core that this script is not, in fact, to be used as a script; rather that this is a P2SH output. The fact that it is a P2SH-patterned output is also what allows anyone displaying this output to show it as a class-5 address (which is a \u00e2\u20ac\u01533\u00e2\u20ac\u009d in bas58).<\/p>\n
I think, if the Bitcoin developers had known what they know now, there would never have been anything but<\/em> P2SH \u00e2\u20ac\u201c the output \u00e2\u20ac\u0153scripts\u00e2\u20ac\u009d would have been only a hash, and nothing else. The three extra bytes here are not the most painful of overheads, so it\u00e2\u20ac\u2122s not the end of the world.<\/p>\n
Running this as if it were a script using pre-P2SH rules, will always fail. An OP_HASH160<\/code> is 33 bytes, so the OP_EQUAL<\/code> operation will never return true if this is not<\/em> identified as a P2SH marker.<\/p>\n
It\u00e2\u20ac\u2122s important to remember that this is no longer<\/em> a script. It is a backward-compatible way of switching bitcoin to P2SH mode and supply the hash<\/em> of the only claimant script that is allowed to claim it. The claimant script must not only successfully complete, but it must first match this hash before bitcoin will even attempt to execute it. Let\u00e2\u20ac\u2122s look in more detail then at the claim (input) script:<\/p>\n
00 (OP_FALSE)\n48 (PUSH_72)\n   30 45 02 21 00 c9 9f 1a   41 b2 86 93 08 76 17 fb\n   03 c4 5e 75 04 65 4f 25   14 23 a4 c5 e2 b5 b9 f4\n   ee 8f f0 44 82 02 20 27   b5 f5 5c 36 50 71 67 ef\n   24 f1 09 e5 ff 44 e2 79   44 7e c8 06 41 bd f2 12\n   99 d9 71 03 5e 2f a1 01\n48 (PUSH_72)\n   30 45 02 20 0a cf 71 36   24 03 58 e0 10 f2 b0 9a\n   58 18 06 8a 00 16 96 67   21 87 63 ae 69 8d 4d 11\n   87 51 a7 3c 02 21 00 ab   e7 a4 98 4c c3 12 ac 28\n   ea 69 c6 96 36 f4 80 1b   05 bc 95 22 21 34 2f 87\n   5e ee a2 37 bc a8 d6 01\n4c 69 (OP_PUSHDATA1(105))\n   52 21 03 97 c3 4b c2 6f   d4 dc 55 23 c8 3b 00 27\n   c1 8a 75 05 c2 66 8f f8   d6 ec 88 34 b0 80 74 d8\n   0b d8 f4 21 02 f8 cc 63   89 cb fa c8 0e e9 43 2a\n   0e 2e 37 0b 0c 0f 52 b1   35 9d f3 fa dd ae 26 6a\n   96 6b 11 bb 71 21 03 c0   72 35 5c 48 8c f8 a0 64\n   ba 9d 6c 22 55 d7 a4 ac   06 b0 de 4d 63 78 70 54\n   1a 81 5e 8f 5c e7 db 53   ae<\/code><\/pre>\n
This, again, is a P2SH-specific layout. If run as a script directly, OP_FALSE<\/code> would simply cause it to fail instantly. Remember though that the funding \u00e2\u20ac\u0153script\u00e2\u20ac\u009d is known at this point, and we\u00e2\u20ac\u2122ve already seen that we can detect the funding script as a P2SH hash, and hence know that the claiming \u00e2\u20ac\u0153script\u00e2\u20ac\u009d should be interpreted as a P2SH claim. These have some special rules:<\/p>\n