Bitcoinjs-lib: Always create signatures with low R values

Created on 15 Aug 2018  路  7Comments  路  Source: bitcoinjs/bitcoinjs-lib

Recently bitcoind merged support for always using low R values during transaction creation

https://github.com/bitcoin/bitcoin/pull/13666

We should do so as well because it will decrease blockchain bloat and make fee calculations easier by having the signature size be at most 71 bytes.

The majority of the work seems to be in updating tests and updating comments that make reference to specific signature sizes, otherwise it's a simple retry and check for a low R.

feature how to / question / docs

Most helpful comment

For 2-of-3 multisig with p2sh it actually reduces the worst case input size from 297 bytes to 293 bytes, because when both signatures are 71 bytes, the sigScript is 252 bytes. The varInt to express the length of the sigScript jumps from 1 byte to 3 bytes when it's 253 bytes or larger which happens when at least one of the signatures is 72 bytes.

All 7 comments

I looked into it. I'll make a pull request now.

@Melvillian I haven't had a chance to follow that up yet, but is there a BIP or summary of __why__ they think it is advantageous?

Is it purely to save 1 byte???

(at the cost of not using RFC6979 by default, or signing multiple times)

Is it purely to save 1 byte???

Yep... I have committed (to a branch) the pure JS part of what will eventually be a PR if we want to merge it...
https://github.com/bitcoinjs/tiny-secp256k1/commit/23894eacd956667c7974c93ddae0d747b6ddf1b9

This is basically what they're doing. In Javascript terms.

@junderw I don't think we should move on that until its been peer reviewed (by ???) and used for atleast a few months. k is a sensitive topic.

Is there any other parts of the discussion happening?

Is it purely to save 1 byte???

(at the cost of not using RFC6979 by default, or signing multiple times)

Yeah, it saves half a byte on every signature at the cost of doubling the expected number of necessary signing attempts to find a signature. Besides saving blockchain space (I roughly estimate about 5-7 kB saved per 1 MB of non-segwit transactions), this allows for more consistent fee estimation on transactions, where previously everyone needed to estimate for the worst case and thus reduces overpaying on fees.

For 2-of-3 multisig with p2sh it actually reduces the worst case input size from 297 bytes to 293 bytes, because when both signatures are 71 bytes, the sigScript is 252 bytes. The varInt to express the length of the sigScript jumps from 1 byte to 3 bytes when it's 253 bytes or larger which happens when at least one of the signatures is 72 bytes.

ECPair and bip32 both have a lowR attribute (default: false) you can set to true and get this behavior.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

tuyennvtb picture tuyennvtb  路  3Comments

dakk picture dakk  路  3Comments

ishwarchandratiwari picture ishwarchandratiwari  路  3Comments

thrastarson picture thrastarson  路  3Comments

dcousens picture dcousens  路  3Comments