Raw transaction from Value Overflow Incident

[ercewubam]

What is the exact form of raw transaction from Value Overflow Incident? I tried to recreate it, but I guess I am doing something wrong.

Link to the topic: https://bitcointalk.org/index.php?topic=822.0

My attempt:

Code:

decoderawtransaction 0100000001395d705a36b122c01c9be97f8c69994c03bb8a0531990411ce7ac78f34e87f23000000008b483045022100db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f6879302205ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027ca841046b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7adfb0627ad7bda601ad2d129ebf037c5750841e9ba64ab199c4cb8280a95335d96ffffffff02af63f8ffffffff7f1976a91490e8d5ba1c2a301824b18d383dead728b13ea7b788acaf63f8ffffffff7f1976a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac00000000
{
  "txid": "ffbe549076b4b550088b4eee11106b702ca091efd360de0a6397dd7ca3e36bc1",
  "hash": "ffbe549076b4b550088b4eee11106b702ca091efd360de0a6397dd7ca3e36bc1",
  "version": 1,
  "size": 258,
  "vsize": 258,
  "weight": 1032,
  "locktime": 0,
  "vin": [
    {
      "txid": "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f6879302205ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027ca8 046b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7adfb0627ad7bda601ad2d129ebf037c5750841e9ba64ab199c4cb8280a95335d96",
        "hex": "483045022100db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f6879302205ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027ca841046b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7adfb0627ad7bda601ad2d129ebf037c5750841e9ba64ab199c4cb8280a95335d96"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 92233720368.54277039,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 90e8d5ba1c2a301824b18d383dead728b13ea7b7 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1EDDEGtrZ5877WPsLU5o9TwjJDqaUqhvte)#h50rucd6",
        "hex": "76a91490e8d5ba1c2a301824b18d383dead728b13ea7b788ac",
        "address": "1EDDEGtrZ5877WPsLU5o9TwjJDqaUqhvte",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 92233720368.54277039,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 2c72c4b5e0cbf9b6435f2cec9df8668c50751215 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu)#squqxq0e",
        "hex": "76a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac",
        "address": "1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu",
        "type": "pubkeyhash"
      }
    }
  ]
}

It seems that outputs are decoded properly, because the second address even exists on-chain: https://mempool.space/address/1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu

However, I am curious about scriptSig, because it is very strange. It has this weird "a8" ending, which sounds like invalid sighash. What is taken in that case? SIGHASH_ALL? Also, I don't know, how to make any message, which will hash into 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9. And then, what is the z-value, which is used to make this signature? What are the last four bytes, added to the transaction? Is it "01000000"? Or maybe "a8000000"? Or something else?

In case of the coinbase transaction, that was quite easy:

Code:

decoderawtransaction 01000000010000000000000000000000000000000000000000000000000000000000000000ffffffff08040e80001c028f00ffffffff01c024102d01000000434104750f835e45baa59bda8989092a3f4c7e201bbb6dc2265f12ea4e044b849acfe1656ecf6f4e99516cd9b95486bda27e7c8363798b8ec7a2a8c3f880155da54b4fac00000000
{
  "txid": "012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca",
  "hash": "012cd8f8910355da9dd214627a31acfeb61ac66e13560255bfd87d3e9c50e1ca",
  "version": 1,
  "size": 135,
  "vsize": 135,
  "weight": 540,
  "locktime": 0,
  "vin": [
    {
      "coinbase": "040e80001c028f00",
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 50.51000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "04750f835e45baa59bda8989092a3f4c7e201bbb6dc2265f12ea4e044b849acfe1656ecf6f4e99516cd9b95486bda27e7c8363798b8ec7a2a8c3f880155da54b4f OP_CHECKSIG",
        "desc": "pk(04750f835e45baa59bda8989092a3f4c7e201bbb6dc2265f12ea4e044b849acfe1656ecf6f4e99516cd9b95486bda27e7c8363798b8ec7a2a8c3f880155da54b4f)#r9p0z7n3",
        "hex": "4104750f835e45baa59bda8989092a3f4c7e201bbb6dc2265f12ea4e044b849acfe1656ecf6f4e99516cd9b95486bda27e7c8363798b8ec7a2a8c3f880155da54b4fac",
        "type": "pubkey"
      }
    }
  ]
}

Also, merkle tree was quite easy to decode, because it is just a concatenation of both transaction hashes, with reversed bytes:

Code:

cae1509c3e7dd8bf550256136ec61ab6feac317a6214d29dda550391f8d82c01c93353b694c1da2fa8778040e767ad98951e2fb50e973b37efcb23972a515e1d
5eecb6808d6de56a05211483d86fc6c7d17cda46c3388dd0c8139e4114ba8e61
618eba14419e13c8d08d38c346da7cd1c7c66fd8831421056ae56d8d80b6ec5e

And, for completeness, the 80-byte block header:

Code:

01000000846e2b968653ef0a25a92c12e8884d76919907df8e3079e665686000000000005eecb6808d6de56a05211483d86fc6c7d17cda46c3388dd0c8139e4114ba8e61751e684c0e80001ccf2fae01
1ceca770147b6f7ac697ebdd0bbf9a56abb643ad56c72ef2b30a790000000000
0000000000790ab3f22ec756ad43b6ab569abf0bddeb97c67a6f7b1470a7ec1c

I guess I did some mistake in calculating sighashes, but I don't know exactly, where it is.

[pooya87]

However, I am curious about scriptSig, because it is very strange. It has this weird "a8" ending, which sounds like invalid sighash. What is taken in that case? SIGHASH_ALL? Also, I don't know, how to make any message, which will hash into 1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9. And then, what is the z-value, which is used to make this signature? What are the last four bytes, added to the transaction? Is it "01000000"? Or maybe "a8000000"? Or something else?

Bitcoin protocol is "flexible" in certain places, one of which is the sighash byte.
This means we are not strict about what values are accepted, instead we work with the bits in that octet to decide whether SIGHASH_SINGLE or SIGHASH_NONE or SIGHASH_ANYONECANPAY is set in order to choose a different branch while computing the sighash. If none of these bits were set, those branches (in the code) are skilled and we call it SIGHASH_ALL.

To understand it best I like to think of it as splitting the byte into 2 limbs: the upper 3 bits and the lower 5 bits.
0xa8 is 0b10101000 so we have 0b101_01000
The lower part indicates NONE or SINGLE but only if the value is exactly equal to 2 or 3 respectively.
Here 0b01000 is equal to 8 so it is neither.

The upper part indicates ANYONECANPAY but only if the highest bit is set.
In 0b101 we can see that the highest bit (0b101) is indeed set so this is ANYONECANPAY.
In other words unlike the lower limb, equality is not checked here meaning 0b100, 0b101, 0b110 and 0b111 are all considered ANYONECANPAY and 0b000, 0b001, 0b010 and 0b011 are not.

In code it would look like this:

Code:

bool isSingle = ((nHashTypeIn & 0x1f) == SIGHASH_SINGLE)
bool isNone   = ((nHashTypeIn & 0x1f) == SIGHASH_NONE)
bool isAnyone = !!(nHashTypeIn & SIGHASH_ANYONECANPAY)

When computing the sighash digest, sighashtype byte is written to the stream as the same value converted to Int32 and in little-endian order meaning as 0xa8000000

[ercewubam]

So, what are the exact values? Because I tried different combinations (including SIGHASH_ANYONECANPAY), and something is still wrong. If I understand correctly, in this case, that kind of sighash will not change anything (because there is only one input). Which means, we first put the previous output in the scriptSig, so we have this transaction:

Code:

decoderawtransaction 0100000001395d705a36b122c01c9be97f8c69994c03bb8a0531990411ce7ac78f34e87f23000000001976a91446c3747322b220fdb925c9802f0e949c1feab99988acffffffff02af63f8ffffffff7f1976a91490e8d5ba1c2a301824b18d383dead728b13ea7b788acaf63f8ffffffff7f1976a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac00000000
{
  "txid": "afb7902164a1cae625082e2bfa7b8e9a85e2afc7fa1dc35edef52e8db8b31fa2",
  "hash": "afb7902164a1cae625082e2bfa7b8e9a85e2afc7fa1dc35edef52e8db8b31fa2",
  "version": 1,
  "size": 144,
  "vsize": 144,
  "weight": 576,
  "locktime": 0,
  "vin": [
    {
      "txid": "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39",
      "vout": 0,
      "scriptSig": {
        "asm": "OP_DUP OP_HASH160 46c3747322b220fdb925c9802f0e949c1feab999 OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a91446c3747322b220fdb925c9802f0e949c1feab99988ac"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 92233720368.54277039,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 90e8d5ba1c2a301824b18d383dead728b13ea7b7 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1EDDEGtrZ5877WPsLU5o9TwjJDqaUqhvte)#h50rucd6",
        "hex": "76a91490e8d5ba1c2a301824b18d383dead728b13ea7b788ac",
        "address": "1EDDEGtrZ5877WPsLU5o9TwjJDqaUqhvte",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 92233720368.54277039,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 2c72c4b5e0cbf9b6435f2cec9df8668c50751215 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu)#squqxq0e",
        "hex": "76a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac",
        "address": "1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu",
        "type": "pubkeyhash"
      }
    }
  ]
}

And then, we append "a8000000", and apply SHA-256 on that, so we get this:

Code:

0100000001395d705a36b122c01c9be97f8c69994c03bb8a0531990411ce7ac78f34e87f23000000001976a91446c3747322b220fdb925c9802f0e949c1feab99988acffffffff02af63f8ffffffff7f1976a91490e8d5ba1c2a301824b18d383dead728b13ea7b788acaf63f8ffffffff7f1976a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac00000000a8000000
39b2ebcbae59ced2b0b3fb0e3e8c095a0678c5a3e8adfce818f7d11bb37247b5
0f74c87ba2a7fad26dc08f85229e546b87011858d08ee77d02f9b173d519b7ea

But: if we use this value to calculate the public key "z*G", then it will give us the wrong value.

Code:

s=(z+rd)/k
sk=z+rd
z=sk-rd
z*G=sR-rQ

der1=3045022100
r=db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793
der2=0220
s=5ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027c
sighash=a8

Q=026b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7ad
R1=02db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793
R2=03db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793
rQ=db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793*026b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7ad
rQ=02B458A37F8F640F8F4CF14D441F96643F0664BEC62758D0B68D513A198ACBBB08
-rQ=03B458A37F8F640F8F4CF14D441F96643F0664BEC62758D0B68D513A198ACBBB08

sR1=5ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027c*02db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793
sR1=0292413FDACE01B90D343EDA1C91473A88F92437FE67CEA645FC7F8962C146831E
sR2=5ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027c*03db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793
sR2=0392413FDACE01B90D343EDA1C91473A88F92437FE67CEA645FC7F8962C146831E

z1*G=sR1+(-rQ)
z1*G=0292413FDACE01B90D343EDA1C91473A88F92437FE67CEA645FC7F8962C146831E+03B458A37F8F640F8F4CF14D441F96643F0664BEC62758D0B68D513A198ACBBB08
z1*G=03CAFF9C05621FF0D3879A93D7E9BAB054699DB8772F18C5B4FB926ABE2EDCDDF2

z2*G=sR2+(-rQ)
z2*G=0392413FDACE01B90D343EDA1C91473A88F92437FE67CEA645FC7F8962C146831E+03B458A37F8F640F8F4CF14D441F96643F0664BEC62758D0B68D513A198ACBBB08
z2*G=03994E79407E8CB50F9D0A41E5647D13445F154B542199B8ED22975F7FBFC60BB8

And then, we finally have two options:

Code:

z1*G=03CAFF9C05621FF0D3879A93D7E9BAB054699DB8772F18C5B4FB926ABE2EDCDDF2
z2*G=03994E79407E8CB50F9D0A41E5647D13445F154B542199B8ED22975F7FBFC60BB8

But if we use 0f74c87ba2a7fad26dc08f85229e546b87011858d08ee77d02f9b173d519b7ea calculated previously, it doesn't match any of those keys. Any ideas, where is the mistake?

[pooya87]

This is getting interesting.
Your sighash digest is now correct but I also can not verify the signature. Here are the values I got:

Code:

r = 0xdb8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793
s = 0x5ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027c
z = 0x0f74c87ba2a7fad26dc08f85229e546b87011858d08ee77d02f9b173d519b7ea

invmod(s) = 0xaa2b6a2b77962ef9d6adbab272abd40813d81caa5ff3f9afd373015aeb9b7c00

u1 = z*invmod(s) = 0x3ad862ff6ed48622eee6aad192d0157c5d98c8ff19b183d679e26b06f9df6872
u2 = r*invmod(s) = 0x8247771d948a778af047f4d2ec597d29966256972921afee4b83f9a0e8391f2d

R = u1*G + u2*pub = (0xc0c0d15d5f967c5d974556be6b5c06143242eb05675dab618fb53a2937549a36, 0xd8963b50661fb41bf14e21633cfbe914e7d87ba90f77486e955162f1f8c6e930)

R.x && R.y != 0
but 
R.x != r

Maybe there is something I'm missing that a third party can tell us...

[nc50lc]

I guess I did some mistake in calculating sighashes, but I don't know exactly, where it is.

In regards with pooya's reply that "0xa8" should be fine and by using the amount in the original thread (e05ef8ffffffff7f little-endian), the message should be:

Code:

0100000001395d705a36b122c01c9be97f8c69994c03bb8a0531990411ce7ac78f34e87f23000000001976a91446c3747322b220fdb925c9802f0e949c1feab99988acffffffff02e05ef8ffffffff7f1976a91490e8d5ba1c2a301824b18d383dead728b13ea7b788ace05ef8ffffffff7f1976a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac00000000a8000000

SHA256(message):

Code:

384749af150c0180312940fc049b3e4458ab3bef1af60ab9b340713e8e7cd79b

SHA256(above):

Code:

d76cb91081dc24b6417f4cb0fe49f8144f85129b871a8b50c3c36df496328353

So, the correct message hash (z) is: d76cb91081dc24b6417f4cb0fe49f8144f85129b871a8b50c3c36df496328353

I've verified the signature and it checks out.

[ercewubam]

Oh, so the amount given by Jeff Garzik was wrong, and it was not 92233720368.54277039, but 92233720368.54275808. Now it matches:

Code:

decoderawtransaction 0100000001395d705a36b122c01c9be97f8c69994c03bb8a0531990411ce7ac78f34e87f23000000008b483045022100db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f6879302205ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027ca841046b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7adfb0627ad7bda601ad2d129ebf037c5750841e9ba64ab199c4cb8280a95335d96ffffffff02e05ef8ffffffff7f1976a91490e8d5ba1c2a301824b18d383dead728b13ea7b788ace05ef8ffffffff7f1976a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac00000000
{
  "txid": "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9",
  "hash": "1d5e512a9723cbef373b970eb52f1e9598ad67e7408077a82fdac194b65333c9",
  "version": 1,
  "size": 258,
  "vsize": 258,
  "weight": 1032,
  "locktime": 0,
  "vin": [
    {
      "txid": "237fe8348fc77ace11049931058abb034c99698c7fe99b1cc022b1365a705d39",
      "vout": 0,
      "scriptSig": {
        "asm": "3045022100db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f6879302205ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027ca8 046b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7adfb0627ad7bda601ad2d129ebf037c5750841e9ba64ab199c4cb8280a95335d96",
        "hex": "483045022100db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f6879302205ad02d53231be18c5d6a77ffdb39476a5b5da4be70f0acc6794b181f4e38027ca841046b5d97aeed2979207f4ca7d9e75cdebf9ebb2a47d0b715370645f6845edfa7adfb0627ad7bda601ad2d129ebf037c5750841e9ba64ab199c4cb8280a95335d96"
      },
      "sequence": 4294967295
    }
  ],
  "vout": [
    {
      "value": 92233720368.54275808,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 90e8d5ba1c2a301824b18d383dead728b13ea7b7 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1EDDEGtrZ5877WPsLU5o9TwjJDqaUqhvte)#h50rucd6",
        "hex": "76a91490e8d5ba1c2a301824b18d383dead728b13ea7b788ac",
        "address": "1EDDEGtrZ5877WPsLU5o9TwjJDqaUqhvte",
        "type": "pubkeyhash"
      }
    },
    {
      "value": 92233720368.54275808,
      "n": 1,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 2c72c4b5e0cbf9b6435f2cec9df8668c50751215 OP_EQUALVERIFY OP_CHECKSIG",
        "desc": "addr(1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu)#squqxq0e",
        "hex": "76a9142c72c4b5e0cbf9b6435f2cec9df8668c5075121588ac",
        "address": "1542Dgx5EeurzHP8cT57fK6hBTQq2dgTEu",
        "type": "pubkeyhash"
      }
    }
  ]
}

And also, z-value of d76cb91081dc24b6417f4cb0fe49f8144f85129b871a8b50c3c36df496328353 matches too:

Code:

z=d76cb91081dc24b6417f4cb0fe49f8144f85129b871a8b50c3c36df496328353
z*G=03CAFF9C05621FF0D3879A93D7E9BAB054699DB8772F18C5B4FB926ABE2EDCDDF2
R=R1=02db8ccad098467a80bdb9ae16fca82aa4214a66c1ee24b62b696073e7e4f68793

So that means R-value should have 02 prefix before getting truncated.