This is now 1:1 with decode, however, were you wanting to support encode 000001 giving back 01?

I see what you wanted, but yes, I wanted that encode give 01 for 000001

because this I used for-loop

@fanatid but we don't do that for decode.
So it would be inconsistent.

Also, you didn't add a test for that 😃

sorry, my fault with tests... (I only removed and fixed existed)
initially I wanted add leading zeros for expanding to 32-bytes in decode, but bip66 not checked that r/s longer than 32 bytes...

after decode we can't come back to 000001 from 01 because we don't knew how much zeros we should put

@fanatid in short, you wanted encode to trim all unnecessary padding? IMHO that is definitely out of scope, this change brings it back to a simple/sane implementation.
Especially since extraneous leading zeros are BIP66 compliant.

You could easily modify your buffer pre-encode to be trimmed with a 1-liner.
Eg count zeros then slice.

but should developer which uses bitcoinjs/bip66 think about padding? I'd like pass just buffer and don't think about leading zeros..
it is hard draw a line what should do encode/decode unlike check

@fanatid true, but developers that use this won't be feeding it signatures that have extraneous zeros unless they are making those themselves, in which case, I'd expect them to know what they're doing.

The change would also block a developer from being able to use bip66 to encode a extraneously padded signature... even if that seems pointless.

agreed, thanks