2

I was reading this gist and am not sure I am understanding/reading the hex of the multisig's redeem script correctly (line 14). It is:

52410491bba2510912a5bd37da1fb5b1673010e43d2c6d812c514e91bfa9f2eb129e1c183329db55bd868e209aac2fbc02cb33d98fe74bf23f0c235d6126b1d8334f864104865c40293a680cb9c020e7b1e106d8c1916d3cef99aa431a56d253e69256dac09ef122b1a986818a7cb624532f062c1d1f8722084861c5c3291ccffef4ec687441048d2455d2403e08708fc1f556002f1b6cd83f992d085097f9974ab08a28838f07896fbab08f39495e15fa6fad6edbfb1e754e35fa1c7844c41f322a1863d4621353ae

So I see the three public key pairs, beginning in bold text. I understand that the last byte (0xae) is OP_CHECKMULTISIG. But I am confused about the bytes (0x53, before 0xae) and the 5241 at the beginning. I am under the impression that before the public keys there should be two variables pushed onto the stack; one because of the checkmultisig bug and another to identify the m of n required signatures to unlock the bitcoin. And then n should come right before the last opcode (3 in this case).

What am I not understanding correctly? What's up with those fives and the 41 at the beginning? Thanks for the help!

Link to gist if broken: https://gist.github.com/gavinandresen/3966071

Improve this question

1 Answer 1

Reset to default
3

You are on the right track. 0x52 and 0x53 are the multisig elements ("2 of 3"), and 0xae terminates the structure. The "off by one error" comes before the signatures, which is in lines 58-60 of the gist. A good explanation of the multisig is (of course) in Andreas' book "Mastering Bitcoin". I have decoded the structure below:

    52: OP_2:                the number 2 is pushed onto stack 
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        0491BBA2510912A5:BD37DA1FB5B16730
        10E43D2C6D812C51:4E91BFA9F2EB129E
        1C183329DB55BD86:8E209AAC2FBC02CB
        33D98FE74BF23F0C:235D6126B1D8334F
        86
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    139FpKh63Vn4Y73ijtyqq8A6XESH8brxqs
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        04865C40293A680C:B9C020E7B1E106D8
        C1916D3CEF99AA43:1A56D253E69256DA
        C09EF122B1A98681:8A7CB624532F062C
        1D1F8722084861C5:C3291CCFFEF4EC68
        74
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1PNvbXZFysxvx3252w9JHMa7zbG95snqnm
    41: OP_DATA_0x41:        uncompressed pub key (65 Bytes)
        048D2455D2403E08:708FC1F556002F1B
        6CD83F992D085097:F9974AB08A28838F
        07896FBAB08F3949:5E15FA6FAD6EDBFB
        1E754E35FA1C7844:C41F322A1863D462
        13
        MultiSig's uncompressed Public Key (X9.63 form)
        corresponding bitcoin address is:    1jqo3ptYSnUhCJq75MMyRuwC2zNyQqRy3
    53: OP_3:                the number 3 is pushed onto stack
        ##### --> 2-of-3 Multisig 
    AE: OP_CHECKMULTISIG:    terminating multisig

        corresponding bitcoin address is:    3QJmV3qfvL9SuYo34YihAf3sRCW3qSinyC
Improve this answer
2
  • Ok, that makes sense. I was unclear on how OP_2-16 worked but your answer I believe clears that up. Hypothetically then if this was a m=10 and n=13 scheme then we would have 0x5a and 0x5d? Our highest possible value for field n being 0x60, no? Thanks for the help!
    – evil_doctor
    Feb 19, 2018 at 22:59
  • the codes are listed here: en.bitcoin.it/wiki/Script#Constants, and yes, 0x5a and 0x5d. Highest value = 0x60 (OP_16). Hint: multisigs have their limitations, you cannot easily create a 10-of-13 multisig, cause it exceeds verification limits / size. Pieter explained it here: bitcoin.stackexchange.com/questions/23893/… - I think with segwit the limits are shifted higher.
    – pebwindkraft
    Feb 19, 2018 at 23:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.