Note: You are viewing this blog post without the intended style information, which may result in formatting issues.
By the time I had a look into Craig Wright's blog post that seemed to imply that he is Satoshi, others had already pointed out that the signature was copied from a 2009 transaction. The contents of the "Sartre" file, however, were still a mystery. Dan Kaminsky had a blog post up analyzing the commands from CW's post, but hadn't been able to figure that bit out, so he asked me to have a look.
Following a screenshot of the output of
sha256sum Sartre, there's a
screenshot purportedly the file being displayed through a program called
more, but only the first 14% can be seen,
making it impossible to verify. How convenient. It's also important to note
that what CW signs is the raw sha256 of "Sartre" rather than the file itself.
OpenSSL will sha256 that data it's signing or verifying anyway, so this would
normally be unnecessary step. More on that in a bit.
Given that the signature is valid, there are really very few possible explanations of what's going on.
- CW has a computationally feasible preimage attack on sha256
- CW is Satoshi and has a been sitting on computationally feasible collision attack on sha256 since 2009
- CW is some sort of actual wizard who enjoys trolling cryptocurrency geeks.
- CW has pulled some sort of digital slight-of-hand
So, about that last one. Obviously, the signature presented was valid for that
Bitcoin transaction, but where did the value
come from? Finding out requires digging a bit into the innards of Bitcoin. I
was not feeling quite masochist enough to slog through a bunch of C++ code this
morning, so I pulled up
We need to know exactly what is being passed into ECDSA to verify a transaction.
1 2 3 4 5 6 7 8 9 10
def verify_tx_input(tx, i, script, sig, pub): if re.match('^[0-9a-fA-F]*$', tx): tx = binascii.unhexlify(tx) if re.match('^[0-9a-fA-F]*$', script): script = binascii.unhexlify(script) if not re.match('^[0-9a-fA-F]*$', sig): sig = safe_hexlify(sig) hashcode = decode(sig[-2:], 16) modtx = signature_form(tx, int(i), script, hashcode) return ecdsa_tx_verify(modtx, sig, pub, hashcode)
...the second to last line in this function being the critical one. What does
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
def signature_form(tx, i, script, hashcode=SIGHASH_ALL): i, hashcode = int(i), int(hashcode) if isinstance(tx, string_or_bytes_types): return serialize(signature_form(deserialize(tx), i, script, hashcode)) newtx = copy.deepcopy(tx) for inp in newtx["ins"]: inp["script"] = "" newtx["ins"][i]["script"] = script if hashcode == SIGHASH_NONE: newtx["outs"] =  elif hashcode == SIGHASH_SINGLE: newtx["outs"] = newtx["outs"][:len(newtx["ins"])] for out in newtx["outs"][:len(newtx["ins"]) - 1]: out['value'] = 2**64 - 1 out['script'] = "" elif hashcode == SIGHASH_ANYONECANPAY: newtx["ins"] = [newtx["ins"][i]] else: pass return newtx
It turns out that the actual data signed does not exactly match the transaction
that is recorded in the blockchain. There are three reasons for this. The first
is that it is not, in general, possible for a signature to contain itself.
The second has to do with these "SIGHASH" flags. The details of how those work
can be found in the documentation for
OP_CHECKSIG, but it's not important
to understand them for the relevant transaction. The third is that since the
signature is spending a previous transaction's output, it needs to include
information about it. That's what the parameters
i (identifies the input
number for this transaction) and
script (the "scriptPubKey" from the
transaction output being spent) are for.
Feeding the to the
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44
# pybitcointools https://github.com/vbuterin/pybitcointools from bitcoin import * # output of # `bitcoin-cli getrawtransaction 828ef3b079f9c23829c56fe86e85b4a69d9e06e5b54ea597eef5fb3ffef509fe` tx = '0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63'+\ 'b5120100000049483045022100c12a7d54972f26d14cb311339b5122f8c187417dde1e'+\ '8efb6841f55c34220ae0022066632c5cd4161efa3a2837764eee9eb84975dd54c2de28'+\ '65e9752585c53e7cce01ffffffff0200ca9a3b00000000434104bed827d37474beffb3'+\ '7efe533701ac1f7c600957a4487be8b371346f016826ee6f57ba30d88a472a0e4ecd2f'+\ '07599a795f1f01de78d791b382e65ee1c58b4508ac00d2496b0000000043410411db93'+\ 'e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0eaddfb84'+\ 'ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000' # from # `bitcoin-cli getrawtransaction 12b5633bad1f9c167d523ad1aa1947b2732a865bf5414eab2f9e5ae5d5c191ba 1` spk = '410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5c'+\ 'b2e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac' # create signature verification 'modified transaction' modtx = signature_form(tx, 0, spk, SIGHASH_ALL) # append the hashcode - in this case SIGHASH_ALL which is just 1 as a little-endian uint32 # see the txhash function modtx += hexlify(encode(SIGHASH_ALL, 256, 4)[::-1]) print modtx # 0100000001ba91c1d5e55a9e2fab4e41f55b862a73b24719aad13a527d169c1fad3b63b5120100 # 000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2e0 # eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3acffffffff0200ca9a # 3b00000000434104bed827d37474beffb37efe533701ac1f7c600957a4487be8b371346f016826 # ee6f57ba30d88a472a0e4ecd2f07599a795f1f01de78d791b382e65ee1c58b4508ac00d2496b00 # 00000043410411db93e1dcdb8a016b49840f8c53bc1eb68a382e97b1482ecad7b148a6909a5cb2 # e0eaddfb84ccf9744464f82e160bfa9b8b64f9d4c03f999b8643f656b412a3ac00000000010000 # 00 # un-hex bin_modtx = changebase(modtx, 16, 256) print sha256(bin_modtx) # 479f9dff0155c045da78402177855fdb4f0f396dc0d2c24f7376dd56e2e68b05 with open('Sartre', 'w') as f: f.write(bin_modtx)
I mentioned that normally, when using ECDSA to sign or verify a file, it is unnecessary to hash it manually. This is where CW's slight-of-hand lies. ECDSA computes the signature operation on a 256 bit integer referred to as z. Normally this is computed as sha256(message), but Bitcoin does sha256(sha256(modtx)). CW showed the signature verification using OpenSSL's ECDSA on sha256(modtx). OpenSSL does another sha256 on the data, which makes the z value match.
|||It's possible to construct ECDSA signatures that contain themselves, but the algorithm to do this works, essentially, by randomly generating a signature, then working backwards to compute a keypair for it. For reasons outside the scope of this blog post, this cannot be used for Bitcoin transactions.|