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? Jun 28, 2019 at 15:57
  • updated question to include the signatures
    – karask
    Jun 28, 2019 at 23:23

1 Answer 1


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 2255. 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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.