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
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 – 2018-02-19T22:59:30.363
the codes are listed here: https://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: https://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses - I think with segwit the limits are shifted higher.
– pebwindkraft – 2018-02-19T23:07:55.867