Issues with Duplicate R and S in Signatures

Hey there. I’ve been struggling to verify a signature. When I get the Z value, the Kx value of point K (or R) doesn’t match. Am I messing up the message calculation? I keep seeing repeated S and R values in the signatures. Here’s a TX for reference: https://www.blockchain.com/explorer/transactions/btc/bd17bfb7051bef5ca916931f06493a0af0db080b4df21ee9768fa0f3d775070a Anyone know how the math works for verifying this TX?

Signature verification is pretty standard across all transactions. If you want a deep dive, check this link out: https://cryptobook.nakov.com/digital-signatures/ecdsa-sign-verify-messages But to give you the gist, you need to calculate the proof of the signature s. Basically, it’s all about ensuring the math lines up between your message, public key, and the signature.

Hey Albert, Thanks for the info! I’ll look it over again. I’ve been around this topic for a bit. I want to break it down with an example from the TX I mentioned. Gonna share my sagemath log. The signature isn’t verifying with these values; I tried a bunch of scripts and checked my Z value. And the signature type? It’s "pubkeyhash".

Yo, Before diving deeper, check those message hashes. They’re definitely off.

Exactly, that's the crux of this topic. According to the math, same R and S can only happen if the hash is identical across messages for the same public key. I checked the signatures too, and all are sharing the same R and S. But the UTXO values are different. Should mean the transaction’s invalid.

I’m betting this is from a bitcoin mixer, and yeah, might see more like this.

Yep. The inputs that show the same R and S have the [SINGLE|ANYONECANPAY] (0x83) sighash flag. That could be why they’re identical. But I can’t find a tool that checks for the sighash flag and adjusts the Z-value calculation accordingly. Just do your own research on it. Here’s some references for that: https://static.learnmeabitcoin.com/diagrams/png/keys-signature-hash-types.png, https://raghavsood.com/blog/2018/06/10/bitcoin-signature-types-sighash/.

Thanks for the clear explanation. This definitely helps!

Hey, appreciate the insights! Hoping I can do this manually. I want to really grasp the validation process. I’ve laid out an example: https://blockchain.info/rawtx/bd17bfb7051bef5ca916931f06493a0af0db080b4df21ee9768fa0f3d775070a?format=hex It’d be awesome if others jumped in and took a crack at it. I really wanna understand this verification algorithm.

Hi, I think I figured this out. The issue is the "SIGHASH_SINGLE bug". After the first sig, the rest all have a hash of "0100000000000000000000000000000000000000000000000000000000000000". I tested it and got it to verify.

Not a bug. That’s how SIGHASH_SINGLE is set up. It basically says you’ve gotta sign the output at the same index as the input, but Bitcoin lets you have different input/output counts. No rules saying they have to match.

Definitely a bug. Usually, that whole transaction should just be marked invalid.

Not really. If you look at legacy and Segwit, they define it differently. For a "bc1q" address, it’s not just the SHA-256 of "1"; it's more complicated.

If we say "z=1" then it should switch endianness. They should just mark that specific case as invalid and reject it.

It’s only a bug if they’re unintentionally signing 1. But the code was written to do that on purpose in that case. If we force every SIGHASH_SINGLE transaction to match inputs and outputs, that’s just unreasonable. Users should have options here.

Looks like a bug to me. That "printf" seems to say "let’s report an error," not "let's legitimize this value". But when it returns "1", everything else just carries on.

No one knows the private key. The public key is out there but the private key remains a mystery. If anyone cracked it, they could do the same for any public key.

Exactly, we don't know d-value or k-value either.