user31844: 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

user208: 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.

31844: <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>
 208: <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>
