<p>This is unrelated to segregated witness.</p>

<p>Since Bitcoin Core version v0.17, signatures have <a href="https://github.com/bitcoin/bitcoin/pull/13666" rel="nofollow noreferrer">low R</a> signatures. The signing operating is repeated until an R value is constructed that's below 2<sup>255</sup>. 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.</p>

CC BY-SA 4.0
2019-06-28T23:29:59.427Z
2019-06-28T23:29:59.427Z
Pieter Wuille
<p>I have been writing a (yet another) Bitcoin <a href="https://github.com/karask/python-bitcoin-utils" rel="nofollow noreferrer">python library</a> primarily for educational purposes; for me and my students.</p>

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

<p>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.</p>

<p>I am trying to understand why. The library uses the same <a href="https://github.com/karask/python-bitcoin-utils/blob/3c8b60c3045501a440a15095ea420fd0fbf7bedc/bitcoinutils/keys.py#L261" rel="nofollow noreferrer">signing method</a> in both cases. The library's <a href="https://github.com/karask/python-bitcoin-utils/blob/3c8b60c3045501a440a15095ea420fd0fbf7bedc/bitcoinutils/transactions.py#L409" rel="nofollow noreferrer">tx digest calculation</a> seems to be working fine since valid transactions are generated.</p>

<p>I have seen another <a href="https://bitcoin.stackexchange.com/questions/81551/allowed-der-encoding-format-violations-for-signatures-in-bitcoin-implications-f">post</a> that mentions lax and strict DER encodings. Is this relevant, and if yes, does it only applies when signing segwit inputs?</p>

<p>What am I missing?</p>

<p>EDIT: the signature from the library is: 
483045022100debdd831b8f144afcaa4e9cb71713ec657292ac09d163e827dc1d458417841a70220292b6f250e4ad94ec2b3f062129b85620c22be9be97f8a42346612de8fc423200121</p>

<p>And from Bitcoin core:
4730440220413d31dcd84594d2bf1408d41ec6913694b7936c2cc598f436a4709cd2d70264  02201b646f18fa4108ee19d103d427c2323a0f221e33ecb65bed0690ec69c478b8800121</p>

CC BY-SA 4.0
2019-06-28T15:57:19.850Z
Can you show the signatures that come out?
Pieter Wuille
CC BY-SA 4.0
2019-06-28T23:23:15.223Z
updated question to include the signatures
karask
<bitcoin-core><segregated-witness><signature><ecdsa><library>
Why is a library's signature of a segwit tx different from Bitcoin Core signature?
karask
# Why is a library's signature of a segwit tx different from Bitcoin Core signature?

(Asked by: username_0 on 2019-06-28)

I have been writing a (yet another) Bitcoin [python library](https://github.com/username_0/python-bitcoin-utils) 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](https://github.com/username_0/python-bitcoin-utils/blob/3c8b60c3045501a440a15095ea420fd0fbf7bedc/bitcoinutils/keys.py#L261) in both cases. The library's [tx digest calculation](https://github.com/username_0/python-bitcoin-utils/blob/3c8b60c3045501a440a15095ea420fd0fbf7bedc/bitcoinutils/transactions.py#L409) seems to be working fine since valid transactions are generated.

I have seen another [post](https://bitcoin.stackexchange.com/questions/81551/allowed-der-encoding-format-violations-for-signatures-in-bitcoin-implications-f) 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

**Tags:** bitcoin-core, segregated-witness, signature, ecdsa, library

> **Comments:**
> **username_1**: Can you show the signatures that come out?  
> **username_0**: updated question to include the signatures  

---

## 1 answers

### Answer by username_1 on 2019-06-28. Score: 3 | Accepted answer

This is unrelated to segregated witness.

Since Bitcoin Core version v0.17, signatures have [low R](https://github.com/bitcoin/bitcoin/pull/13666) 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.


---

