Why is a library's signature of a segwit tx different from Bitcoin Core signature?

Question

I have been writing a (yet another) Bitcoin python library primarily for educational purposes; for me and my students.

Signing a non-segwit transaction results in a signed tx that is identical to what Bitcoin Core produces.

However, signing a segwit tx results in a signed tx that is valid but different to what Bitcoin Core produces. The signature created is different.

I am trying to understand why. The library uses the same signing method in both cases. The library's tx digest calculation seems to be working fine since valid transactions are generated.

I have seen another post that mentions lax and strict DER encodings. Is this relevant, and if yes, does it only applies when signing segwit inputs?

What am I missing?

EDIT: the signature from the library is: 483045022100debdd831b8f144afcaa4e9cb71713ec657292ac09d163e827dc1d458417841a70220292b6f250e4ad94ec2b3f062129b85620c22be9be97f8a42346612de8fc423200121

And from Bitcoin core: 4730440220413d31dcd84594d2bf1408d41ec6913694b7936c2cc598f436a4709cd2d70264 02201b646f18fa4108ee19d103d427c2323a0f221e33ecb65bed0690ec69c478b8800121

Can you show the signatures that come out? – Pieter Wuille Jun 28 '19 at 15:57 — Pieter Wuille, Jun 28 '19 at 15:57
updated question to include the signatures – karask Jun 28 '19 at 23:23 — karask, Jun 28 '19 at 23:23

score 3 · Accepted Answer · answered Jun 28 '19 at 23:29

This is unrelated to segregated witness.

Since Bitcoin Core version v0.17, signatures have low R signatures. The signing operating is repeated until an R value is constructed that's below 2²⁵⁵. On average this only takes 2 attempts, but it makes all signatures equally long (71 bytes; rather than 50% 71 bytes and 50% 72 bytes), making them more predictable and slightly cheaper on the network.

Why is a library's signature of a segwit tx different from Bitcoin Core signature?

1 Answers1