mandatory-script-verify-flag-failed (Non-canonical DER signature issue)

Hey everyone So I got this transaction from 2016 that was signed using an old wallet. There's this annoying error popping up: mandatory-script-verify-flag-failed (Non-canonical signature: S value is unnecessarily high). I tried fixing the S value to the proper one but now I'm stuck with a new error: mandatory-script-verify-flag-failed (Non-canonical DER signature). Here’s what I have: Original signature: 3046022100ac792f9d39b644835b9eabbeba9d48897385c721291267d07a850fbb07e5d9a102210 0a552e1f28efb3dbd3ca6a360bc0e28f5cf0d73f4ba96202451be1129433a67b5 Updated signature with the fixed S value: 3046022100ac792f9d39b644835b9eabbeba9d48897385c721291267d07a850fbb07e5d9a102210 05aad1e0d7104c242c3595c9f43f1d708eba168f1f4b280176e144d638cfbd98c The kicker is, I can't re-sign the transaction since I don't have the sender's private key, and I'm just the recipient here. Any advice would be awesome!

Assuming you did indeed compute -s correctly, all you have to do here is to change the DER encoded signature to 0x3045022100ac....e5d9a102205aad1... Explanation: In DER encoding to indicate a positive integer the highest bit of the first byte should not be set. In this case when in your first signature the s value starts with 0xa5 which is 0b10100101 we can see that the highest bit is set. So we append 0x00 to the beginning of it to make sure it is interpreted as positive: 0x00a5 However, when you computed -s your new value is 0x5a which is 0b01011010 and as we can see the highest bit is 0 so there is no need for the 0x00 addition. Meaning your second signature is non-standard with that additional zero. The other thing to consider is the DER lengths. When you remove that 0x00 you are removing one byte and the DER lengths have to reflect that. So the s length 0x21 turns into 0x20 and the total sequence length 0x46 should turn into 0x45.

Here you put an extra a e5d9a102205aaad1...? A mistake? So the signature is like this after your instructions 3045022100ac792f9d39b644835b9eabbeba9d48897385c721291267d07a850fbb07e5d9a102205aad1e0d7104c242c3595c9f43f1d708eba168f1f4b280176e144d638cfbd98c But when I try to do a broadcast raw transaction I now have this error "error": "RangeError: value out of range"

Yes, that was a mistake. Sorry about that. Yes, I double checked your s value as well. It was correct and the new signature should be like what you posted. The error you are receiving may not be related to your signature. Have you checked other values like the amounts in your outputs to be within range?

Yes, I checked. The amounts are within range, the fee is correct. I have no idea why I'm getting this error now

on another website I have the following error: 1 the transaction was rejected by network rules. TX decode failed. Make sure the tx has at least one input.

If you don't mind a little privacy issue, you may post the actual signed transaction so users can pinpoint the cause. No one can edit the outputs of your transaction unless its using other non-default sighash types, For that, check the byte next to that signature. By the way, is this related to your old topics or another one of your finds? (your username is familiar so I searched for similar users) Links to those threads: Where is my BTC from 2010? HelpI have a BTC from 2016 - old network

No, it's not mine lol The byte next to that signature is fe I don't want to give raw transaction publicly because everyone will want payment for help (I already did it on another forum). People unfortunately can't help for free

Providing the raw transaction will not in any way allow someone to force you to pay them. Anyone demanding payment for helping is likely a scammer who will not be able to help you anyhow. You are mistaken.  All of the most knowledgeable and experienced people on this forum provide nearly all of their help for free. We are more interested in the long-term success of Bitcoin than in trying to get a few dollars from a few people that need help. Are you SURE you checked ALL other values to make sure they are ALL in range?  Why are you so sure that the signature is the problem? It sounds like maybe you don't have valid inputs in the transaction? You might want to check that again. Also: Why didn't the sender broadcast the transaction in 2016?  Why didn't YOU broadcast the transaction in 2016?  Why did the sender give you a transaction that was not broadcast?

This may be yet another case of purchased fake wallet.dat where it looks like the file they buyer just paid for is filled with bitcoins and all it takes is a trivial step (breaking the password, broadcasting a tx that was never sent, importing the partial private key in a wallet software, etc.).

Okay, I'll just consider that as a strange case of case-sensitive first 8 characters collision of two user's username... With a grain of salt Weird, normally, the signature is followed by the "sighash type" used and 0xFE isn't a valid sighash type for legacy transactions. You might want to check the other parts of your transaction aside from the signature.

I'm aware.  I just thought it was more polite to ask rather than accuse.

Ok guys. It doesn't matter what, how or why, just that I send this transaction (it's a long story). Original raw transaction 0100000001fe84d378379a44b5751e89f5145916abe2ec18c03735ad811fc656a34628dd2200000 0008c493046022100ac792f9d39b644835b9eabbeba9d48897385c721291267d07a850fbb07e5d9 a1022100a552e1f28efb3dbd3ca6a360bc0e28f5cf0d73f4ba96202451be1129433a67b50141049 3249c6c4b75ce574e4f1ecc07117668f5ca7fd73ead514843ad4a9d4195c8f7b41662586dc61bcf 920ef53031770afa183be244e88d6cc75d16de97f2da6d1dfeffffff02006d7c4d0000000016001 4bce56fa1231ff207fee8c421060faeb08f47813cf09c8a29000000001976a914687ff91a13091d 31303c1bd7d27f23b610d52ac488ace2220d00 Raw transaction with changed S 0100000001fe84d378379a44b5751e89f5145916abe2ec18c03735ad811fc656a34628dd2200000 0008c493046022100ac792f9d39b644835b9eabbeba9d48897385c721291267d07a850fbb07e5d9 a10221005aad1e0d7104c242c3595c9f43f1d708eba168f1f4b280176e144d638cfbd98c0141049 3249c6c4b75ce574e4f1ecc07117668f5ca7fd73ead514843ad4a9d4195c8f7b41662586dc61bcf 920ef53031770afa183be244e88d6cc75d16de97f2da6d1dfeffffff02006d7c4d0000000016001 4bce56fa1231ff207fee8c421060faeb08f47813cf09c8a29000000001976a914687ff91a13091d 31303c1bd7d27f23b610d52ac488ace2220d00 Modified after instructions pooya87 0100000001fe84d378379a44b5751e89f5145916abe2ec18c03735ad811fc656a34628dd2200000 0008c493045022100ac792f9d39b644835b9eabbeba9d48897385c721291267d07a850fbb07e5d9 a102205aad1e0d7104c242c3595c9f43f1d708eba168f1f4b280176e144d638cfbd98c014104932 49c6c4b75ce574e4f1ecc07117668f5ca7fd73ead514843ad4a9d4195c8f7b41662586dc61bcf92 0ef53031770afa183be244e88d6cc75d16de97f2da6d1dfeffffff02006d7c4d00000000160014b ce56fa1231ff207fee8c421060faeb08f47813cf09c8a29000000001976a914687ff91a13091d31 303c1bd7d27f23b610d52ac488ace2220d00 I have no idea what else I can do to broadcast it

Allow me to add code tags so the forum doesn't add spaces:

You forgot to fix two of the "other length" values. In each signature script we have these lengths: 1. The script length that covers the entire script 0x8c 2. When you enter the script, there is signature that is being pushed to the stack and it starts with the length of the signature 0x49 (and also the pubkey being pushed to the stack that remains unchanged) 3. The DER lengths we discussed before inside the signature itself We fixed #3 but you should have fixed #1 and #2 by reducing them each by one to reflect the byte we removed. 0x8c becomes 0x8b and 0x49 becomes 0x48 In the future try to avoid manually modifying transactions. Always use code. In this case you should have deserialized the transaction, evaluated the script, pushed the first item to the stack (ie. the signature when reading from left to right!), evaluated the signature and then negated the s and recreated a push to the stack and then recreated the signature script using code. Something like this in pseudocode:

Let's see what we've got here. I've separated the transaction into it's components below (please, someone else, review that and make sure I got it all correct. It's been quite a while since I last tried to analyze a bitcoin transaction byte-by-byte).  It does seem that all the necessary components are there. I haven't looked closely at the signature yet, but everything else does look correct/valid.  I did verify that the pubKey in the transaction input appears to be the correct pubKey (although, I'd appreciate it if someone else would double-check that). 01000000 = version 1 transaction 01 = 1 input fe84d378379a44b5751e89f5145916abe2ec18c03735ad811fc656a34628dd22 = hash of output being spent 00000000 = index of output being spent (19.9995 BTC) 8c = Txin-script length (140 bytes) 49 = push 73 bytes to the stack (that should be the signature) 3046022100ac792f9d39b644835b9eabbeba9d48897385c721291267d07a850fbb07e5d9a102210 0a552e1f28efb3dbd3ca6a360bc0e28f5cf0d73f4ba96202451be1129433a67b501 = the 73 bytes to push (The signature associated with the pubKey) 41 = push 65 bytes to the stack (that should be a pubKey) 0493249c6c4b75ce574e4f1ecc07117668f5ca7fd73ead514843ad4a9d4195c8f7b41662586dc61 bcf920ef53031770afa183be244e88d6cc75d16de97f2da6d1d = the 65 bytes to push (the Pubkey that hashes to pubKeyHash from the UTXO that's being spent) feffffff = Sequence number (RBF) 02 = 2 outputs 006d7c4d00000000 = satoshis assigned to the first output (13.0 BTC) 16 = Txout-script length (22 bytes) 00 = OP_0 (I haven't learned as much about segWit as I'd like, but I think this indicates a segWit output?) 14 = push 20 bytes to the stack bce56fa1231ff207fee8c421060faeb08f47813c = the 20 bytes to push f09c8a2900000000 = satoshis assigned to the second output (6.9695 BTC) 19 = Txout-script length of the second output (25 bytes) 76 = OP_DUP a9 = OP_HASH_160 14 = push 20 bytes to the stack 687ff91a13091d31303c1bd7d27f23b610d52ac4 = the 20 bytes to push (this is the pubKey Hash) 88 = OP_EQUALVERIFY ac = OP_CHECKSIG e2220d00 = locktime (decimal 860898) I'll look through pooya87's suggestions later this evening and see if you've applied them correctly, and if (applied correctly) they are likely to fix the problem. EDIT:  I see that pooya87 has already responded. I hadn't refreshed the conversation before writing this up. Sorry about that. Did his latest fix it for you?  I'll still take a look at it later this evening if there's no response from anyone else by then.

You can use Bitcoin Core's testmempoolaccept command to try if it'll be accepted by your node without actually sending it. Using the provided transaction: Result: It has "failed CHECKSIG operation". Looks like the client/tool used to create the signature was buggy or (in case of fake wallets) forced to sign with the wrong private key.

Thank you so much guys But still ... Mempool accept test failed: mandatory-script-verify-flag-failed (Signature must be zero for failed CHECK(MULTI)SIG operation) Now I'm worried if there's anything I can do to fix this (without re-signing)

The signature is just invalid. You need to re-sign the transaction.

As other have pointed out, there are really two likely possibilities here. Either the transaction was signed using custom software and that accidentally had a bug in it (just ask the sender to re-sign using valid software), or you acquired a transaction that was never intended to actually be valid from someone that was trying to take advantage of you. Are you willing to tell us which it is, and where/how you acquired this transaction?