I’m attempting to implement a script-path spend on taproot, the place the 1 script is a 1 of two multisig (sure I do know this is not probably the most environment friendly approach of reaching this final result).
I can get the key-path to work appropriately, and I’ve calculated the entire tagged hashes appropriately, however I nonetheless get error code: -26 error message: non-mandatory-script-verify-flag (Invalid Schnorr signature).
My Schnorr signature is appropriate and is validated, and corresponds to one of many keys within the multisig (once I attempt the opposite key I get identical error). I believe the issue lies in both the multisig script implementation, or the sighash development.
My multisig is as follows: <32-byte pubkey1> OP_CHECKSIG <32-byte pubkey2> OP_CHECKSIGADD 1 OP_NUMEQUAL, a.okay.a <20> <32 bytes> <ac> <20> <32 bytes> <ba> <51> <9c>
My sighash is the next (with little endianness the place acceptable):
epoch + hash_type + model + nlocktime + #sha_prevouts + #sha_amounts +#sha_scriptpubkeys + #sha_sequences+ #sha_outputs + spend_type + input_index
The place epoch = "00", hash_type = "00", spend_type = "00" and input_index = "00000000".
I’m formatting and concatenating the SHA preimages appropriately (together with the script byte lengths), and this sighash format has labored for key path spends previously. All the things hashes out appropriately (there isn’t any witness program hash mismatch).
My management block is: c0 + internal_pubkey and unlocking script is: "00" + "40" + schnorr_sig + <len script> + <script> + <len management block> + control_block. I wasn’t positive if the “00” ought to go earlier than or after the primary sig, however with script execution it is smart to place “00” first in case the place I signal with first pubkey (though I’ve tried each methods unsuccessfully).
Given my validated signature (which does match to the 1 of two multisig), seemingly appropriate sighash and so on., I am at a lack of what I might be doing flawed. Any help is drastically appreciated. Under is the sighash, TapSighash, signature and remaining uncooked transaction respectively:
Sighash:
0000010000000000000099f39068ebcfd1d34e63d3bd1159c8237d5d086343c06408cdbc79180695e8c73e1f6dbf626619317d04b24ac25799871709e0f3e35cc0e05dae4da21bc5a162e3c29eaa90352e63931c83366d585cc64019da58c9cd8dd2f43062702153d6b9bf906cd362964d265fdb27547a75d2ad2ce86cccec49cdc613764a77dc5f149d993b3cce8dcc00523357f17a52fcc5fecbe39fea83829dda4bdf453fb3d056300000000000
TapSighash:
0aea7f6f399744d65b9b8077c2f1431b14a78db43bd9659f6c1afd65a912dfdc
Schnorr Sig:
ef6ee4c4ec327c61b3455575f4683df36b24b993daccca3328473e1149906f1f929c2707f5f972855935f2b9320538e6999e4bd1b0ad99f86332100a190164e5
Uncooked Tx:
01000000000101c9612f1a4436eae322feecf68ef3318f87c3ce375c09b1d257c7621e5997f5df0000000000fffffffe0218150000000000002251203ea692bfe06ac9956836045a73b0184644c9d8cdd39734236c4c101c59676ce658020000000000001976a9148059905a03a8b65b9783037490d629948898054888ac040040ef6ee4c4ec327c61b3455575f4683df36b24b993daccca3328473e1149906f1f929c2707f5f972855935f2b9320538e6999e4bd1b0ad99f86332100a190164e54620de153317307164e7c9918791c7787d9833a3a8201bdff880e631e490cf9a087cac202e936665ba37c601f91a8110d9da29caeb20b4f62c55ef3ae7868bd7a37afa84ba519c21c0b33421b257ea992bc721b71b58449ac6e529318daff80a4b7477abddf829476400000000