{"id":1297,"date":"2014-12-08T00:00:00","date_gmt":"2014-12-08T00:00:00","guid":{"rendered":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1297"},"modified":"2014-12-07T13:08:24","modified_gmt":"2014-12-07T13:08:24","slug":"bitcoin-explained-vii","status":"publish","type":"post","link":"https:\/\/www.fussylogic.co.uk\/blog\/?p=1297","title":{"rendered":"Bitcoin Explained (VII)"},"content":{"rendered":"

This series of articles is an extension to my earlier Bitcoin Explained<\/a> series. It absolutely isn\u00e2\u20ac\u2122t necessary for understanding bitcoin, the previous articles are still valid. However, I recently made use of the Brawker<\/a> website, and wanted to understand their use of P2SH more fully. This new series of articles is the result of me trying to gain that understanding, and on the way explaining transactions in more detail.<\/p>\n

We\u00e2\u20ac\u2122ll begin with the idea of bitcoin scripts.<\/p>\n

First let me repeat the diagram I gave in Part VI<\/a>, as to the contents of a particular transaction (#5004 in this case):<\/p>\n

TX#5000:out#1 = ...\nTX#5000:out#2 = ...\nTX#5000:out#3 =  50 BTC -\n                         \\\n       ...                \\\nTX#5001:out#3 = ...        \\             \/-- 80 BTC -> PUBKEY#9292\nTX#5001:out#5 = 150 BTC ----+- TX#5004 -+\nTX#5001:out#6 = ...        \/  (155 BTC)  \\-- 70 BTC -> PUBKEY#8755\n                          \/\nTX#5002:out#1 = ...      \/\nTX#5002:out#2 =   5 BTC -\n       ...<\/code><\/pre>\n
Earlier we found that the inputs were really references to earlier outputs; and in fact were \u00e2\u20ac\u0153claims\u00e2\u20ac\u009d on those outputs. The outputs of the transaction aren\u00e2\u20ac\u2122t really outputs, as they don\u00e2\u20ac\u2122t go anywhere, rather they are \u00e2\u20ac\u0153conditions of claim\u00e2\u20ac\u009d. Bitcoin transactions have their own, highly specific, scripting language that lets us describe the output conditions, and then meet those conditions with claims.<\/p>\n
Let me relabel the above diagram with that in mind:<\/p>\n
TX#5000:CONDITION#3\nCLAIM()  -> 50 BTC -\n                     \\\n                      \\\nTX#5001:CONDITION#5    \\             \/-- 80 BTC -> CONDITION#0\nCLAIM()  -> 150 BTC ----+- TX#5004 -+\n                       \/  (155 BTC)  \\-- 70 BTC -> CONDITION#1\n                      \/\nTX#5002:CONDITION#2  \/\nCLAIM()  ->   5 BTC -<\/code><\/pre>\n
Our \u00e2\u20ac\u0153inputs\u00e2\u20ac\u009d then, aren\u00e2\u20ac\u2122t really inputs, they are a reference to an earlier transaction\u00e2\u20ac\u2122s condition script, and a claim script that validates the claim.<\/p>\n
These \u00e2\u20ac\u0153scripts\u00e2\u20ac\u009d are a series of operators that perform actions on a stack. Not unlike Postscript or Forth.<\/p>\n
Let\u00e2\u20ac\u2122s look first at a typical transaction; here\u00e2\u20ac\u2122s one<\/a> I picked at random with a few clicks on . We can get the raw hex<\/a> of the transaction by appending \u00e2\u20ac\u0153?format=hex<\/code>\u00e2\u20ac\u009d to the transaction display URI.<\/p>\n
01 00 00 00 01 66 01 62   1c 41 a6 dc a0 38 1e 17\n3b 9a 8d 89 35 64 e9 3d   ea 95 9b 51 04 16 4c 82\n09 9e 34 d2 3c 06 00 00   00 6b 48 30 45 02 21 00\na7 55 54 4e 79 a1 d3 ff   9e 68 3e e5 34 cb a7 1e\n2a 7d b5 78 dd 39 2f 6f   67 d1 03 e9 7e 40 80 3f\n02 20 53 be 17 c6 dd f5   f7 b6 b1 64 44 a8 08 9f\nad 94 3d f0 1b 17 a3 08   89 96 c1 90 76 69 54 88\nba 4a 01 21 03 74 51 ce   c1 99 e4 6e cb 33 49 11\n4d 67 48 cc 4f 12 b9 40   63 2c b2 a3 73 92 83 63\nfe 1a fa 10 f8 ff ff ff   ff 02 10 ae 93 03 00 00\n00 00 19 76 a9 14 d7 c5   3f 1e d6 9e 35 f2 4b 3a\nc1 f0 22 7f 4f 17 73 dd   35 01 88 ac 80 d9 e9 02\n00 00 00 00 19 76 a9 14   38 d4 68 61 53 49 86 69\n4f b6 a0 b6 98 c0 88 a1   56 9d 44 15 88 ac 00 00\n00 00 <\/code><\/pre>\n
Remember that the bitcoin formats are pretty dense binary as every byte counts when we\u00e2\u20ac\u2122re storing billions of these things. We could decode this by hand for our edification (I\u00e2\u20ac\u2122d encourage you to do so if you are interested in programming, it\u00e2\u20ac\u2122s good for the soul), but http:\/\/blockchain.info<\/a> also have a very nice raw decoder<\/a> interface we can make use of.<\/p>\n
{\n   "lock_time":0,\n   "size":226,\n   "inputs":[\n      {\n         "prev_out":{\n            "index":6,\n            "hash":"3cd2349e09824c1604519b95ea3de96435898d9a3b171e38a0dca6411c620166"\n         },\n         "script":"483045022100a755544e79a1d3ff9e683ee534cba71e2a7db578dd392f6f67d103e97e40803f022053be17c6ddf5f7b6b16444a8089fad943df01b17a3088996c19076695488ba4a0121037451cec199e46ecb3349114d6748cc4f12b940632cb2a373928363fe1afa10f8"\n      }\n   ],\n   "version":1,\n   "vin_sz":1,\n   "hash":"85de8fa55135a4a0b126cafabe30b0b9b6034121cb7439740a30aaf34c25d127",\n   "vout_sz":2,\n   "out":[\n      {\n         "script_string":"OP_DUP OP_HASH160 d7c53f1ed69e35f24b3ac1f0227f4f1773dd3501 OP_EQUALVERIFY OP_CHECKSIG",\n         "address":"1LftaBA1WVJCPKen9tmrb8g5DgXAVghZKy",\n         "value":60010000,\n         "script":"76a914d7c53f1ed69e35f24b3ac1f0227f4f1773dd350188ac"\n      },\n      {\n         "script_string":"OP_DUP OP_HASH160 38d46861534986694fb6a0b698c088a1569d4415 OP_EQUALVERIFY OP_CHECKSIG",\n         "address":"16BVJ6G1FdocrgQ5kAQHLwxrA9gxfftXRX",\n         "value":48880000,\n         "script":"76a91438d46861534986694fb6a0b698c088a1569d441588ac"\n      }\n   ]\n}<\/code><\/pre>\n
This is the same information as was in the block of hex bytes, but decoded into more readable fields for us \u00e2\u20ac\u201c there is actually a little more than that here, as some additional hashes are calculated for convenience, but I\u00e2\u20ac\u2122ll not go into them now. Notice one input and two outputs. We\u00e2\u20ac\u2122ll ignore the outputs of this transaction, and instead focus on this transaction\u00e2\u20ac\u2122s single input.<\/p>\n
   "inputs":[\n      {\n         "prev_out":{\n            "index":6,\n            "hash":"3cd2349e09824c1604519b95ea3de96435898d9a3b171e38a0dca6411c620166"\n         },\n         "script":"483045022100a755544e79a1d3ff9e683ee534cba71e2a7db578dd392f6f67d103e97e40803f022053be17c6ddf5f7b6b16444a8089fad943df01b17a3088996c19076695488ba4a0121037451cec199e46ecb3349114d6748cc4f12b940632cb2a373928363fe1afa10f8"\n      }\n   ],<\/code><\/pre>\n
The script itself, needs a little bit of decoding, we will do this one by hand:<\/p>\n
48 (PUSH_72)\n   30 45 02 21 00 a7 55 54   4e 79 a1 d3 ff 9e 68 3e\n   e5 34 cb a7 1e 2a 7d b5   78 dd 39 2f 6f 67 d1 03\n   e9 7e 40 80 3f 02 20 53   be 17 c6 dd f5 f7 b6 b1\n   64 44 a8 08 9f ad 94 3d   f0 1b 17 a3 08 89 96 c1\n   90 76 69 54 88 ba 4a 01\n21 (PUSH_33)\n   03 74 51 ce c1 99 e4 6e   cb 33 49 11 4d 67 48 cc\n   4f 12 b9 40 63 2c b2 a3   73 92 83 63 fe 1a fa 10\n   f8 <\/code><\/pre>\n
The PUSH_nn<\/code> bitcoin script simply pushes the following nn<\/code> bytes of script onto the execution stack. To make this more straight forward to understand, I\u00e2\u20ac\u2122m going to write this as:<\/p>\n
PUSH_TRANSACTION_SIGNATURE\nPUSH_CLAIM_PUBLIC_KEY<\/code><\/pre>\n
Moving on to the other fields in the input<\/code> array, we can see that this script is claiming index 6 of previous transaction 3cd2349e09824c1604519b95ea3de96435898d9a3b171e38a0dca6411c620166. We can use http:\/\/blockchain.info<\/a> to look that transaction<\/a> up too. I won\u00e2\u20ac\u2122t repeat the whole hex and decode, you can look at them yourself should you be interested. Instead, let\u00e2\u20ac\u2122s just look at output 6, which is what our original transaction is claiming.<\/p>\n
{\n   "script_string":"OP_DUP OP_HASH160 b442e3f5440fa5858807b18a4c9aff6c773648df OP_EQUALVERIFY OP_CHECKSIG",\n   "address":"1HS8mAHuiemhxNdw7gGFYJTY8ioa3MYL4N",\n   "value":108900000,\n   "script":"76a914b442e3f5440fa5858807b18a4c9aff6c773648df88ac"\n},<\/code><\/pre>\n
We see then that our transaction is claiming 108900000 satoshis. The address<\/code> and script_string<\/code> fields have been added for convenience, consider them informational for now. What we\u00e2\u20ac\u2122re interested in is the script.<\/p>\n
OP_DUP\nOP_HASH160\nb442e3f5440fa5858807b18a4c9aff6c773648df\nOP_EQUALVERIFY\nOP_CHECKSIG<\/code><\/pre>\n
The vast majority (at present) of bitcoin outputs are condition scripts of this form \u00e2\u20ac\u201c and in truth, Bitcoin core maintains a list of what it calls \u00e2\u20ac\u0153standard\u00e2\u20ac\u009d scripts \u00e2\u20ac\u201c so entirely arbitrary scripts are not allowed in the interests of not ending up with abuse of all the full node\u00e2\u20ac\u2122s CPUs. A claim is tested for validity by prepending the claim script to it, then running the whole. The hex in the middle is the hex equivalent of the payee\u00e2\u20ac\u2122s bitcoin address. Bitcoin addresses are usually presented in base-58 and with a type-code and checksum, this is the raw hex form. A bitcoin \u00e2\u20ac\u0153address\u00e2\u20ac\u009d is in truth, the RIPE-160 hash of the public key in an ECDSA public\/private key pair.<\/p>\n
Let\u00e2\u20ac\u2122s combine the claim and the condition, and give the hex bytes symbolic names.<\/p>\n
PUSH_TRANSACTION_SIGNATURE\nPUSH_CLAIM_PUBLIC_KEY\nOP_DUP\nOP_HASH160\nPUSH_NEW_OWNER_PUBLIC_KEY\nOP_EQUALVERIFY\nOP_CHECKSIG<\/code><\/pre>\n
Now we\u00e2\u20ac\u2122re in a position to \u00e2\u20ac\u0153run\u00e2\u20ac\u009d this script. Remember that the script operates on a stack. That stack starts out empty, PUSH_TRANSACTION_SIGNATURE<\/code> leaves it as:<\/p>\n
TRANSACTION_SIGNATURE<\/code><\/pre>\n
Then PUSH_CLAIM_PUBLIC_KEY<\/code> adds its data (I\u00e2\u20ac\u2122ll draw the stack growing downwards):<\/p>\n
TRANSACTION_SIGNATURE\nCLAIM_PUBLIC_KEY<\/code><\/pre>\n
OP_DUP<\/code> copies the last item on the stack.<\/p>\n
TRANSACTION_SIGNATURE\nCLAIM_PUBLIC_KEY\nCLAIM_PUBLIC_KEY<\/code><\/pre>\n
OP_HASH160<\/code> calculates the RIPE-160 hash of the last stack item. Recall that a RIPE-160 hash of a public key is also a bitcoin address. So this operation in fact converts a public key into a bitcoin address:<\/p>\n
TRANSACTION_SIGNATURE\nCLAIM_PUBLIC_KEY\nCLAIM_BITCOIN_ADDRESS<\/code><\/pre>\n
PUSH_NEW_OWNER_PUBLIC_KEY<\/code> pushes its data onto the stack:<\/p>\n
TRANSACTION_SIGNATURE\nCLAIM_PUBLIC_KEY\nCLAIM_BITCOIN_ADDRESS\nNEW_OWNER_PUBLIC_KEY<\/code><\/pre>\n
OP_EQUALVERIFY<\/code> pops the last two items and compares them for equality; aborting in failure if they are not. Remember that PAYEE_ADDRESS<\/code> was part of the condition script, and CLAIM_PUBLIC_KEY<\/code> was from the claim script. So this operation is verifying that the person claiming this output is the owner of the public key referenced in the claimed transactions condition script.<\/p>\n
TRANSACTION_SIGNATURE\nOWNER_PUBLIC_KEY<\/code><\/pre>\n
And we\u00e2\u20ac\u2122re back to were we began, but this time so CLAIM_PUBLIC_KEY<\/code> becomes OWNER_PUBLIC_KEY<\/code>. We\u00e2\u20ac\u2122ve now got one operation left in the script, OP_CHECKSIG<\/code>. This is a biggie. OP_CHECKSIG<\/code> is a complex, compound operator, and it\u00e2\u20ac\u2122s shortness is deceptive. (If I\u00e2\u20ac\u2122m honest, I find OP_CHECKSIG<\/code> one of the smelliest bits of bitcoin precisely because it\u00e2\u20ac\u2122s operations are so complex, it relies on a very particular set of byte formats and memory operations, and you\u00e2\u20ac\u2122d be basically very worried about reimplementing it yourself in case you differed even slightly from the bitcoin-core implementation).<\/p>\n
What it does is take the rest of the claiming transaction and verify that the signature of it, TRANSACTION_SIGNATURE<\/code>, was generated by OWNER_PUBLIC_KEY<\/code>. Phew. \u00e2\u20ac\u0153The rest of the claiming transaction\u00e2\u20ac\u009d is important \u00e2\u20ac\u201c what\u00e2\u20ac\u2122s being signed is the output condition<\/em> section of the new transaction \u00e2\u20ac\u201c i.e.\u00c2\u00a0the conditions that the next claimant must meet. That means that only<\/em> the owner of OWNER_PUBLIC_KEY<\/code> can specify how his property can next be claimed.<\/p>\n
Let\u00e2\u20ac\u2122s simplify this: if I want to pay you, I must claim some other coins that have previously specified that only I can claim them. I must then specify who is the next claimant \u00e2\u20ac\u201c you. I do that by saying (in script form) \u00e2\u20ac\u0153only a signature generated by PAYEE_ADDRESS<\/code> can specify the next condition script for these coins\u00e2\u20ac\u009d. Since I do not own the private key for PAYEE_ADDRESS<\/code>, even I cannot meet my own condition \u00e2\u20ac\u201c only you can.<\/p>\n
That\u00e2\u20ac\u2122s the current standard bitcoin transaction that every client and every node will use by default. It should be clear though, that the claim script we specified was entirely arbitrary. Nothing, in fact, stops us from specifying the following condition script:<\/p>\n
OP_TRUE<\/code><\/pre>\n
Anyone<\/em> would be able to meet this condition; all they need do is create a transaction that claims to meet it, and it\u00e2\u20ac\u2122s theirs. It will become a \u00e2\u20ac\u0153first to pick up the money I found lying around\u00e2\u20ac\u009d situation. You can imagine then that the variety of possible condition scripts is infinite.<\/p>\n
Next time, I\u00e2\u20ac\u2122ll discuss the limitations of this arrangement, and how bitcoin has addressed those limitations with P2SH (pay to script hash).<\/p>\n","protected":false},"excerpt":{"rendered":"
This series of articles is an extension to my earlier Bitcoin Explained series. It absolutely isn\u00e2\u20ac\u2122t necessary for understanding bitcoin, the previous articles are still valid. However, I recently made use of the Brawker website, and wanted to understand their use of P2SH more fully. This new series of articles is the result of me\u2026 Read More »<\/a><\/span><\/p>\n","protected":false},"author":2,"featured_media":0,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[1],"tags":[20],"_links":{"self":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1297"}],"collection":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1297"}],"version-history":[{"count":4,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1297\/revisions"}],"predecessor-version":[{"id":1304,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=\/wp\/v2\/posts\/1297\/revisions\/1304"}],"wp:attachment":[{"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1297"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1297"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.fussylogic.co.uk\/blog\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1297"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}